Incident Response Policy: The Essential 2026 Guide

An incident response policy is the short, management-approved document that commits your organization to responding to incidents, says who has the authority to act, and sets the rules for prioritizing that response. It is not the plan, and it is not a playbook; mixing those up is how policies swell until nobody reads them.

NIST SP 800-61 Rev. 3, finalized in April 2025, makes the policy an explicit expectation and lists what it should cover. This guide walks through the seven elements in Section 2.3, shows how the policy differs from the plan, procedures and playbooks, and gives drafting rules that hold up in an audit.

Why Rev. 3 asks for an incident response policy

Rev. 3 is a CSF 2.0 Community Profile, and the policy requirement sits in the Govern Function. Our NIST 800-61 Rev 3 guide explains the structure; three rows matter here.

• GV.PO (the Policy Category, rated High) — organizational cybersecurity policy is established, communicated and enforced. Its Recommendation, GV.PO.R1, says cybersecurity policies should include an incident response policy.
• GV.RR-02 (Medium) — R1 says all roles and responsibilities involving incident response should be documented in the organization’s policies. R2 says the appropriate people or parties should be given the authority they need to carry out those responsibilities.
• GV.PO-02 (Low) — policy is reviewed, updated, communicated and enforced to reflect changes in requirements, threats, technology and mission.

The decision rule that follows: if your incident response policy does not name roles and grant authority, it does not meet GV.RR-02, however well written the rest is.

The seven elements of an incident response policy

Section 2.3 of Rev. 3 notes that a policy is highly individualized, but lists seven key elements that most incident response policy documents share. Treat them as the table of contents. Each subsection below says what the element is for and gives a drafting rule.

1. Statement of management commitment

One or two sentences, signed or approved by the executive who owns cybersecurity risk. The point is authority: when an incident handler disconnects a revenue-generating system, the policy is what shows they were acting for leadership, not on their own judgment. Drafting rule: name the approving role and the approval date in the document control block.

2. Purpose and objectives

State what the policy is for in outcome terms: detect and declare incidents promptly, limit their impact, restore operations safely, meet notification obligations and improve after every incident. Drafting rule: write objectives you could measure. “Minimize business impact” is not testable; “declare incidents against approved criteria” is.

3. Scope

Say which organizations, locations, systems, environments and people the policy covers. Rev. 3’s glossary defines an event as any observable occurrence involving computing assets, including physical and virtual platforms, networks, services and cloud environments. Drafting rule: if a cloud service or a contractor-run system is in scope, say so by name or by category, so nobody argues about it mid-incident.

4. Definitions

Define events, cybersecurity incidents, investigations and related terms. Rev. 3’s glossary gives you a consistent base:

• Event — any observable occurrence involving computing assets.
• Adverse cybersecurity event — any event with a potentially negative impact on cybersecurity.
• Cybersecurity incident — an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality or availability of information or an information system; or that violates, or imminently threatens to violate, law, security policies, security procedures or acceptable use policies.

Drafting rule: do not define “breach” in the policy. Breach is a legal term each law defines for itself; leave it to the obligations register maintained by legal.

5. Roles, responsibilities and authorities

This is the element auditors read first. Rev. 3 gives an example of the authorities to settle: which roles may confiscate, disconnect or shut down technology assets. Section 2.2 also notes that leadership may hold decision authority for high-impact actions, such as shutting down or rebuilding critical services.

Drafting rule: grant authority to roles, not named people, and state any limits. For example, an incident lead may isolate an endpoint without approval, but shutting down a customer-facing service requires the accountable executive. Put the detailed split in the plan or a RACI; keep the grants of authority in the policy.

6. Prioritization, severity and recovery guidelines

Rev. 3 asks the policy to give guidelines for prioritizing incidents, estimating severity, initiating recovery, and maintaining or restoring operations. RS.MA.R1 adds that incidents should not be handled first-come, first-served, and RS.MA.N2 lists example risk evaluation factors: asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization and recoverability.

Drafting rule: the policy states the principle and names the factors; the severity matrix itself lives in a separate document so it can be tuned without re-approving the policy.

7. Performance measures

The policy should say how the program will be measured. Rev. 3 names performance measures as an element; which measures you adopt is your choice, so pick ones you can collect reliably. Candidates include time from detection to declaration, time from declaration to containment, incidents by severity, and the share of improvement actions closed by their due date. Our MTTD vs MTTR explainer covers how to define the time measures so they stay comparable.

Incident response policy vs plan vs procedure vs playbook

Section 2.3 separates the policy from the material that tells people what to do. Playbooks give actionable steps for specific scenarios; procedures cover the most common incident types and urgent processes, such as redeploying the primary authentication platform. Rev. 3 points to CISA’s Cybersecurity Incident & Vulnerability Response Playbooks (2021) as examples.

Document	Answers	Approved by	Changes when
Incident response policy	Why we respond, who has authority, what principles govern priority	Executive leadership	Requirements, threats, technology or mission change (GV.PO-02)
Incident response plan	How the capability works: roles, declaration, escalation, recovery, communication	Program owner, with leadership sign-off	After exercises, incidents or significant improvements (ID.IM-04.R2)
Procedure	How to perform a recurring task, such as triage or evidence handling	Process owner	When tools or teams change
Playbook	What to do, step by step, for one scenario such as ransomware or account takeover	Incident response manager	When the scenario or the threat changes

A simple routing test decides where a sentence belongs. If it grants authority or states a principle, it goes in the incident response policy. If it describes how the capability is organized, it goes in the plan; our incident response plan template guide sets out a section-by-section outline. If it lists steps, it goes in a procedure or playbook.

Where the incident response policy sits among your other policies

The incident response policy does not stand alone, and three links are worth writing in explicitly.

• Acceptable use. Rev. 3’s definition of a cybersecurity incident includes violations of acceptable use policies. Cross-reference your acceptable use policy so a misuse report has a clear route into incident handling.
• Human resources. RS.CO-03.R3 says to notify human resources when malicious insider activity has occurred. The policy should name HR as a party and point to the disciplinary process.
• Business continuity. The policy’s guideline on maintaining or restoring operations should defer to the continuity plan for the detail, so the two never contradict each other.

Drafting an incident response policy that survives an audit

Apply these rules to the draft before it goes for approval.

• Keep it short. If a paragraph needs updating every time a tool changes, it belongs in a procedure.
• Name no products. Refer to technology categories, such as EDR, SIEM or the identity provider, so a vendor change does not force a policy change.
• Hard-code no deadlines. Notification clocks differ by regime and start from different triggers. Require legal to maintain an obligations register and make the policy point to it. Our breach notification guide covers the approach.
• Cover third parties. Where providers handle detection or response, the policy should require their responsibilities, information flows and authority to act to be defined in contract.
• Set review triggers. A fixed cycle plus the GV.PO-02 triggers: changes in requirements, threats, technology or mission.
• Reserve the hardest decisions. Name the decisions that only executive leadership can make, such as paying a ransom, which must be taken with legal counsel after sanctions and reporting exposure has been assessed.

The source for every element above is NIST SP 800-61 Rev. 3, Section 2.3 and the Govern rows of Table 2.

Incident response policy FAQ

What is the difference between an incident response policy and a plan?

The policy grants authority and states principles. The plan describes how the capability operates. Rev. 3 expects both: GV.PO.R1 for the policy and ID.IM-04 for the plan.

How long should an incident response policy be?

Short enough to approve and read in one sitting. Cover the seven Section 2.3 elements and move operational detail into the plan, procedures and playbooks.

Who should approve the incident response policy?

Executive leadership, because the policy’s main job is to grant authority. Record the approving role and date.

How often should it be reviewed?

On a fixed cycle and whenever requirements, threats, technology or the organization’s mission change, as GV.PO-02 describes.

Our Incident Response Toolkit provides 93 editable templates aligned to NIST SP 800-61 Rev. 3 — including the Incident Response Policy, the Incident Declaration Criteria and the Incident Severity and Prioritisation Matrix — for $99.