The incident response lifecycle

Why a process exists at all

When a breach is in progress, improvisation costs money and evidence. A defined incident response (IR) process means the team acts fast, consistently and legally under pressure, containing damage, preserving evidence, and learning so it doesn't recur. The point is to have made the hard decisions before the alarm goes off.

Some definitions that exams test:

• An event is any observable occurrence (a login, a file change); most are benign.
• An alert is an event flagged as potentially significant.
• An incident is an event (or series) that actually harms, or imminently threatens, the confidentiality, integrity or availability of systems or data. Triage is the work of deciding which alerts are incidents.

The classic four-phase lifecycle (SP 800-61r2)

For years the reference model was NIST's four-phase cycle, and it remains the cleanest way to learn the flow. It's a cycle, not a line: lessons feed back into preparation.

1. Preparation: everything done before an incident: the IR plan, a trained team, tooling, logging, backups, contact lists, and runbooks. The most important phase, because it determines how well every other phase goes.
2. Detection and Analysis: identifying that an incident is happening (from SIEM alerts, IDS, user reports, threat intel) and analysing its scope, entry point and impact. Triage and prioritisation live here.
3. Containment, Eradication and Recovery: limit the spread (short-term containment, e.g. isolate the host; long-term, e.g. rebuild cleanly), remove the threat (eradicate the malware, close the vulnerability, reset credentials), then restore systems to normal, verified-clean operation.
4. Post-Incident Activity: the "lessons learned" review: what happened, how well did we respond, what do we change? Feeds back into preparation. Frequently skipped under pressure, and that's how organisations get hit the same way twice.

Containment nuance: there's a tension between containing immediately and watching to understand scope. Pull the plug too early and you may miss how far the attacker spread or tip them off; wait too long and damage grows. There's also an evidence trade-off, since pulling power kills volatile memory evidence. These judgement calls are why the plan and a clear decision-maker matter.

The modern model: NIST SP 800-61 Revision 3 (2025)

In April 2025 NIST published SP 800-61 Revision 3, which restructures incident response around the six Functions of the NIST Cybersecurity Framework (CSF) 2.0 rather than the rigid four-phase lifecycle. The aim is to embed IR within broader risk management instead of treating it as a standalone procedure. The Functions split across the incident:

• Govern, Identify, Protect: the "before": prevent what you can, prepare to handle the rest, reduce impact, and improve based on lessons learned. (This is the old Preparation phase, widened and tied to governance.)
• Detect, Respond, Recover: the "during and after": discover, triage, contain, eradicate, recover, and handle reporting and communications.

For study, hold both: the four-phase cycle is the intuitive process model and still widely used and examined; r3/CSF 2.0 is the current official framing that ties IR into governance and risk. They describe the same work organised differently. Preparation maps onto Govern/Identify/Protect, and the active handling maps onto Detect/Respond/Recover.

A useful alternative to know is the SANS PICERL model (Preparation, Identification, Containment, Eradication, Recovery, Lessons learned), essentially the four phases expanded to six steps.

The team and the plan

CSIRT / CERT: the Computer Security Incident Response Team is the group (often cross-functional) responsible for handling incidents. It isn't only technical staff. Serious incidents pull in legal (breach-notification obligations), communications/PR (public messaging), HR (if an insider is involved) and senior management (decisions like whether to pay a ransom or take systems offline).

The Incident Response Plan is the document defining roles, severity classifications, escalation paths, decision authority and communication procedures. Two themes make it work:

• Communication planning. Who is told, when, and how. This includes out-of-band channels: if email and chat are compromised, the team needs a pre-agreed alternative. It also covers regulators (e.g. UK GDPR's 72-hour breach-notification rule) and customers.
• Practice. Plans that live in a drawer fail. Tabletop exercises (talking through a scenario) and full simulations expose gaps in a low-stakes setting and build the muscle memory that makes the real response calm.

Detection inputs and metrics

Detection draws on SIEM correlation, IDS/IPS, EDR, threat intelligence, and (often the fastest source) user reports, which is why blame-free reporting from the social-engineering chapter matters. Two metrics measure how well it's working:

• MTTD (Mean Time To Detect): how long until an incident is noticed. Industry dwell times are often measured in weeks, which is precisely the problem OWASP's logging/alerting category targets.
• MTTR (Mean Time To Respond/Recover): how long from detection to resolution.

Shrinking both is the goal of investing in detection and a rehearsed response.

Quick recall

• Event → alert → incident: an incident actually harms or imminently threatens CIA.
• Classic NIST four phases: Preparation → Detection & Analysis → Containment, Eradication & Recovery → Post-Incident Activity (a cycle; preparation is the most important, lessons-learned the most skipped).
• SP 800-61r3 (2025) reorganises IR around CSF 2.0's six Functions: Govern/Identify/Protect (before) and Detect/Respond/Recover (during/after). SANS PICERL is the six-step variant.
• Containment trades speed against understanding and against preserving volatile evidence; decide in advance.
• CSIRT/CERT is cross-functional (legal, PR, HR, management). The IR plan needs out-of-band comms and regular tabletop practice; GDPR requires breach notification within 72 hours. Track MTTD and MTTR.