How to Write an Incident Response Plan (NIST SP 800-61r3)

An incident response plan has to answer six questions, and it can do it in about ten pages: what counts as an incident, who holds which role and who backs them up, how the team reaches each other when the email tenant is compromised, who may take a revenue-generating system offline without asking permission, which regulatory clocks a given fact pattern starts, and how the lessons get back into the document. The authoritative reference changed in April 2025: NIST SP 800-61 Revision 3 supersedes SP 800-61r2 from August 2012 and reorganizes incident response around the six CSF 2.0 Functions instead of the old four phases. Here is the contrarian part, and it is NIST's own position rather than ours: Revision 3 does not order you to throw the four phases away. It states that organizations "should use the incident response life cycle framework or model that suits them best." The thing that makes a plan work is not which model it borrows. It is whether a named person has written authority to unplug production at 3 a.m.

This guide walks through what actually changed in the standard, the six questions, what NIST puts in the policy rather than the plan, and the two sections that separate a plan that gets used from one that gets filed.

Key takeaways

• SP 800-61r3 was published in April 2025 and supersedes SP 800-61r2 (August 2012). Pages still teaching the four-phase lifecycle as current NIST guidance are citing a withdrawn edition.
• Revision 3 maps the old phases onto the six CSF 2.0 Functions: Govern, Identify, Protect, Detect, Respond, Recover. Preparation becomes Govern, Identify and Protect; post-incident activity becomes the Improvement Category inside Identify.
• NIST is explicit that the model is a choice, not a mandate. A four-phase plan that works is better than a six-Function plan nobody has read.
• The plan and the policy are different documents. NIST lists what belongs in the policy, and most of what people try to cram into a plan belongs there instead.
• Two sections decide whether the plan survives contact with a real incident: an out-of-band communications tree, and a named containment authority with a spending limit.

What actually changed in April 2025

The 2012 guidance described incident response as a circular lifecycle of preparation, detection and analysis, containment/eradication/recovery, and post-incident activity, performed by a dedicated team. Revision 3 says that picture assumed conditions that no longer hold. In its own words, at the time of the earlier model "incidents were relatively rare, the scope of most incidents was narrow and well-defined, and incident response and recovery was usually completed within a day or two." Today, the document continues, "incidents occur frequently and cause far more damage. Recovering from them often takes weeks or months due to their breadth, complexity, and dynamic nature."

So Revision 3 reframes incident response as part of cybersecurity risk management rather than a separate discipline, and organizes it around the six CSF 2.0 Functions: Govern (strategy, expectations and policy), Identify (understanding your risks), Protect (safeguards in use), Detect (finding and analyzing compromises), Respond (acting on a detected incident), and Recover (restoring assets and operations). The document draws a line through the middle of that set: Govern, Identify and Protect are preparation and are not part of the response itself, while Detect, Respond and Recover are the response.

The change that matters most to a plan author is where lessons learned went. In the old model, post-incident activity was the closing phase that fed the next cycle. In Revision 3 it becomes the Improvement Category (ID.IM) inside Identify, drawing from every Function continuously, because as NIST puts it, "the lessons learned during incident response should often be shared as soon as they are identified, not delayed until after recovery concludes." That is a scheduling instruction disguised as a taxonomy change, and it is covered in more depth in our guide to running a post-incident review.

None of this obliges you to rewrite a working plan. Revision 3 provides a mapping table precisely so that a four-phase plan can be read against the new structure without being torn up, and it says the right model "depends on many factors," noting that larger and more technology-dependent organizations tend to benefit more from a model emphasizing continuous improvement.

The six questions your plan has to answer

One: what counts as an incident

Write the activation criteria as observable conditions, not adjectives. "Any confirmed unauthorized access to a production database," "any ransom demand received by any employee," "any alert indicating credential use from an impossible location for a privileged account." A severity scale with three or four levels, each with a named notification list, is enough. A plan whose trigger is "a serious security event" activates late, because nobody wants to be the person who declared an incident that turned out to be a false alarm.

Two: roles, and the backup for each role

Incident commander, technical lead, communications owner, legal liaison, scribe. NIST's own role list is broader than most plans assume, naming leadership with decision-making authority on high-impact actions, incident handlers who may be on staff or on contract, technology professionals, legal, public affairs, human resources, physical security and asset owners. The half of this nobody writes down is the backup. Incidents begin at inconvenient hours, and your incident commander is on a plane roughly a fifth of the time.

Three: how you talk when the tenant is compromised

Covered below, because it is the section most often missing.

Four: who can take things offline

Also covered below, for the same reason.

Five: which clocks start

The plan does not need to reproduce the whole regulatory map, but it needs the trigger events and the person who owns the analysis. Our breach notification deadlines guide walks through the regimes and, more importantly, the trigger events that start each one, because those differ even when the deadlines look similar.

Six: how the plan improves

A named review cadence, a named owner, and the loop from the post-incident review back into the document. NIST's ID.IM-04 asks that incident response plans "are established, communicated, maintained, and improved," and its recommendations include reviewing and updating cybersecurity plans "periodically or when a need for significant improvements is identified."

What NIST puts in the policy, not the plan

Plans get bloated because authors put governance material in them. Revision 3 separates the two cleanly. The elements it lists for an incident response policy are a statement of management commitment, the purpose and objectives, the scope (who and what it applies to, and under what circumstances), definitions of events, incidents and investigations, roles and responsibilities and authorities including which roles may "confiscate, disconnect, or shut down technology assets," guidelines for prioritizing incidents and estimating severity, and performance measures.

Read that list against your current document. If your plan opens with four pages of management commitment and definitions, that is policy content, and moving it out makes the plan usable at 3 a.m. What remains in the plan is the roadmap for implementing the capability. What sits under the plan is procedures, which NIST describes as documentation explaining how technical processes should actually be performed, testable, and useful for training new staff.

The communications tree that assumes email is compromised

Write the escalation tree on the assumption that your corporate email and chat are readable by the attacker, because in a domain-compromise scenario they are. That means the tree needs personal phone numbers, an agreed out-of-band channel, and a rule that the first message on the corporate tenant after activation is nothing more than a request to move.

Three details make the difference between a tree that works and a list of names. Store it somewhere that survives the outage, which means printed and in a personal password manager, not only in the wiki hosted on the environment that is down. Include external parties in the same tree: your cyber insurer's claims hotline, outside counsel, your response firm, and your critical vendors, with the account numbers each will ask for. And put the numbers in the hands of the people who will need them before they need them, because a tree that lives only in the plan is a tree the on-call engineer cannot reach at 3 a.m.

Containment authority, the paragraph nobody writes

Here is the section we most often find missing, and the one that costs the most when it is. Somebody has to be allowed to take production offline, isolate a subnet, disable a customer-facing integration, or lock every privileged account, immediately, without convening a meeting.

Write it as three sentences. Name the roles that hold the authority, by role and not by person. State the ceiling: what they may do unilaterally, and what requires the incident commander or an executive. And state the spending limit, because containment usually costs money before anyone has approved a budget, and a responder who has to wake up a CFO for a purchase order is a responder who is not containing anything.

The reason this matters more than the model you pick is that hesitation is the expensive failure mode. NIST's policy elements include exactly this: roles, responsibilities and authorities, "such as which roles have the authority to confiscate, disconnect, or shut down technology assets." Most plans quote the sentence and never name the roles.

Where the plan stops and playbooks start

The plan is the roadmap. Playbooks are the turn-by-turn directions for the incident types you actually see: business email compromise, ransomware, a compromised cloud access key, a lost laptop with regulated data, a vendor breach that reaches you. NIST recommends documenting procedures for the most common incident types rather than attempting to cover every situation, and it points readers to CISA's incident and vulnerability response playbooks as examples.

Two practical rules. Write playbooks for the four or five scenarios that describe most of your realistic incidents, and write them as steps with owners, not as narrative. And do not let a playbook contradict the plan on authority or notification; when they diverge, the person following the playbook at 2 a.m. wins, which means the error ships.

When writing a plan is not your bottleneck

We do this work, so weigh this section accordingly. There are three situations where paying a consultancy to write your plan is the wrong purchase.

You already have a plan and have never exercised it. A tabletop against the plan you have will find more than a rewrite will, and it costs less. A plan nobody has walked through is a document, not a capability.

Your logging cannot support the plan you would write. If endpoint telemetry and authentication logs roll over in a week, or were never centralized, no plan makes the investigation tractable. Spend the money on retention first. The plan can wait a quarter; the logs you did not keep are gone permanently.

You are under about 25 people, fully cloud-hosted, with no regulated data. Write a two-page version yourself: activation criteria, five phone numbers, the out-of-band channel, containment authority, and who calls the insurer. That document, actually rehearsed, beats a thirty-page plan you bought and filed.

Where Top Floor fits

Our incident response work covers the plan, the playbooks for your realistic incident types, and the exercise that proves the escalation tree resolves to people who answer. Where the plan is being written to satisfy an auditor as much as an attacker, it sits inside compliance as a service, because the same evidence has to satisfy the control as well as the crisis. And where the gap is that nobody owns the cadence, a vCISO holding the review schedule and the annual exercise is usually the cheaper fix than a bigger document.

How to decide this week

1. Open your current plan and find the sentence naming who may take production offline. If it is not there, that is this week's edit.

2. Print the escalation tree and call two numbers on it at random. A tree that resolves to a voicemail box nobody monitors is the failure you want to find on a Tuesday.

3. Check whether your plan cites the four-phase model as current NIST guidance. If it does, add a line mapping your phases to the six Functions rather than rewriting the document.

4. Move the management-commitment and definitions material into a policy document, and see how much shorter the plan gets.

5. Pick the four incident types you have actually seen in the last three years and schedule one playbook each, one per month.

Frequently asked questions

Does NIST SP 800-61r3 require abandoning the four-phase incident response lifecycle?

No. Revision 3 proposes a lifecycle model based on the six CSF 2.0 Functions and provides a table mapping the earlier phases onto them, but it states directly that organizations "should use the incident response life cycle framework or model that suits them best," and that the appropriate choice depends on factors including the organization's size and technology dependence. What changed is the reference edition: Revision 3, published April 2025, supersedes Revision 2 from August 2012, so a plan claiming the four phases are current NIST guidance is citing a withdrawn document even though the phases themselves remain a defensible way to organize a plan.

How long should an incident response plan be?

Roughly ten pages for a company under a few hundred people, with procedures and playbooks living in separate documents beneath it. Length is a symptom rather than a goal: plans balloon when policy material (management commitment, definitions, scope) and step-by-step procedures both get pulled into the same file, and NIST separates all three deliberately. The practical test is whether someone woken at 3 a.m. can find the activation criteria, the escalation tree, and the containment authority inside two minutes.

Who should own the incident response plan?

One named role, with an executive sponsor who can enforce the exercise schedule. In most mid-market companies that owner is the head of security or the person acting as it, and where nobody holds that seat a fractional security lead is the usual answer. What does not work is joint ownership between IT and compliance, because the plan then optimizes for the audit rather than the incident, and the containment-authority paragraph is exactly the section that quietly goes missing when nobody feels entitled to write it.