A blank playbook and a blank runbook you can copy straight into your repository, with guidance on every field and one section filled in to show the standard.
Who needs this: Playbook owners, IR leads, SOC managers, service owners | Read time: 12 min | Maps to: CSF 2.0 GOVERN, RESPOND (GV.RR, RS.MA, ID.IM) | CIS Control 17 | ISO 27001 A.5.24, A.5.26
Chapter 2 argued the case; this appendix hands you the file. Copy the block below into playbooks/PB-XXXX.md, delete the guidance, fill the angle brackets, and open a pull request. That is the whole ritual.
Two things to fix in your head before you start typing. First, the empty fields are the point. A playbook is not a description of how you respond — it is a container for decisions you have already made, and every blank you leave is a decision someone will have to invent at 03:00 with an outage running. Second, resist the urge to write the interesting parts first. The interesting parts are the phase tables. The parts that decide whether the playbook works are the header, the entry criteria and the authority table, and they are boring to write. Write them anyway.
One structural note the published standards agree on and most home-grown playbooks miss: a playbook expires. OASIS CACAO — the closest thing to a normative machine-readable playbook schema — carries valid_until, revoked, derived_from and workflow_exception as first-class properties (CACAO Security Playbooks v2.0). Provenance, an expiry date, and a statement of what to do when the playbook itself fails. Those four fields are in the template below because a document with no expiry date is not maintained, it is merely old.
# Playbook: <Scenario name>
**Playbook ID:** `PB-XXXX` | **Version:** v0.1 | **Status:** Draft | Active | Revoked
**Owner:** <named person + role — never a team alias> | **Approver:** <role>
**Created:** YYYY-MM-DD | **Last modified:** YYYY-MM-DD
**Last exercised:** YYYY-MM-DD (<exercise ID>) — result: <n findings, n closed>
**Next review due:** YYYY-MM-DD | **Expires (auto-Draft after):** YYYY-MM-DD
**TLP marking:** TLP:CLEAR | GREEN | AMBER | AMBER+STRICT | RED
**Derived from:** <template or parent playbook + version> | **Related playbooks:** <IDs>
**Runbooks invoked:** <RB-IDs> | **ATT&CK references:** <technique IDs>
## When to run this (entry criteria)
Open this playbook when ANY of the following is observed:
- <Observable condition 1 — an alert name, log signature, or report source. Not a feeling.>
- <Observable condition 2>
- <Observable condition 3>
Do NOT use this playbook for:
- <Adjacent scenario> → run `<PB-ID>` instead
- <Adjacent scenario> → run `<PB-ID>` **in parallel**; this playbook owns <X>, that one owns <Y>
## When this is closed (exit criteria)
All of the following must be true:
- [ ] No new indicators of this activity for <N> hours across <named telemetry sources>
- [ ] Initial access vector identified and remediated, or formally risk-accepted by <role>
- [ ] All affected <identities / hosts / tenants> enumerated and remediated
- [ ] Evidence set complete, hashed, and retained per <retention policy>
- [ ] All notification obligations discharged or formally determined not to apply
- [ ] Post-incident review scheduled with a named facilitator
## Severity and escalation
| Condition | Severity | Escalation (more people/time) | Elevation (higher management) |
|---|---|---|---|
| <default case> | SEV-_ | <who is paged> | <who is told> |
| <aggravating condition> | SEV-_ | | |
| <aggravating condition> | SEV-_ | | |
Under uncertainty between two levels, take the higher one. Reassess at the post-incident review, never during.
## Roles
| Role | Holder | Deputy | Out-of-hours reach path | Responsibility in this playbook |
|---|---|---|---|---|
| Incident Commander | | | | Decides and delegates. No technical work. |
| Operations Lead | | | | |
| Communications Lead | | | | |
| Scribe | | | | Contemporaneous UTC timeline, recorded off the affected estate. |
| Legal Liaison | | | | |
| Executive Sponsor | | | | |
## Authority
| Action | Pre-authorized? | Who may authorize | Out-of-hours reach path | Logged where |
|---|---|---|---|---|
| <isolate a single endpoint> | Yes — log after | — | — | |
| <revoke a session token> | Yes — log after | — | — | |
| <enterprise-wide credential reset> | No | | | |
| <stop a production service> | No | | | |
| <engage third-party IR firm> | No | | | |
| <pay anything> | No | | | |
**If the named authority is unreachable within <N> minutes, the default is:** <action>.
## Containment considerations — read before any Phase 2 action
- Additional adverse impact on mission operations and availability of services:
- Duration, resources required, and effectiveness — full vs. partial, full vs. unknown containment:
- Impact on the collection, preservation and documentation of evidence:
## Phase 1 — Detection and Triage
| # | Action | Who | Done when | Evidence to capture |
|---|---|---|---|---|
| 1.1 | | | | |
| 1.2 | | | | |
| 1.3 | | | | |
## Phase 2 — Containment
| # | Action | Who | Done when | Evidence to capture |
|---|---|---|---|---|
| 2.1 | | | | |
| 2.2 | | | | |
## Phase 3 — Eradication
| # | Action | Who | Done when | Evidence to capture |
|---|---|---|---|---|
| 3.1 | | | | |
| 3.2 | | | | |
## Phase 4 — Recovery
| # | Action | Who | Done when | Evidence to capture |
|---|---|---|---|---|
| 4.1 | | | | |
| 4.2 | | | | |
## Phase 5 — Post-Incident
| # | Action | Who | Done when | Evidence to capture |
|---|---|---|---|---|
| 5.1 | | | | |
| 5.2 | | | | |
**Step markings.** ``⚑EVIDENCE`` this step destroys or degrades evidence — capture the artefacts in that
row's Evidence column first. ``⚐TIP-OFF`` this step is visible to the adversary — hold it for the
eradication event unless the Incident Commander records an explicit acceptance of the tip-off.
## Loop-back rule
If new signs of compromise are found at any point, contain that activity and return to Phase 1
to re-scope. Do not proceed to eradication until the scope and the initial access vector are
identified.
## Decision points
> [!DECISION] <The question, phrased as a binary>
> **Decide by:** T+<time>. **Authority:** <role>.
> **Do X if:** <observable evidence>
> **Do Y if:** <observable evidence>
> **Default if the window expires undecided:** <the safer branch>
## Communications hooks
| Trigger | Audience | Owner | Clock starts at | Pre-approved template |
|---|---|---|---|---|
| | Internal — all staff | Comms Lead | | |
| | Executive / board | Exec Sponsor | | |
| | Customers | Comms Lead | | |
| | Regulator(s) | Legal Liaison | | |
| | Law enforcement | Legal Liaison | | |
| | Insurer | Legal Liaison | | |
| | Affected suppliers | <role> | | |
**Out-of-band channel for this incident type:** <channel that does not depend on the systems in scope>
## Automation notes
| Step | Automated / Assisted / Manual | System | Human gate | What the automation must log |
|---|---|---|---|---|
| | | | | |
## If this playbook fails
<What to do when the playbook does not fit, the tooling it assumes is unavailable, or the
scope exceeds it: which playbook to switch to, who to call, what to fall back on.>
## Pitfalls
- <A specific way this scenario is habitually botched, and the consequence.>
- <Another.>
## Revision history
| Version | Date | Author | Change | Trigger | Approved by |
|---|---|---|---|---|---|
| v0.1 | | | Initial draft | — | |The header is a contract, and each line answers a question somebody would otherwise ask you on the bridge.
| Field | The rule |
|---|---|
| Owner | A named person plus their role. Team aliases have no pager and no accountability. |
| Status | Active only if the last exercise date is inside your review window. Otherwise it is Draft, whatever it says on the cover. |
| Last exercised | Date, exercise ID, and the finding count with how many are closed. An untested playbook is a hypothesis. |
| Expires | A hard date. CI marks the playbook Draft when it passes. This single field does more for maintenance than any review meeting. |
| Derived from / Related | Provenance and neighbours, so a fix propagates and a responder in the wrong playbook finds the right one. |
| Runbooks invoked | List the runbook IDs. CI should fail if a referenced runbook does not exist — the Equifax notification list that had quietly gone stale is the same class of defect (GAO-18-559). |
| TLP marking | Decides who may be handed this document during an incident. Decide it now, not while someone is asking. |
Entry criteria must be observable. "Suspected ransomware" is not an entry criterion; "a ransom note is recovered, or mass file-extension changes are detected on a file server" is. CISA's federal playbook carries an explicit when to use this playbook box with a matching do not use list, and the do-not list is the half people skip (CISA Federal Playbooks). Without it, every incident gets funnelled into whichever playbook is best written.
Exit criteria are what stop an incident from being closed by exhaustion. Write them as things that must be true, never as steps that must be done. "All fourteen steps completed" is not containment. "No new indicators for 72 hours across these four telemetry sources" is.
The authority table is the highest-leverage table in the document. NIST SP 800-61r3 requires the policy to name which roles have authority to confiscate, disconnect or shut down assets (NIST SP 800-61r3), and NCSC adds that decision-makers must hold actual authority and that deputies must be named for when primaries are unreachable (NCSC). The out-of-hours column is not optional. An approver you cannot reach at 02:00 on a Sunday is a blocker wearing a job title.
The containment considerations block goes before the containment steps, not after. CISA forces three weighings first: adverse mission impact, duration and effectiveness of containment, and impact on evidence (CISA Federal Playbooks). Reading it out loud takes ninety seconds and is the cheapest insurance against whack-a-mole containment, where piecemeal action tips your hand and the adversary quietly re-establishes on the backdoors you never found (Aldridge, Remediating Targeted-threat Intrusions).
Actionable takeaway: fill the header, entry criteria, exit criteria and authority table before you write step 1.1. If you never get to the phase tables, you will still have a more useful document than most organizations have.
Five phases — detection and triage, containment, eradication, recovery, post-incident — following the shape AWS uses for its published library (AWS SEC10-BP04). These are the same five, in the same order, that all fourteen playbooks in Chapter 14 use. Keep the names. Scoping lives inside Phase 1, which is why the loop-back rule sends you back there and not somewhere in the middle.
Here is a real fill of the first three sections, for a phishing-triage playbook. The alert names are from a fictional tenant — substitute your own detection names, or the row is decoration.
# Playbook: Reported Phishing Email — Credential Harvesting
**Playbook ID:** `PB-PHISH` | **Version:** v2.1 | **Status:** Active
**Owner:** J. Okafor, SOC Manager | **Approver:** IR Lead
**Created:** 2024-11-04 | **Last modified:** 2026-07-19
**Last exercised:** 2026-06-11 (TTX-2026-03) — result: 3 findings, 3 closed
**Next review due:** 2026-12-19 | **Expires (auto-Draft after):** 2027-01-19
**TLP marking:** TLP:GREEN
**Derived from:** TEMPLATE v1.4 | **Related playbooks:** `PB-BEC`, `PB-ATO`
**Runbooks invoked:** `RB-012` purge message, `RB-004` revoke sessions, `RB-021` block sender
## When to run this (entry criteria)
Open this playbook when ANY of the following is observed:
- A user reports a message via the Report Phishing button and the message contains a
credential-collection link or an attachment prompting for sign-in
- Mail security flags 3+ recipients on the same campaign within 60 minutes
- A credential-harvest domain from this campaign appears in proxy or DNS logs
Do NOT use this playbook for:
- A payment or bank-detail change was requested or made → run `PB-BEC`
- A session, token or OAuth grant is already in use by someone who is not the user →
run `PB-ATO`; this playbook stops at the point a credential is confirmed used
## When this is closed (exit criteria)
- [ ] All copies of the campaign purged from all mailboxes; purge job ID recorded
- [ ] Every recipient who submitted credentials has had sessions revoked and
credentials reset, in that order
- [ ] No successful authentication from campaign infrastructure in the last 24 hours
- [ ] Sender, domains and URLs blocked, with block IDs recorded
- [ ] Detection gap, if any, raised as a ticket with an owner and a due dateNote what this example does not contain: opinions, guesses at attribution, or an estimate of how many people fell for it. Facts and timestamps go in the incident record; everything else is a line someone reads aloud in a deposition later. The SEC's complaint against SolarWinds and its CISO leaned heavily on internal messages and presentations (SEC press release 2023-227). Write like it will be read by a stranger who is not on your side, because one day it will be.
A playbook says what happens and who decides. A runbook says which buttons to press. Keep them separate: playbooks change per threat, runbooks change every time a vendor moves a menu (AWS Security Incident Response Guide).
# Runbook: <Single task, stated as a verb phrase>
**Runbook ID:** `RB-000` | **Version:** v1.0 | **Owner:** <service owner, named>
**Last verified against live tooling:** YYYY-MM-DD by <name>
**Invoked by:** `PB-XXXX` step <n.n>, `PB-YYYY` step <n.n>
**Purpose:** <One sentence. If it needs two, it is two runbooks.>
**Preconditions:** <role/permission required, licence tier, logging that must already be on>
**Reversibility:** <what this changes, how to undo it, how long the undo takes>
**Evidence impact:** <what this destroys or degrades — capture first>
**Adversary-visible:** Yes | No
**Estimated duration:** <minutes>
## Steps
1. <Action.>
<command>
2. <Action.>
## Verification
<How you know it worked — the specific output, console state or log event to check.
"No error" is not verification.>
## Rollback
<Exact steps to undo, or "not reversible — escalate before running".>
## Escalate to <role> if
- <condition>
- <the command returns anything other than the expected output>
## Change log
| Version | Date | Change | Verified against tooling by |
|---|---|---|---|Takeaway: every runbook carries a last verified against live tooling date, and that date is a claim someone made by actually running it. A runbook nobody has executed since the last platform update is a fiction with syntax highlighting.
Twelve properties separate a playbook that survives contact from one that gets abandoned in the first hour. Run this before you merge.
That last one is the paradox of playbooks-as-code, and it is worth saying plainly. Microsoft ships its response playbooks as Markdown in a public repository with pull-request review (MicrosoftDocs/security); AWS and Counteractive do the same with their libraries (counteractive/incident-response-plan-template). Git gives you diffable history, CODEOWNERS, PR review as the approval workflow, and CI that can fail a build when a required field is missing or a last_tested date has gone stale. All of which is excellent, and none of which helps if the incident takes down the identity provider your git host authenticates against.
So: version it like code, and then print it. Print the contact list too. Not next quarter. Now.
Fill the blanks, exercise the result, and let the CI job be the one that nags you — it has no feelings and it never forgets the review date.