What goes in an incident response policy, and how is it different from the plan?
The policy says who is accountable and what the organization commits to. The plan says what to do. The playbook says what to do about one specific thing. An organization that writes the plan and skips the policy can find at its first audit that the policy is what gets asked for first, because it authorizes everything else.
What is the difference between a policy, a plan and a playbook?
NIST puts the hierarchy in one sentence: Processes and procedures should be based on the incident response policy and plan (NIST Special Publication 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025). Everything operational hangs off the two documents above it.
| Policy | Plan | Playbook | |
|---|---|---|---|
| Answers | What are we committed to, and who is accountable? | What do we do in any incident? | What do we do about ransomware? |
| Length | One or two pages | A handful of pages plus contacts | As long as the steps take |
| Changes | Rarely | When the organization changes | Whenever the threat does |
| Signed by | An executive | The plan owner | Nobody |
| Read by | Auditors, customers | The response team | Whoever is on the keyboard |
What goes in the policy?
NIST says that while a policy is individual to the organization, most incident response policies include the same key elements (NIST Special Publication 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025). Those elements, turned into a template you can fill in:
| Section | One or two sentences saying |
|---|---|
| Management commitment | That the organization treats incident response as a funded obligation, signed by somebody who controls the funding |
| Purpose and objectives | What the policy exists to achieve |
| Scope | Who and what it applies to, and under what circumstances |
| Definitions | What counts as an event, what counts as an incident, and who decides |
| Roles, responsibilities and authorities | Who may confiscate, disconnect or shut down a system, and who may not |
| Prioritization | How severity is estimated and what each level triggers |
| Performance measures | What you will measure, such as time to escalate and findings closed on time |
| Testing and review | How the plan is exercised, how often, and who owns the findings |
The last row is ours, not NIST’s. It belongs in the policy rather than only in the plan, because a cadence written into a plan is a working assumption and a cadence written into a signed policy is a commitment.
Who signs it and who reviews it?
Management commitment is the first element on NIST’s list, and a signature is what makes it real. The signer should be the executive accountable for the response, usually the person who would be woken up.
Review sits with whoever owns the plan. Keep the two roles apart. One authorizes, the other maintains.
How often is it reviewed, and how does testing feed the review?
The cadence to write in is annual, which is what the Cyber Centre’s guidance on developing an incident response plan asks for: Test, revisit, and revise your incident response plan annually to keep it effective (Canadian Centre for Cyber Security, Developing your incident response plan, ITSAP.40.003, 2026).
Add a change trigger next to it. A calendar on its own misses what matters. The Cloud Security Alliance’s control for this asks organizations to Test and update as necessary IR plans at planned intervals or upon significant organizational or environmental changes for effectiveness (Cloud Security Alliance, Cloud Controls Matrix, SEF domain, 2025), and NIST’s version is periodically or when a need for significant improvements is identified (NIST Special Publication 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025).
The mechanism that makes any of this more than a date: the exercise produces findings, the findings get owners and dates, and the review checks whether they closed. Write that loop into the policy in one sentence and the policy has done the only job a plan cannot do for itself.
SOC 2 and ISO 27001 both carry incident response criteria, and an auditor maps your documents against them. In ISO 27001 they are controls 5.24 to 5.28, and none of those control titles names a method or a facilitator. Have the policy, the plan, and evidence the loop ran ready for either.
Can the policy and the plan be one document?
They can, and for a small organization it is often sensible. Keep them as separate sections with their own headings, because they are read by different people for different reasons. An auditor can then find the accountability and cadence in one place. Somebody handling an incident at midnight wants the steps.
Who should sign the incident response policy?
An executive with authority over budget and people, not the person who wrote it. The point of the signature is that the commitments in the policy have been agreed by somebody who can honour them. A policy signed only by its author commits nobody.
Does an auditor ask for the policy or the plan?
Expect both, and have the policy ready first, because it is the shorter document and it says what the organization has committed to. Then the plan, then evidence that the plan was exercised and the findings closed.