Incident response: the six phases, from preparation to lessons learned

Sooner or later, every organisation has a security incident: a phished account, a stolen laptop, ransomware on a file server. What separates a bad day from a disaster is rarely the attack itself. It is whether people knew what to do, who was in charge and what to do first. Incident response is the discipline of answering those questions in advance.

Two ways of drawing the same cycle

You will meet two common models. The SANS Institute’s incident handler’s handbook describes six phases, often remembered as PICERL: Preparation, Identification, Containment, Eradication, Recovery and Lessons learned. NIST’s Computer Security Incident Handling Guide (SP 800-61 revision 2) groups the same work into four phases: Preparation; Detection and Analysis; Containment, Eradication and Recovery; and Post-Incident Activity. In 2025 NIST published revision 3, which reorganises its recommendations around the six functions of the NIST Cybersecurity Framework 2.0. The steps are the same work; only the grouping differs.

1. Preparation

Preparation is everything you do before the incident: an up-to-date contact list, a written plan with clear roles, logging turned on and kept, backups tested, and playbooks for the incidents you expect most (phishing, ransomware, a lost device). It also means practice: tabletop exercises where the team talks through a scenario and discovers, safely, that nobody knows who can shut down the VPN at 2 a.m.

2. Identification

Something looks wrong: an alert, a user report, a strange bill from a cloud provider. Identification means confirming whether it is a real incident, how serious it is and what is affected. The key discipline here is to write everything down with timestamps from the first minute, because early notes become the timeline everyone relies on later.

3. Containment

Containment stops the damage from spreading while you work out the rest. Short-term containment might mean disconnecting a laptop from the network, disabling a compromised account or blocking an attacker’s address at the firewall. The tension here is real: acting too fast can destroy evidence or tip off the attacker; acting too slowly lets them move further. A good plan says in advance who is allowed to make that call.

4. Eradication

Once the incident is contained, you remove what the attacker left behind: malicious files, persistence mechanisms, rogue accounts, stolen credentials. Eradication is only as good as your understanding of the scope. If you clean one machine but miss the second one the attacker also reached, they come back.

5. Recovery

Recovery brings systems back to normal: restoring from clean backups, rebuilding machines, resetting passwords and watching closely for signs that the attacker is still present. For ransomware, this is where tested, offline backups turn a crisis into an inconvenience.

6. Lessons learned

Within a couple of weeks, the people involved meet to review what happened, without looking for someone to blame. What let the attacker in? What slowed the response? Which detection would have caught it earlier? The output is a short list of concrete changes, and it feeds straight back into preparation. Skipping this phase is the most common way organisations get hit twice by the same thing.

Beyond the technical work

• Legal and regulatory duties: some incidents must be reported to authorities or to affected people within strict deadlines, for example under the GDPR in Europe.
• Communication: one person speaks for the organisation, and staff know not to post about the incident publicly.
• Outside help: know in advance which incident response firm, insurer or national CERT you will call.