This page is part of our guide to building an incident response plan, which sets out the eight steps, where to store the plan and how to test it. Here we cover the phases a response follows and what each section of the plan must contain. For scenario playbooks, see incident response playbooks.
The six phases of incident response
NIST Special Publication 800-61 is the most widely used reference for incident response. Revision 2 (2012) described a four-phase lifecycle: Preparation; Detection and Analysis; Containment, Eradication and Recovery; and Post-Incident Activity. Revision 3, published in April 2025, replaces it. It places incident response inside the six functions of the NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond and Recover) and treats preparation and improvement as continuous risk management rather than one-off phases.
For operational procedures, most practitioners still work through the six steps below, with containment and eradication handled separately. They apply across incident types, from a compromised email account to a full ransomware deployment.
1
Preparation
Everything that happens before an incident occurs. Documenting roles and responsibilities, building escalation paths, maintaining a current contact list, inventorying critical assets and their recovery priorities, defining what constitutes a notifiable incident, training staff to recognise and report suspicious activity, and testing backups under realistic conditions. Preparation is the only phase where time pressure does not exist. It is also the phase most organisations defer indefinitely.
2
Detection and Analysis
Identifying that an incident has occurred and determining its nature, scope, and severity. This requires centralised logging and alerting capable of correlating events across systems. Many organisations discover breaches through external notification, from a customer, a business partner, a bank, or law enforcement, rather than internal detection. That gap can mean weeks or months of attacker activity going unnoticed inside the environment. Better detection shortens the time between an attack starting and someone recognising it. Where to invest depends on your existing visibility, your likely attack paths and your team's capacity to act on alerts.
3
Containment
Limiting the spread and impact of the incident without destroying forensic evidence. Short-term containment isolates affected systems immediately. Long-term containment restores limited functionality while keeping the compromised environment isolated. Attackers move fast: CrowdStrike's 2026 Global Threat Report puts the average eCrime breakout time, from initial access to moving on to other systems, at 29 minutes. The containment decision requires pre-defined authority. Who can authorise taking a production system offline during business hours? That question should have a named answer before the incident, not during it.
4
Eradication
Removing the threat from the environment: malicious code, compromised accounts, backdoors and persistence mechanisms left by attackers. Eradication without thorough forensic analysis risks incomplete removal. Incomplete removal leads to re-infection. For ransomware specifically, returning to operations on infrastructure that still contains the initial access vector or attacker tooling results in a second, often faster, encryption event.
5
Recovery
Restoring normal operations. This is where backup integrity is tested against real conditions: can the organisation restore to a usable state within its maximum tolerable downtime? Recovery includes monitoring for re-infection, extra logging to catch the attacker if they come back, and validating that affected systems are functioning correctly before returning them to production. Without that monitoring, an attacker who kept a foothold can undo the recovery.
6
Post-Incident Activity
The structured review conducted after the incident is resolved: what happened, how was it first detected, what worked, what failed, what needs to change in the plan, the controls, or the environment. Post-incident reviews are the primary mechanism through which response capability improves. Organisations that skip this step because the team is exhausted tend to repeat the same mistakes in the next incident.
What your plan must contain
A plan that cannot be executed under pressure is not a plan. The following elements are the minimum for a functional document.
Scope and objectives
What types of incidents the plan covers, what the organisation's response goals are (minimise operational impact, meet legal notification obligations, preserve forensic evidence, protect reputation), and what is explicitly out of scope. A plan that tries to cover every possible situation in equal detail often covers none of them usefully. Start with the incident types your organisation is most likely to face.
Roles, responsibilities, and authority
Named individuals for each role with a named backup for each. Defined authority: who can declare a formal incident, who can authorise containment actions including taking systems offline, who can approve external communications, who can authorise a payment decision. Without defined authority, decisions escalate to whoever is most senior and available, which may not be the right person and will be slower.
Escalation paths and external contacts
Internal escalation: who gets called first, who gets called if they are unreachable, at what severity level does the board get notified. External contacts: legal counsel (with 24/7 emergency number), cyber insurance (policy number, claims number, insurer's IR retainer contact if included), incident response or managed detection and response provider if applicable, critical suppliers and cloud providers (account references and support escalation routes), your data protection regulator and any sector regulator, your national cyber security agency, and law enforcement. In the UK that means the ICO, the NCSC and Action Fraud; in the US, CISA and the FBI's IC3; in the Netherlands, the Autoriteit Persoonsgegevens and the NCSC-NL. A contact list that lives only inside the email system is unusable when the email system is compromised. Agree an out-of-band channel, such as personal mobiles or a separate messaging service, for when corporate email or identity services are down. Agree too how responders confirm each other's identity on that channel, for example a call-back to a number already on the contact sheet, because an attacker reading your email can see the plan and try to join the conversation.
Communication protocols
Separate protocols for internal and external communication. Who communicates to staff, and what they are authorised to say. Who communicates externally, to customers, suppliers, the press, and regulators, and what requires legal approval before sending. Improvised external communications during an incident create legal and reputational exposure that outlasts the technical impact. Pre-drafted templates for common notifications reduce decision time and error under pressure.
Incident classification
A severity scale (P1 to P3, or Critical, High and Medium) with clear criteria for each level, a response target and an escalation path. Without one, every incident gets the same treatment, which wastes effort on minor events and under-resources major ones. The example below is a starting point to adapt.
| Level | Examples | Response target | Who is told |
|---|---|---|---|
| P1 Critical | Ransomware spreading; confirmed theft of personal or sensitive data; a critical service down; compromise of an administrator account or the identity system | Immediately, at any hour | Incident lead, executive sponsor, legal and data protection lead; board briefed the same day |
| P2 High | Compromise confirmed but contained to one system or account; suspected data exposure under investigation; an incident at a critical supplier that affects you | Within 1 hour, at any hour | Incident lead and technical lead; data protection lead if personal data may be involved |
| P3 Medium | Malware caught on one device; a phishing click where the password was reset at once; a policy breach with no sign of harm | Within 4 working hours | Security or IT team; incident lead informed |
These are illustrative internal targets, not legal deadlines. Severity can go up or down as evidence comes in; record each change and the reason in the decision log. Whether a regulator must be told is a separate test against each law's own threshold. A P3 can still be a reportable personal data breach, for example an email containing health information sent to the wrong person.
Recovery priorities and dependencies
The critical services, the systems and suppliers each one depends on, and the order in which they come back. Record a recovery time objective (RTO) and recovery point objective (RPO) for each, matching the targets in your business continuity and disaster recovery plans, so the recovery team is not setting priorities in the middle of an incident. Agree the handoff to your disaster recovery and business continuity plans: who decides a system is clean enough to restore, and which disk images and logs the forensic team needs kept before anything is rebuilt.
Decision and evidence log
A running record, kept outside the affected environment from the first hour: what was decided, who authorised it, when, what evidence was available at the time, and what action followed. It supports the forensic investigation, answers insurer and regulator questions, and feeds the post-incident review. It also shows the regulator that decisions were made on a reasonable basis, even where hindsight suggests a different call.
Critical supplier register
The suppliers whose failure would stop a critical service, and for each one: what it runs for you, what data it holds, what access it has into your systems, how you reach it out of hours, what the contract says it must tell you and how fast, and the workaround if it goes down. Keep it short enough to use in a crisis and store it with the offline copy of the plan. A supplier that holds your data or can log in to your systems belongs on the list even if its service looks minor. If you have already tiered your suppliers, the Tier 1 list is the starting point.
Closure criteria and sign-off
The conditions for closing an incident: the attacker's access is removed and monitoring has shown no return for an agreed period, affected systems are restored and their owners have confirmed they work, every notification has been made or the decision not to notify is recorded, evidence is retained, and the post-incident review is booked. Name who signs the incident off as closed, usually the incident lead together with the executive sponsor. Without that, incidents drift open for weeks or close before the attacker is gone.
About the author
Lead Consultant, Cyvra · CISM · CompTIA Security+ · MCP
Ryland has delivered cybersecurity, compliance, and IT management programmes for regulated organisations across the UK and the Netherlands for over 20 years. View full profile