What is Incident Response?

What is incident response?

Incident response is the organised way a team handles an incident: an unplanned event that disrupts a service or threatens security, such as an outage, a data leak or a compromised account. It covers noticing the problem, working out its scope, limiting the damage, restoring service and learning from it so it happens less often.

There are two flavours. Operational incidents (outages, slow responses, a bad deploy) are about restoring service fast. Security incidents (a breach, malware, stolen credentials) add evidence handling and legal duties. They share the same backbone, which is why one process can cover both.

The incident response lifecycle: no single number of phases

There is no universal count of phases. The classic model from NIST SP 800-61 Revision 2 (2012) has four: preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. NIST replaced that revision in April 2025 with SP 800-61 Revision 3, which organises incident response around the six functions of the NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) and feeds lessons learned back into all of them. It also says each organisation should use the lifecycle model that suits it best. The four classic phases are still a handy vocabulary:

1. Preparation. Done before anything breaks: on-call rotation, escalation paths, runbooks, role definitions, message templates, practice runs.
2. Detection and analysis. An alert fires or a customer reports a problem. Someone confirms it, judges how bad it is and who is affected, and declares an incident.
3. Containment, eradication and recovery. Stop the damage first (roll back, disable a feature, fail over, revoke credentials), then remove the cause and bring the service back.
4. Post-incident review. Reconstruct the timeline, find the contributing causes, agree actions and follow them through. Run it blamelessly, or people stop reporting what went wrong.

Roles

Even a two-person team benefits from naming who does what, one person may hold several roles:

• Incident commander: runs the response and makes the calls. Coordinates rather than fixing.
• Responders: investigate and apply the fix, taking direction from the commander.
• Communications lead: keeps customers and colleagues informed. See incident communication.
• Scribe: writes down the timeline as it happens, which makes the review far easier.

An example

This is illustrative. At 14:05 two monitoring locations report that POST /checkout returns 500 errors. The on-call engineer confirms it, declares a major incident (severity names and levels are whatever your team defines) and names an incident commander. The communications lead posts "Investigating" on the status page. A responder links the errors to the 13:50 deploy, and the commander decides to roll back rather than debug live. Errors stop, the team watches the error rate for a while, then marks the incident resolved. Afterwards the review finds the deploy skipped a staging check, and the action list adds that check plus a faster alert.

Common mistakes

• No single owner. Several people changing things in parallel undo each other's work. Always name a commander.
• Investigating before containing. Stopping the damage with a rough fix, then finding the root cause calmly, is usually the right order. For a security incident, preserve evidence while you contain.
• Noisy alerts. If people ignore pages, a real incident is lost among them. See alert fatigue.
• Silence outside the team. Customers notice the outage before your update does. Keep the status page on infrastructure that survives the incident.
• A review with no follow-through. A postmortem whose actions never ship just records the next incident in advance.
• Reading the runbook for the first time during an incident. Rehearse with tabletop exercises or game days.

Security incidents and legal clocks

Security incidents can start legal deadlines. Under GDPR Article 33, a controller must notify the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people's rights and freedoms. Know who decides this before you need to.

How it relates to testing and monitoring

Response starts with detection, and detection depends on observability: metrics, logs and checks that tell you something is wrong before customers do. It also sits inside reliability engineering, where blameless reviews and service level targets decide what gets fixed afterwards. LoadFocus is not an incident response platform and does not run your on-call or process. What it gives you are two inputs:

• API monitoring runs scripted checks on a schedule (every 5 minutes on the free plan) from several of its 25 regions, asserts on status code, body, headers and response time, and alerts by email, Slack, Microsoft Teams or webhook, plus PagerDuty and Opsgenie on paid plans. Requiring consecutive failures or several failing locations cuts false pages.
• Status pages carry the public side: incident updates move from investigating to identified, monitoring and resolved, and a postmortem can be published afterwards. A status page is where customers look first.

Load testing belongs in preparation: load tests show where a system breaks under volume before real traffic finds out. For habits that keep alerts useful, see the monitoring best practices guide.

FAQ: Incident Response

How many phases does incident response have?

It depends on the model. NIST SP 800-61 Revision 2 used four phases. Revision 3 (April 2025) maps incident response onto the six functions of the Cybersecurity Framework 2.0 and tells organisations to use the lifecycle that suits them. What matters is covering preparation, detection, containment and recovery, and learning, whatever you call them.

Who should be the incident commander?

Anyone trained for the role, not necessarily the most senior engineer. The job is coordination and decisions, not fixing. Many teams keep a rotating bench of commanders so the role does not depend on one person.

What is the difference between an incident and a problem?

In ITIL vocabulary, an incident is a single unplanned interruption and a problem is the underlying cause of one or more incidents. One problem, such as an exhausted connection pool, can cause several incidents over time.

Should postmortems be public?

It is a judgement call. Many teams publish a shorter public summary for major customer-facing incidents and keep the detailed review internal. Whichever you choose, say what happened, what you are changing and by when.

How do we practise incident response?

Walk through a scenario in a tabletop exercise, run a game day where you inject a real failure in a safe environment, and let new on-call engineers shadow a response before they lead one.