The policy says that incident response exists and who has authority. The plan says how the capability is organised, staffed and run. A playbook gives the steps for one kind of incident. Mixing the three produces documents that are too vague to act on or too detailed to approve.
The policy: authority and intent
A policy is short and changes rarely. It states that the company will detect and respond to incidents, gives the incident lead authority to take systems offline, requires staff to report suspected incidents, and names an owner. Executives approve it.
If you find yourself writing tool names or phone numbers, you are in the wrong document.
The plan: structure and roles
The plan carries the details NIST SP 800-53 IR-8 describes: what counts as an incident, how response is structured and staffed, how information is shared, how effectiveness is measured, and who is accountable. See what goes in an incident response plan. It changes when the organisation changes and is reviewed on a set schedule.
The playbook: do this, then this
A playbook handles one scenario. Good first ones for a software company:
- Stolen or leaked credentials or API keys.
- Compromised developer laptop.
- Malicious dependency discovered in a build.
- Ransomware on corporate systems.
- Customer data exposure through a misconfigured service.
- Account takeover of a customer.
Each playbook lists triggers, first actions, who to call, what evidence to save, containment options, recovery checks, and a closing task to hold a review. Playbooks change often, because tools and systems change.
How they relate
- Policy: read by everyone, changes rarely, approved by executives.
- Plan: read by the response team and managers, changes yearly or on organisational change, approved by the security lead and an executive.
- Playbook: read by responders, changes often, approved by the incident lead.
This is a common way of dividing the layers, not a required format.
Keep the cross references honest
When you add a playbook, check the plan's severity table still fits. When you change the plan, check the policy's authority statement still holds. IR-8 asks for updates when systems or the organisation change and when problems appear in implementation or testing, so build that review into after-incident work.
Where continuity plans fit
Incident response often runs alongside continuity and recovery planning. NIST IR-4 asks for incident handling to be coordinated with contingency planning, and CP-2 asks the same in reverse. See BCP, DR and incident response compared.
A small team shortcut
Early on, combine policy and plan in one short document and write only three playbooks: leaked secret, lost laptop, and suspicious login. Split them when the document outgrows a few pages.
Safeguard's zero-day discovery and policy gates can help you detect and block some supply chain triggers that feed a playbook. They do not replace a response process.
Quick check
Do auditors expect all three documents?
They expect that your response approach is documented, approved and tested. The names and the number of documents are up to you.
Which should be tested?
The plan and the playbooks, through tabletop exercises that walk through a scenario.
Sources
- IR-8 Incident Response Plan, NIST SP 800-53 Rev. 5
- IR-4 Incident Handling, NIST SP 800-53 Rev. 5
- CP-2 Contingency Plan, NIST SP 800-53 Rev. 5
Last reviewed: 19 October 2026.
