An incident response plan is a written, senior-approved document that tells an organisation exactly how to detect, contain, and recover from a cyber security incident. Its purpose is to limit damage, restore normal operations quickly, and preserve evidence throughout the process. Most plans structure this work around a recognised lifecycle: preparation, detection and analysis, containment, eradication, recovery, and lessons learned.
TL;DR:
- Incident response plans must integrate with overall cybersecurity governance and be signed off by senior leadership to ensure authority during an incident.
- Clear scope definition is critical, requiring understanding of key assets, threats, and sector-specific risks before writing detailed playbooks.
- Response should follow a six-phase lifecycle, including preparation, detection, containment, eradication, recovery, and lessons learned, with roles and thresholds explicitly documented.
- Effective plans include precise decision triggers, offline contact lists, incident-specific playbooks, and metrics to measure response effectiveness and improvements.
- When incidents involve advanced threats or legal risks, involving forensic specialists early preserves evidence properly and supports forensic analysis and court readiness.
Table of Contents
- What is an incident response plan and how does it fit with business continuity?
- What are the six phases of the incident response lifecycle?
- What should every incident response plan include?
- How do you create an incident response plan step by step?
- How do you test and exercise an incident response plan?
- How should evidence be preserved during an incident response?
- When should you call in a digital forensics specialist?
- Where incident response plans usually fall apart
- How Computer Forensics Lab supports incident response
- Sources
- FAQ
What is an incident response plan and how does it fit with business continuity?
An incident response plan (IRP) is the operational document that governs how an organisation reacts once it suspects or confirms a cyber security incident. It names the people responsible for making decisions, sets out the procedures they follow, and defines when and how the organisation communicates with staff, customers, regulators, or law enforcement. According to CISA’s Incident Response Plan Basics, an effective plan requires formal sign-off from senior leadership, not just approval from the IT department, because incidents routinely force decisions that carry legal, financial, and reputational weight.
Governance matters here more than most organisations expect. A plan buried in a shared drive that nobody in the boardroom has read is not really a plan; it is a draft waiting for a crisis to expose its gaps. NIST’s 2025 revision to SP 800-61 makes this explicit by folding incident response into wider cybersecurity governance rather than treating it as a standalone IT procedure. A plan that sits disconnected from risk management, asset inventories, and business priorities tends to fail exactly when it is needed most.
Scope is the second thing organisations get wrong. Before writing a single playbook, you need a clear picture of what you are protecting: which systems hold sensitive data, which suppliers touch your network, and which threats are realistic for your sector. A small accountancy practice faces a different threat model to a hospital trust or a logistics firm, and a plan written from a generic template rarely reflects that.
It helps to separate an IRP from two related documents it often gets confused with. A business continuity plan (BCP) covers how the whole organisation keeps functioning during any disruption, whether that is a cyber attack, a flood, or a pandemic. A disaster recovery plan (DR) focuses specifically on restoring IT systems and data after a major failure. The incident response plan sits inside this wider family but deals specifically with security incidents: detecting them, containing the damage, and working out what happened.
In practice, the three plans need to talk to each other. If a ransomware attack takes down a finance system, the IRP governs how you detect, contain, and investigate the attack, while the BCP dictates how finance keeps operating on manual processes in the meantime, and the DR plan governs how the finance system itself gets rebuilt. Organisations that draft these in isolation often find, mid-incident, that nobody agreed which document takes priority when their instructions conflict.
What are the six phases of the incident response lifecycle?
Most incident response models describe six phases, though some frameworks compress them into five by folding containment and eradication together. NIST SP 800-61 Revision 3 reorganises the traditional lifecycle around the newer CSF 2.0 functions, placing preparation within broader governance activity and giving sharper focus to Detect, Respond, and Recover as the operational core. Whichever model you use, the underlying activities are largely the same.
Preparation. This is where policies, tools, contact lists, and training happen before anything goes wrong. Security teams build detection capability, IT staff harden systems, and everyone with a role in the plan knows what that role involves. Preparation also includes deciding who has authority to declare an incident and who signs off major decisions like paying a ransom or notifying a regulator.
Detection and analysis. Someone, or something, notices unusual activity, whether that is a SIEM alert, a user reporting a suspicious email, or a third party flagging leaked data. Analysts then work out what actually happened: what was accessed, how the attacker got in, and how serious the incident is. This phase often takes longer than people expect, and rushing it leads to containment decisions based on incomplete information.
Containment. The goal is to stop the incident spreading without destroying evidence or making recovery harder. Short-term containment might mean isolating an infected machine from the network within minutes. Long-term containment could mean rebuilding affected systems on clean infrastructure while investigators continue examining the compromised originals.
Eradication. Once the immediate threat is contained, the team removes the root cause: malware, backdoors, compromised accounts, or the vulnerability that let the attacker in. Skipping or rushing this step is one of the most common reasons organisations suffer repeat incidents within weeks of the first one.
Recovery. Systems are restored, monitored closely for signs of reinfection, and gradually returned to normal operation. Recovery decisions, such as when to bring a system back online, should sit with someone senior enough to weigh business pressure against residual risk.
Lessons learned. A structured review captures what worked, what didn’t, and what needs to change in the plan itself. CISA highlights blameless post-incident retrospectives as the mechanism that actually turns an incident into organisational learning rather than into a search for someone to blame.
Some organisations fold containment and eradication into a single “response” step, producing a five-phase model instead of six. The distinction matters less than making sure every activity above is genuinely assigned to someone and tested before it is needed for real.
What should every incident response plan include?
A plan that only describes phases in the abstract will not help anyone at 2am during a live breach. It needs concrete, checkable content that a responder can act on without having to improvise decisions under pressure. TechTarget’s practical breakdown frames this as a checklist rather than a narrative, and that framing holds up well in practice.
- Roles and responsibilities, including a named incident manager who coordinates the response and communications, separate from a technical lead who makes containment and remediation decisions.
- Incident categories and severity levels, so a phishing email that got clicked once is not treated the same way as active data exfiltration.
- Decision triggers with concrete thresholds. According to CISA’s guidance on IRP basics, plans should specify exact conditions for escalation, such as a defined volume of exfiltrated data, a regulatory reporting deadline, or an outage lasting beyond a set duration, so responders are not debating whether to act while the clock runs.
- Contact lists kept offline or independently accessible, because email, chat, and shared document platforms are often exactly what an incident takes offline first.
- Playbook templates for priority scenarios, covering the incidents most likely to hit your organisation, such as ransomware, business email compromise, or a lost or stolen device holding client data.
- Communications and notification criteria, defining who tells customers, regulators, insurers, or law enforcement, and under what legal triggers.
- Evidence handling procedures and a documentation standard, so every action taken during the incident is timestamped and recorded for later investigation or litigation.
- Metrics for measuring effectiveness, such as time to detect, time to contain, and time to full recovery, tracked across incidents so the organisation can see whether its response is genuinely improving.
Pro Tip: Print a paper copy of your incident manager’s contact tree and store it somewhere physically accessible, not just in a cloud folder. During a ransomware incident that encrypts file servers, your own documentation can become one of the first casualties.
A checklist like this only earns its place if someone actually reviews and updates it. Plans drift out of date as staff leave, systems change, and new regulatory obligations appear, so treat the checklist as a living document rather than a one-off deliverable.
How do you create an incident response plan step by step?
Building an incident response plan from scratch, or overhauling one that has gathered dust, follows a fairly consistent sequence regardless of organisation size. NIST’s earlier Computer Security Incident Handling Guide laid out much of this practice, and later revisions build on it rather than replacing it.
Identify your critical assets and realistic threat scenarios. Map the systems, data, and third-party connections that matter most, then work out which threats genuinely apply to your organisation. A retailer worrying primarily about industrial espionage is solving the wrong problem; card data theft and point-of-sale compromise are far more likely.
Set incident criteria and escalation thresholds. Define what counts as an incident at all, and at what point a low-severity issue becomes a high-severity one requiring senior notification. Vague thresholds are one of the most common reasons responses stall in the first hour.
Assign roles and draft playbooks for your top scenarios. Name an incident manager to handle coordination and communications, and a technical lead to make containment calls, deliberately as two different people. Then write scenario-specific playbooks: what happens, step by step, if ransomware is detected, if a laptop with client files goes missing, or if an employee is suspected of exfiltrating company data.
Get formal sign-off from senior leadership. This is not a formality. Whoever approves the plan is implicitly agreeing to the authority it grants responders, including decisions about system shutdowns, public communications, and spending on external help.
Prepare secure, out-of-band communications and offline plan copies. As CISA notes, keeping an independently accessible copy of the plan and contact list matters because the very systems you rely on for communication are often the ones an incident disables.
Train the team, run exercises, and revise based on what you learn. A plan that has never been tested is a hypothesis, not a capability; effective staff training and communications strategy are essential for incident response readiness. Run a tabletop exercise, capture what broke down, assign someone to fix it, and update the document before the next drill.
For organisations without an existing document to work from, a written incident response plan template built around these six steps gives a faster starting point than drafting every playbook and contact list from a blank page. It still needs tailoring to your specific assets and threat model, but it removes the blank-page problem that stalls most first attempts.
How do you test and exercise an incident response plan?
A plan is only as good as the last time someone tried to follow it under pressure, which is why testing deserves its own discipline rather than an annual tick-box exercise. Different exercise types test different things, and confusing them wastes effort.
- Tabletop exercises walk participants through a scenario verbally, discussing decisions without touching live systems. These are cheap to run and good for testing decision-making and communication chains.
- Live-play or functional exercises involve actually executing parts of the response, such as failing over to backup systems or actually calling the incident hotline, which surfaces practical problems tabletops miss.
- Red-team exercises simulate a real attacker probing your defences without warning most of the organisation, testing whether detection and response actually work against realistic tradecraft rather than a scripted scenario.
NCSC’s guidance on planning incident responses stresses that exercises need measurable objectives defined in advance, not a vague intention to “see how it goes.” Decide what you are actually testing, whether that is time to detect, clarity of escalation decisions, or whether the incident manager and technical lead avoid stepping on each other’s authority, and measure against that.
One detail organisations consistently skip is testing the notification and convening mechanism itself, separately and early, rather than assuming it during a bigger drill. If your incident manager’s first job is texting five people, test that texting chain on its own before building a scenario around it. NCSC’s exercise creation guidance makes the same point: exercises should be judged by whether they change behaviour and process, not by whether a document technically exists.
After any exercise, record participant feedback, assign a named owner to each recommendation, and set a date to re-test. Exercises that generate a list of findings nobody owns tend to generate the same findings again next year.
How should evidence be preserved during an incident response?
Preserving evidence correctly during an active incident often matters as much as containing the threat itself, particularly if the incident later ends up in a regulatory inquiry, an insurance claim, or a courtroom. CISA’s federal incident and vulnerability response playbooks recommend collecting perimeter, network, and endpoint logs, along with memory and disk images where forensic analysis may be required, backed by a detailed evidence log recording who collected what, when, and how.
The single most damaging mistake organisations make under pressure is wiping or reimaging affected systems before anyone has captured a forensic image. It feels like the fast route back to normal, but if evidence might be needed later, that decision can permanently destroy the ability to prove what happened, who did it, or how the attacker got in. CISA’s playbook guidance is direct on this point: when evidence may be required, containment actions must be coordinated with forensic preservation steps, and every action taken should be timestamped and recorded to protect its evidentiary value.
Pro Tip: If you are not certain whether an incident will end up in litigation or a regulatory investigation, treat it as if it will. You can always decide evidence wasn’t needed later; you cannot un-wipe a drive.
Maintaining chain of custody, a documented record of who has handled evidence and when, is what separates evidence that holds up under scrutiny from evidence a court or regulator can dismiss. Computer Forensics Lab’s guidance on preserving chain of custody sets out the practical standard organisations should aim for even before a specialist arrives.
Certain triggers create legal obligations around preservation and notification that plans need to name explicitly rather than leaving to judgement calls mid-incident. Data protection law in most jurisdictions imposes strict notification deadlines once personal data has been compromised, and sector regulators often add their own reporting windows on top. A plan that doesn’t name these triggers in advance risks discovering the deadline has already passed by the time someone checks.
When should you call in a digital forensics specialist?
Certain incidents are beyond what an internal IT or security team should handle alone, and recognising that moment early protects both the investigation and the organisation’s legal position. Litigation, suspected employee misconduct, law enforcement involvement, sophisticated or unfamiliar malware, and any sign that data or logs have been deliberately destroyed are all situations where bringing in a specialist changes the outcome rather than just adding cost.
Digital forensics specialists provide forensically sound imaging of devices and storage, structured evidence handling that maintains chain of custody, and, where needed, an expert witness report that can withstand challenge in court. That last point matters more than it might seem: an internal IT report written under pressure rarely holds up the same way a peer-reviewed, court-ready report does when a case is contested.
Before a forensic team arrives, preserve what you can without altering it further. Avoid powering devices off if they are already off, avoid logging into affected accounts unnecessarily, and note down timestamps, actions already taken, and anyone who has touched the affected systems. Having asset inventories, network diagrams, and existing log data ready to hand over speeds up the engagement considerably and reduces the risk of the investigation missing something because nobody could explain what “normal” looked like on that network.
Where incident response plans usually fall apart
The plans that fail under pressure are rarely the ones missing a phase or a template. They fail because of structural mistakes that look fine on paper. A single point of failure, one person who holds all the contact details or the only login to the incident tracker, turns a bad incident into a worse one the moment that person is unreachable. Offline access to the plan itself gets treated as optional until the very systems hosting it are the ones under attack.
The other recurring error is collapsing coordination and technical decision making into one role. Separating the incident manager from the technical lead, as CISA’s guidance recommends, keeps communications moving while technical judgement gets made without distraction. Pair that with genuinely blameless retrospectives, focused on root causes and fixes rather than fault, and a plan starts improving with every incident instead of just surviving each one.
— Computer
How Computer Forensics Lab supports incident response
When an incident moves beyond what internal teams can safely handle, specialist providers can offer forensic imaging and analysis of computers, mobile devices, and cloud data, structured evidence handling that maintains chain of custody throughout, and expert witness reports built to withstand scrutiny in litigation or regulatory proceedings.
On first instruction, clients typically receive a clear scope of work, an assessment of what evidence exists and how urgently it needs preserving, and a realistic timeline for imaging and analysis before anything else moves forward. If your organisation is mid-incident, or drafting a plan and wants specialist input on the evidence-handling sections, Computer Forensics Lab’s specialist digital forensics services outline what an engagement involves, and you can get in touch through the main services page to discuss your situation directly.
Sources
The standards and government guidance referenced throughout this article are worth reading in full if you are drafting or revising a plan.
- Incident Response Plan (IRP) Basics | CISA
- Planning your response to cyber incidents | NCSC
- What is incident response? | TechTarget
FAQ
What does an incident response plan include?
An incident response plan includes defined roles and responsibilities, incident categories and severity levels, escalation thresholds, communications procedures, playbooks for likely scenarios, and evidence-handling standards. CISA’s IRP Basics guidance also requires senior leadership sign-off and regular testing as core components, not optional extras.
What are the five steps of incident response?
Some frameworks describe five steps by combining containment and eradication into one stage, while others separate them into six phases: preparation, detection and analysis, containment, eradication, recovery, and lessons learned. The activities are the same either way; only the grouping differs between frameworks.
How do I create an incident response plan?
Start by identifying your critical assets and realistic threats, then set clear escalation criteria, assign an incident manager and technical lead as separate roles, and draft scenario-specific playbooks. Get formal senior sign-off, prepare offline copies of the plan and contact lists, and run exercises regularly to refine it, following the sequence CISA and NIST both recommend.
What are the four stages of an incident response plan?
Four-stage models typically group the work as preparation, detection and analysis, containment and eradication combined, and recovery, sometimes folding lessons learned into recovery as well. It is a compressed version of the same six activities most detailed frameworks, including NIST SP 800-61 Revision 3, describe separately.
Does Computer Forensics Lab help organisations after an incident?
Yes. Computer Forensics Lab provides forensic imaging, evidence preservation, and expert witness reporting for organisations dealing with data breaches, suspected misconduct, or incidents likely to involve litigation or regulatory review. Current service details are available on the main services page.