Incident Response Plan Template: Practical 2026 Outline

An incident response plan template is only worth adopting if its sections match what current NIST guidance expects a plan to do. Since April 2025 that guidance is SP 800-61 Rev. 3, and it judges a plan by outcomes rather than by a fixed table of contents.

This article sets out what an incident response plan template needs to contain to align with Rev. 3, section by section, with the Rev. 3 identifier behind each section. If you are building your plan for an ISO 27001 certification audit, our ISO 27001 incident response plan guide covers the Annex A angle; this one stays with NIST.

What Rev. 3 expects an incident response plan to be

Rev. 3 is a CSF 2.0 Community Profile, so it does not prescribe a document layout. The plan requirements sit in a handful of rows. Our NIST 800-61 Rev 3 guide explains how the profile is organized; these are the rows that shape the plan:

• ID.IM-04 (High) — incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained and improved. A note under it describes the incident response plan as the roadmap for implementing the incident response capability.
• RS.MA-01 (High) — the plan is executed in coordination with relevant third parties once an incident is declared.
• RS.MA-01.R3 — initiate other cybersecurity plans, such as business continuity and disaster recovery plans, as needed to support incident response.
• RC.RP-01 (High) — the recovery portion of the plan is executed once initiated from the incident response process.

Read together, these say the plan is an operating document. It must be usable on the day an incident is declared, it must connect to your other plans, and it must change as you learn.

Four tests any incident response plan template must pass

ID.IM-04 carries four Recommendations. Use them as acceptance tests before you adopt any incident response plan template, including ours.

Rev. 3 item	What it asks	Test for the template
ID.IM-04.R1	Synchronize business continuity plans with incident response plans	Does it name the continuity and recovery plans it triggers, and who decides to trigger them?
ID.IM-04.R2	Review and update plans periodically or when significant improvements are needed	Does it state a review cycle and the events that force an early review?
ID.IM-04.R3	Base each plan on the organization’s requirements, mission, size, structure and functions	Can you tailor it, or does it assume one organization shape?
ID.IM-04.R4	Identify the resources and management support needed	Does it have a section for budget, staff, retainers and executive sponsorship?

Apply R3 hardest. If every example in an incident response plan template assumes a round-the-clock security operations center, a small team will either ignore the plan or pretend to meet it. Both outcomes fail an audit.

Incident response plan template: section-by-section outline

The incident response plan template outline below covers the outcomes Rev. 3 ties to the plan. Section names are ours; the identifiers show where each section earns its place.

#	Section	What it contains	Rev. 3 anchor
1	Document control	Owner, approver, version, review cycle, early-review triggers	ID.IM-04.R2
2	Purpose, scope and context	Mission, services in scope, environments covered, assumptions	ID.IM-04.R3
3	Related plans	Continuity, disaster recovery and crisis plans; who triggers each	ID.IM-04.R1, RS.MA-01.R3
4	Roles, responsibilities and authorities	Who does what, who may disconnect or shut down assets	GV.RR-02, Section 2.2
5	Third parties	Service providers, their duties, information flows, authority to act	Section 2.2, GV.SC-08
6	Declaration	Incident criteria and known false positives	DE.AE-08.R1
7	Triage and prioritization	Risk evaluation factors, severity estimate, urgency	RS.MA.R2, RS.MA-02.R1, RS.MA-03.R2
8	Escalation and elevation	When to add resources; when to involve senior management	RS.MA-04
9	Response strategy	Containment and eradication choices, speed vs investigation	RS.MA-03.R3, RS.MI
10	Recovery	Criteria to start recovery, restoration checks, end of recovery	RS.MA-05, RC.RP-02.R2, RC.RP-06
11	Communication and notification	Who is told what and when; regulator and law enforcement criteria	RS.CO-02.R2, RS.CO-02.R5
12	Records and evidence	Incident tracking, record integrity, evidence handling	RS.MA.R3, RS.AN-06, RS.AN-07
13	Improvement and exercises	Lessons learned, exercise program, improvement register	ID.IM-02, ID.IM-03
14	Resources and support	Staffing, budget, retainers, executive sponsor	ID.IM-04.R4

Sections 4 and 5: roles and third parties

Section 2.2 of Rev. 3 lists the parties with incident response roles: leadership, incident handlers, technology professionals, legal, public affairs and media relations, human resources, physical security and facilities management, and asset owners. Your incident response plan template should name a role for each, even if one person covers several.

Two details matter most. First, leadership may hold decision authority over high-impact actions, such as shutting down or rebuilding critical services; write down who holds it. Second, incident handlers may be on staff, on contract (for example a managed security service provider running your SOC, or a cloud provider’s incident team) or available when needed. For contracted parties, Rev. 3 expects responsibilities, information flows, coordination and authority to act to be defined in the contract, including restrictions.

Sections 7 to 9: triage, escalation and strategy

RS.MA.R1 says incidents should not be handled first-come, first-served. The plan therefore needs a stated basis for priority. RS.MA.N2 gives example risk evaluation factors: asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization and recoverability.

Keep escalation and elevation separate. RS.MA-04.N1 describes escalation as adding resources or time, and elevation as involving a higher level of management. Your plan should give a trigger for each. For strategy, RS.MA-03.R3 asks you to balance quick recovery against observing the attacker or investigating more thoroughly; the plan should say who makes that call.

Section 11: communication without hard-coded deadlines

RS.CO-02.R5 ties notification of law enforcement and regulators to criteria in the plan and to management approval. Notification clocks differ by regime and start from different triggers, so do not copy deadlines into the plan body. Point to an obligations register that legal maintains. Our breach notification guide covers how to build one.

What to keep out of the plan

An incident response plan template that tries to hold everything becomes unusable under pressure. Move these items into separate documents and reference them:

• Scenario steps. Section 2.3 puts actionable steps in playbooks and procedures. The plan says when a playbook applies, not what it says.
• Contact details. Keep a call list as an appendix or a separate register so it can be updated without re-approving the plan.
• Tool runbooks. EDR, SIEM and identity provider procedures change with every upgrade. Reference them by name.
• Regulatory text. Hold obligations in a register owned by legal, as above.

Tailoring an incident response plan template to your size

ID.IM-04.R3 asks you to base the plan on your own requirements, mission, size, structure and functions. These decision rules keep tailoring honest.

• If one person fills several roles, keep every role in the plan and list the same name against each. Deleting roles hides gaps.
• If a provider runs detection or response for you, the plan must state what it does, what you still do, and what the contract lets each side do without asking.
• If you have no out-of-hours cover, say so and state the accepted risk. Do not describe a capability you do not have.
• If your mission depends on a few critical services, list them in section 2 so the risk evaluation factors in section 7 have something to point at.

Once the plan is in place, map its sections to the Functions so you can show alignment. Our NIST incident response lifecycle guide shows how the Rev. 2 phases map to the CSF 2.0 Functions. The primary source is NIST SP 800-61 Rev. 3.

Proving your incident response plan template works

A plan nobody has rehearsed is a draft. ID.IM-02 is rated High: improvements come from tests and exercises, including those run with suppliers and other third parties. Rev. 3 points to NIST SP 800-84 for simulations and tabletop discussions.

Before you sign off a plan built from an incident response plan template, run one discussion-based exercise against it and check four things:

• Every decision in the scenario has a named owner in section 4, including the authority to shut down a critical service.
• The declaration criteria in section 6 produce the same answer when two people apply them separately.
• The plan tells participants when to hand over to the continuity or disaster recovery plan, and who makes that call.
• Each gap the exercise finds is logged in the improvement register in section 13, with an owner, as ID.IM-03 expects.

Incident response plan template FAQ

What should an incident response plan template include?

Roles and authorities, declaration criteria, prioritization, escalation and elevation, response strategy, recovery, communication, records, improvement and resources, each tied to a Rev. 3 outcome.

How long should an incident response plan be?

Long enough to cover the fourteen sections above and short enough to use during an incident. Push scenario detail into playbooks.

How often should the plan be reviewed?

ID.IM-04.R2 says periodically and whenever a significant improvement is needed. Set a fixed cycle and list the events that force an early review.

Is a NIST incident response plan template different from an ISO 27001 one?

The core content overlaps. The difference is the evidence each framework asks for, so map your incident response plan template to the framework your auditor uses.

Our Incident Response Toolkit provides 93 editable templates aligned to NIST SP 800-61 Rev. 3 — including the Incident Response Plan, the Incident Response Roles Responsibilities and Authorities document and the Incident Response RACI Matrix — for $99.