Incident Response Plan: How to Build One and Test It

Most incident response plans are written to satisfy an auditor and opened for the first time at two in the morning on the night they are needed. By then the person holding the laptop is whoever was on shift, they have never read the document, the phone number on page four belongs to somebody who left in March, and they have ten minutes to decide whether to pull a server off the network or leave it running so the forensic evidence survives. That decision is the plan. The rest is scaffolding around it.

A plan that works is shorter than the one most companies produce, and the phases it runs on are published free by NIST and CISA. What confuses people is that different sources count those phases differently, which is why the two questions searched alongside this one ask for the 5 steps of incident response and the 7 steps in incident response. Both are answered below, with an honest account of why the numbers disagree.

What Is an Incident Response Plan?

An incident response plan is the operational document that turns a security incident from an argument into a procedure. It answers four questions in advance: what counts as an incident, who runs the response, what they are allowed to do without asking, and who gets notified and how fast.

Before any of that, one distinction has to be right, because plans that skip it end up either ignoring real attacks or paging the chief executive over a failed login. NIST defines an event as any observable occurrence involving computing assets: a login attempt, a software update, an application answering a request. An incident is narrower. NIST Special Publication 800-61r3 uses the statutory definition from FISMA, an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality or availability of information or an information system, or constitutes a violation or imminent threat of violation of law, security policies, security procedures or acceptable use policies. Every alert is an event. Only some events are incidents, and the plan needs a rule for telling them apart.

Three documents get muddled together, and separating them makes each one shorter:

• The policy states management's commitment, the scope, and who holds which authority, including who can disconnect, confiscate or shut down a system. It changes rarely.
• The plan describes the response process, the severity levels, the contacts and the communications approach. It is reviewed annually.
• The playbook is the step-by-step for one scenario: ransomware, a compromised mailbox, a stolen laptop. NIST describes playbooks as actionable steps for particular situations and points readers at CISA's published examples. Playbooks change most often, because attacks do.

A company with one document trying to be all three has a document nobody uses. A company whose plan says "follow the procedure" without a playbook has a plan that stops exactly where the work starts. If the first sign of trouble is a phishing message somebody reported an hour ago, the playbook is what tells the responder to pull the mail logs before resetting the password.

What Are the 5 Steps of Incident Response?

The five-step version has a checkable origin rather than a marketing one. CISA's Cybersecurity Incident and Vulnerability Response Playbooks, published in November 2021 for federal civilian executive branch agencies, sets out the incident response process in five named phases: preparation, detection and analysis, containment, eradication and recovery, and post-incident activities. A sixth section on coordination runs alongside all of them rather than after any of them.

Preparation is everything done before the phone rings, and it decides how the other four go. CISA's list covers documenting the procedures, instrumenting the environment so suspicious activity is visible at all, staffing the response, training users on how to report, and developing and testing the courses of action for containment and eradication in advance. It also names two things smaller plans forget: infrastructure for out-of-band communication, and a defined means of collecting forensic evidence.

Detection and analysis is where an alert becomes a declared incident. Declaration in the playbook means identifying an incident and telling the responders and CISA, not making a formal legal declaration. This phase establishes scope: which accounts, which systems, which data, and what the attacker did before anyone noticed.

Containment is a high priority, especially for a major incident, and the objective is to remove the attacker's access without tipping them off or wrecking the evidence. CISA notes plainly that containing an active adversary using fileless malware looks nothing like containing a ransomware attack. Its containment activities include isolating affected systems and segments, capturing forensic images, updating firewall filtering, closing ports, and rotating administrator passwords, private keys and service account secrets where compromise is suspected. The hard part is judgment: contain too early and you lose sight of the full scope, too late and the attacker moves further.

Eradication and recovery removes the artifacts and the ways back in, then returns service. CISA is specific that before eradication starts, every means of persistent access must be accounted for, containment must be sufficient and evidence must be collected, because attackers routinely hold several backdoors and will hop back into a cleaned area if the eradication is not orchestrated. Where a specific vulnerability was the way in, the document hands that half of the job to its vulnerability response playbook, which is the same remediation queue routine vulnerability scanning is meant to work through before an attacker finds it. Recovery then reconnects the rebuilt systems, tightens perimeter and access rules, tests thoroughly, and watches for signs the attacker returned.

Post-incident activity is the phase everyone skips and the only one that makes the next incident cheaper. CISA calls the review a hotwash: a lessons-learned analysis covering the effectiveness of the handling, the initial root cause, problems executing the planned courses of action, and any missing policies and procedures. It also means adding detections for the techniques the attacker actually used and filing whatever reports law and policy require.

What Are the 7 Steps in Incident Response?

The honest answer is that no standards body publishes seven steps. The seven-step lists are derived, and knowing what from tells you whether the extra step is real.

The genuine six-step model is the SANS one. The SANS Incident Handler's Handbook, written by Patrick Kral and published in February 2012, covers the six phases of the incident handling process, and SANS's own reference on incident response names them as preparation, identification, containment, eradication, recovery and lessons learned. It is the model most practitioners were taught and the ancestor of nearly every numbered list on the internet.

Seven-step lists get there in one of three ways. Some split identification into detection and analysis, which is defensible, because finding something and understanding its scope are different jobs done by different people. Some append a testing or repeat step, which is maintenance rather than a phase of a live response. Some promote notification to a phase of its own, and that version has the strongest case today, because the regulatory clock now starts during containment rather than after recovery.

Every row above describes the same work. The numbers differ because the authors drew the boundaries in different places, not because anyone found a step the others missed. A plan that names five phases and a plan that names seven will be identical in what people actually do, provided both cover preparation at one end and the review at the other.

NIST vs SANS: Which Incident Response Framework to Use

NIST answers this itself, and the answer is not the one people expect. SP 800-61r3 says organizations should use whichever incident response life cycle model suits them best, and that the model in the document is built on the Cybersecurity Framework only because so many organizations already use it.

What changed in April 2025 is worth knowing, because most articles on this subject have not caught up. SP 800-61r3 supersedes SP 800-61r2, the 2012 guide that gave the world the four-phase circular lifecycle, and replaces that circle with a model built on the six CSF 2.0 Functions: Govern, Identify and Protect cover preparing and improving, Detect, Respond and Recover cover the incident itself. NIST states the reason directly. When r2 was written, incidents were relatively rare, narrow in scope, and usually resolved within a day or two. Today they are frequent, they cause far more damage, and recovery often takes weeks or months. Response as an occasional self-contained loop run by a separate team no longer matches how it happens.

The numbers support that. In IBM's Cost of a Data Breach Report 2026, the mean time to identify and contain a breach rose to 247 days, made up of 183 to identify and 64 to contain, a 2.5 percent increase that reversed five straight years of improvement. A process designed around a two-day incident is being asked to run for eight months.

What Should an Incident Response Plan Include?

If you are working from a blank page, this is the contents list. Anything here that you cannot fill in yet is a finding in its own right.

Two of those are where plans quietly fail. The first is logging: a response cannot establish scope from data nobody collected, so the plan states what is logged, where it goes and how long it is kept, checked against the SIEM logs that exist rather than the ones the architecture diagram promises. The second is out-of-band communication. If the incident is in your email tenant, the incident bridge cannot be a thread in that tenant.

How to Write an Incident Response Plan

Nine steps, in order. A small company can complete all of them in two focused sessions; the output should be a handful of pages, not a binder.

Who Should Be on the Incident Response Team?

NIST's roles list in SP 800-61r3 is broader than the security team, deliberately. It names leadership, who oversee the response, fund it and hold decision authority on high-impact actions such as rebuilding a critical service. It names incident handlers, who verify the incident, collect and analyze evidence, prioritize the work and act to limit damage, and notes these can be on staff, on contract through a managed provider, or called in when needed. It also names technology professionals, legal, public affairs, human resources, physical security, and asset owners, who know what their systems are for and what recovery order makes sense.

NIST adds a point worth reading twice if you outsource: where a third party performs response activities, that is a shared responsibility model in which you have transferred some of your responsibilities, and the division belongs in the contract. That includes information flows, authority to act on your behalf, and the restrictions, such as whether the provider can deactivate a service to contain an incident without calling you first. Teams discover that answer during the incident more often than they should.

For a company with no dedicated security staff, the practical version collapses to four names and a phone list. One incident lead, usually the head of IT, whose real job during an incident is running the response rather than typing. One or two technical responders. One executive with authority to spend money and take services offline. And a set of external numbers: counsel, insurer, forensics, provider. If the detection half is contracted out, that is what a security operations center is being paid for, and the plan should say what they escalate, to whom, and how fast.

How to Report a Cyber Incident to CISA and Regulators

Reporting deadlines now run during the incident rather than after it, which is why the notification step belongs in the plan and not in an appendix. The clocks that apply to US organizations:

The one-hour figure is real and often misquoted as applying to everyone. CISA's federal incident notification guidelines require federal executive branch civilian agencies to report within one hour of an incident being identified by the agency's top-level CSIRT, security operations center or IT department, with seven required data elements including functional impact, recoverability, detection time and the number of affected systems, records and users. Reporting by everyone else is voluntary, and CISA wants it anyway.

The other obligation is to the people whose data was taken. The FTC's data breach response guide for business gives the sequence in three moves, secure operations, fix vulnerabilities, notify appropriate parties, and carries one instruction that belongs verbatim in every plan because the instinct runs the other way: take all affected equipment offline immediately, but do not turn any machines off until the forensic experts arrive. Powering down destroys memory-resident evidence, and with it the answer to what the attacker did. The follow-on steps your customers will need are set out in what to do after a data breach, and pointing the notification letter at them saves writing it under pressure.

How Often Should an Incident Response Plan Be Tested?

Review the document annually, and immediately after any real incident, any change of the people named in it, and any significant change to the systems it covers. Run a tabletop at least once a year, twice if you are regulated or hold a lot of personal data. Test the technical assumptions separately: restore a system from backup and time it, fail over what is supposed to fail over, and confirm the out-of-band channel works.

A tabletop is cheap. Two hours, the response team, an executive, and one scenario read out in stages by someone who prepared it. The output is not a score. It is the list of things nobody could answer, and that list is the next revision of the plan.

Companies do increasingly fund this after they have been hit. In IBM's 2026 study, 43 percent of breached organizations named incident response plans and testing as an area of increased investment, up from 35 percent the year before, second only to hiring skilled specialists. That is money spent to buy back the thing an untested plan costs you, which is time.

Why Incident Response Plans Fail

They fail for boring reasons, and the same handful recur: nobody owned the document, the contacts went stale, the severity rules were vague enough that nothing ever qualified, the logging needed to establish scope was never turned on, or the plan assumed a team the company does not employ.

Underneath all of them sits one measurable difference, which is how long the attacker had. Two of this year's reports show what that gap is worth.

The failure mode worth naming separately starts with a person rather than a machine. Where the way in was social engineering rather than an exploit, the first signal is a colleague saying something felt wrong, not an alert. If the plan has no route for that report and no expectation that it gets triaged in minutes, the detection phase does not exist for that whole class of attack.

Do Small Businesses Need an Incident Response Plan?

Yes, and the version they need is short. The reason is not compliance. It is that a small company has no slack: one person knows how the payment integration works, one backup exists, and the owner is the legal, communications and technical decision maker at once. Improvisation scales worse the smaller you are.