How to Write an Incident Response Plan People Can Use in the First Hours

An incident response plan is a written document, approved by senior leadership, that tells your organization who does what before, during and after a suspected or confirmed security incident. In our view, it holds up in a real incident only when, for every decision that stalls the response, it names one person, one backup, the limit of what that person may approve alone, and how fast they must be reached. The definition follows CISA's, which also says the plan should clarify roles and responsibilities and list the key people you will need in a crisis.

This guide is for the security lead or IT director who will also run the incident, and for the CISO who has to show the plan to a board or an insurer. You will be able to rewrite a template-derived plan around decisions, and you can fill in and download your own plan at the end.

What is the difference between a policy, a plan and a playbook?

The policy grants authority, the plan names who holds it tonight, and the playbooks hold the steps for one scenario. Keeping the three apart stops the plan from turning into a 60-page document nobody opens at 3 a.m.

NIST draws the same line. It lists "which roles have the authority to confiscate, disconnect, or shut down technology assets" among the elements of an incident response policy, says procedures should rest on "the incident response policy and plan," and describes playbooks as "actionable steps or tasks for people to perform during various scenarios." In our view, that leaves the plan one job the policy cannot do: say which named role holds each authority right now, who covers for them, what the limit is, and how to reach them. Scenario steps belong elsewhere, for example in a ransomware response playbook or a business email compromise response guide. This page does not repeat them.

What does NIST expect now?

The current revision of NIST SP 800-61 is Rev. 3. Rev. 3, published in April 2025, replaced the four-phase lifecycle of Rev. 2 with a model built on the six functions of NIST CSF 2.0: Govern, Identify, Protect, Detect, Respond and Recover. NIST withdrew Rev. 2 on April 3, 2025.

Three points matter when you write the plan:

• Rev. 3 is a CSF community profile, not a handling guide. It has no plan outline to copy, so "map your plan to SP 800-61 sections" is not possible. This guide maps to CSF subcategories instead.
• NIST states that "organizations should use the incident response life cycle framework or model that suits them best." The four-phase model is the previous one, not a wrong one. A plan built on it is not non-compliant for that reason.
• Govern, Identify and Protect are preparation. NIST says they are "not part of the incident response itself," while Detect, Respond and Recover are. Roles and authorities sit in Govern (GV.RR-02), and plan review sits in the Improvement category of Identify (ID.IM-04). That is where this guide spends its time.

As of October 2026, several top-ranking templates still teach older models or cite Rev. 2, including Carnegie Mellon's plan. That matters only if an auditor asks which NIST revision you follow.

How do you create an incident response plan?

Write the decisions first and the phases last. The seven steps below take a small team a few working sessions. Each has an owner and a check.

1. Get the authorities into policy. Owner: CISO, with the general counsel. Time frame: before anything else. Check: the policy states which roles may disconnect or shut down systems, and leadership has signed it.
2. Fill the decision matrix (next section). Owner: CISO. Time frame: one working session with IT, legal, finance and communications. Check: every row has a primary, a backup, a limit and a reach time, and the backup is not in the same reporting line as the primary.
3. Write the severity table. Owner: IR lead. Time frame: one session. Check: two people classify the same three past incidents and land on the same level.
4. Line up outside help. Owner: CISO and general counsel. Time frame: before the next renewal or review. Check: each contact has been called once from the number on the list.
5. Set the communication channel. Owner: IR lead. Time frame: one week. Check: everyone on the call list can join the out-of-band channel without corporate email or SSO.
6. Print it. Owner: IR lead. Time frame: after each approval. Check: named holders can show you their paper or offline copy.
7. Schedule the first tabletop to run against this plan. Owner: CISO. Time frame: within the first quarter. Check: the exercise report lists each gap as a ticket with an owner.

Which decisions must the plan assign?

The plan must assign every decision that someone will otherwise wait for a meeting to make. The matrix below lists the decisions we expect to stall a response. Where a row quotes NIST or the SEC, the concern is theirs; the other rows, and the "why it stalls" reasons, are our analysis, not a published requirement.

Sanctions check on a ransom demand: Treasury's OFAC warns that paying a sanctioned party can bring civil penalties on a strict-liability basis, and that it treats an early, complete report to law enforcement or CISA as a significant mitigating factor. The U.S. government strongly discourages paying.

Two cautions on limits. First, "may approve alone" should be a number or a scope, not "reasonable." Examples: "isolate any single host or one network segment," "spend up to $25,000," "anything touching production customer systems goes to the COO." Second, the primary and the backup must be able to act in the same hour, so check time zones and leave schedules.

A defensive AI agent can help around the matrix, but should not sit in it. It can pull asset owners, last-seen backup status and draft the timeline for the person who holds the decision. Give it read-only access to the asset inventory and ticketing. A human must make and record each decision in the table above.

How should severity levels work?

Three or four levels are enough if each one changes who is paged, how fast, and which outside parties are called. NIST calls evaluating risk and prioritization "perhaps the most critical decision points," and says it should rest on defined factors such as asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization and recoverability.

Severity tables with response times are common in public templates. What makes yours usable is that each row points at the matrix: it says which decision holders are reached and whether the notification-clock check runs. NIST separates two terms worth using: escalation "refers to increasing resources or time frames," and elevation "indicates involving a higher level of management." The levels below are an illustration of ours.

What outside help should be lined up before an incident?

Four relationships need a name and a number before you need them: your insurer, outside counsel, an incident response firm and law enforcement. For each, the plan should hold the contact, the contract location, and who may call.

Insurer. Check your policy for notice timing, whom to notify, whether you must use panel vendors, and what the carrier pays for before notice. We did not find a regulator, NIST or CISA source stating what policies require, so the plan should quote your own policy rather than a general rule. Also see what your insurer will ask about the plan.

Outside counsel. CISA warns that your attorney "may instruct you to use a completely different IRP template" and that attorneys "often have preferences on how to engage with outside incident response vendors, law enforcement, and other stakeholders." Ask your counsel how engagements should be structured. One reason to ask early: in June 2020 a federal court in Virginia ordered Capital One to produce a Mandiant forensic report, noting that the main difference between the existing retainer's statement of work and the later letter agreement was a reference to the incident and to outside counsel's role. That is one district court. The same opinion cites a 2015 Minnesota decision that protected a report on different facts, so do not read it as a rule.

IR retainer. NIST says the contract should define "information flows, coordination, and authority to act on behalf of the organization," including limits on what the provider may do, such as "immediately deactivating certain services to contain an incident." Confirm four things: who may invoke it, the response time in writing, what the provider may change without asking you, and whether counsel needs to be involved first.

Law enforcement. CISA's advice is to get to know your local police or FBI representatives, in coordination with your attorney, because "the time to figure out how to notify LEA representatives isn't in the heat of battle."

Who decides whether a notification clock has started?

Name one role. State breach laws, HIPAA, SEC rules and customer contracts can each start a legal or contractual clock, and some clocks run from a determination rather than from discovery. NIST notes that "incident notification is an evolving topic, and new laws and regulations are being established frequently."

For that reason this plan carries no day counts. The plan should say who runs the check, which counsel supports them, and where the current rules live. See state breach notification deadlines for the multistate picture and the HIPAA breach notification procedure for covered entities. CISA's performance goals suggest reporting "within time frames directed by applicable regulatory guidance."

How do you communicate when the network is down?

Choose a channel the attacker cannot reach, and print the plan. CISA notes that during an incident "your internal email, chat, and document storage services may be down or inaccessible," and advises giving printed copies and the contact list to everyone with a role.

The communication section needs:

• an out-of-band channel (a separate messaging tenant or a conference line not tied to your corporate identity provider), with contacts stored outside the compromised directory;
• a rule for who speaks to staff, customers, regulators and press, and who owns the holding statement (CISA asks, "If a reporter calls you, claiming to have data stolen from your file servers, what will you say?");
• a stakeholder list that includes people who "won't be top of mind," such as the board, key investors and critical partners;
• a cadence for status updates, so the executive team does not interrupt responders.

What does a post-incident review need?

A review needs a date, an owner, a blameless format and a ticket for every action. NIST says improvements are often identified through follow-up reports or "lessons learned" meetings when recovery is concluding, and that lessons should often be shared as soon as they are found. CISA says retrospectives "must be blameless."

An agenda we use as a starting point:

1. Timeline from first signal to recovery, built from logs.
2. Where a decision waited, and for whom.
3. Which row of the matrix was wrong or missing.
4. What worked and should be written down.
5. Actions, each with an owner and a due date.

The IR lead owns the meeting and the action list. The CISO reviews open actions monthly until closed. Verify the review worked by checking that each change reached the plan, the matrix or a playbook.

How do you tell the plan works?

Test it against a scenario, and run the self-check. To run a tabletop exercise against this plan, give participants the printed plan only and see what they cannot answer.

Your plan is not ready if:

• it lives only on systems an attacker could encrypt, with no printed or offline copy;
• the contact list lives only in the compromised directory;
• there is no out-of-band channel;
• a matrix row has no backup;
• a "may approve alone" cell says "reasonable";
• no one is assigned to read the insurance policy and run the insurer step;
• no one owns the notification-clock check.

On cadence, sources differ. CISA's IRP Basics factsheet says to review the plan quarterly. CISA's Cross-Sector Cybersecurity Performance Goals 2.0, published December 2025, say plans should be reviewed and drilled "at a minimum, on an annual basis." NIST says "periodically or when a need for significant improvements is identified," and asks that incident response plans be synchronized with business continuity plans. We suggest checking the contact list and matrix every quarter and drilling at least annually.

Incident response plan template

Fill in the plan below with titles, not names, so it survives staff changes, then download it as a Word document or print it to PDF. Nothing you type leaves your browser. Each part notes the CSF 2.0 subcategories from NIST's incident response profile in SP 800-61 Rev. 3 that it serves; which part maps to which subcategory is our analysis, not a NIST outline.

What to do this week

• The CISO: read the policy for authority to shut systems down; if it is silent, fix that first.
• The IR lead: fill in the decision rights in the plan builder above with titles and limits, and print them.
• The general counsel: confirm how outside engagements should be structured and who reads the insurance policy.
• The CISO: schedule the tabletop and put the self-check on the agenda.