#Chapter 2 — Plan, Playbook, Runbook

How to write incident documentation that a tired person can execute at 03:00 without stopping to work out who is allowed to decide.

Who needs this: CISO, IR lead, playbook owners, SOC managers, anyone who has been handed "update the IR plan" | Read time: 18 min | Maps to: CSF 2.0 GOVERN, RESPOND (GV.RR, GV.PO, RS.MA, ID.IM) | CIS Control 17 | ISO 27001 A.5.24, A.5.26, A.5.27

Fellow defenders, let me start with the most expensive email that never arrived.

When Equifax was breached, the company had a process. A vulnerability notice went out. Patching happened across the estate. And the Apache Struts vulnerability on the online dispute portal did not get patched, because — in GAO's words — "the recipient list for the notice was out-of-date and, as a result, the notice was not received by the individuals who would have been responsible for installing the necessary patch." A scan a week later did not find it either. Separately, an expired digital certificate meant traffic went uninspected throughout the breach (GAO-18-559, pp.15–16). None of that is a missing document. Every one of those is a document that existed and was quietly wrong.

That is the actual failure mode of security documentation, and it is not the one people plan for. Teams worry that they have no playbook. The recurring finding in published post-incident reports is that they had one, it was approved, and a field inside it had rotted — a distribution list, a phone number, an authority that moved with a reorg, a runbook referencing a console that was decommissioned two migrations ago. The document was fine. The document was also fiction.

So this chapter is not about what to write. It is about how to build the thing so it stays true. The craft, stripped to one sentence: every structural convention below exists to remove a decision from the moment of crisis and move it into peacetime. Metadata, entry and exit criteria, pre-authorized action lists, severity keyed to business impact, named authorities with named deputies — none of it is bureaucracy. It is all the same move, made repeatedly, because the research on fatigue is unambiguous about which cognitive faculties leave the building first. Harrison and Horne found that well-practiced, rule-based tasks hold up surprisingly well under sleep deprivation; what degrades is handling the unexpected, innovating, revising plans, filtering distraction, and communicating effectively (Harrison & Horne, 2000). Read that list once more. It is a precise inventory of what a novel incident demands and what your responder will not have at hour eleven.

A playbook converts judgement into rule-following. That is the whole trick. Everything else is formatting.

#Three documents, three jobs

There is no single normative taxonomy across the standards bodies, but they converge on a ladder: policy → plan → playbook → runbook. Each rung answers a different question, changes at a different rate, and is approved by a different person. Collapse two rungs and you get a document that is neither approvable nor executable.

CISA defines an incident response plan as "a written document, formally approved by the senior leadership team, that helps your organization before, during, and after a confirmed or suspected security incident. Your IRP will clarify roles and responsibilities and will provide guidance on key activities" (CISA, Incident Response Plan Basics). Note what that definition does not promise: steps. NIST separates the artifacts the same way — the policy carries management commitment, scope, and "roles, responsibilities, and authorities, such as which roles have the authority to confiscate, disconnect, or shut down technology assets," while processes and procedures derived from it "explain how technical processes and other operating procedures should be performed" (NIST SP 800-61r3, §2.3).

NIST then says the useful part out loud: "Many organizations choose to create playbooks as part of documenting their procedures… Formatting procedures within a playbook instead of another format can improve their usability." And AWS draws the last line: "A runbook is the documented form of an organization's procedures for conducting a task or series of tasks," while playbooks "provide prescriptive guidance and steps to follow when a security event occurs" (AWS Security Incident Response Guide).

The most common structural error is collapsing plan and playbook into a sixty-page hybrid that tries to be executable. It fails twice: too operational for the board to meaningfully approve, too abstract for a responder to run. CISA models the separation in its own output — a short plan fact-sheet on one hand, an operational playbook document on the other (CISA Federal Playbooks).

The second most common is the opposite: inlining runbook commands into playbooks. Do it once and you feel efficient. Do it across fourteen playbooks and you have fourteen copies of the same PowerShell one-liner, of which eleven are stale within a year. RE&CT solves this by composing playbooks from a library of atomic, individually-owned response actions, structured deliberately like ATT&CK (RE&CT). That is the best idea in this space: fix "isolate a host" once and the fix propagates to every playbook referencing it.

You do not need fourteen playbooks to start. NCSC's guidance is to build detailed scenario documents — it calls them runbooks; in this book's vocabulary they are playbooks — for the top three to five highest-risk incident types only, covering initial response, containment, evidence preservation, and when to involve legal, HR and PR (NCSC). Three real ones beat fourteen aspirational ones, every time.

Actionable takeaway: Write one plan of no more than fifteen pages that a senior leader can actually read and sign, then move every step, command and decision out of it into playbooks and runbooks. If a page of your plan contains a command, it is in the wrong document — cut it out today and give it an owner.

#The header block: everything you must not have to ask

Open a playbook mid-incident and there are roughly a dozen things you need to know before step one, none of which are steps. Most home-grown playbooks answer three of them.

The most rigorous published schema is OASIS CACAO Security Playbooks v2.0, and even if you never write a line of machine-readable playbook, its property list is the best available checklist for what a header needs: id, name, description, playbook_types, created_by, created, modified, revoked, valid_from, valid_until, derived_from, related_to, priority, severity, impact, labels, external_references, markings, signatures, workflow, and workflow_exception (OASIS CACAO v2.0). Look at what CACAO makes explicit that hand-rolled playbooks almost always omit: a playbook that can expire (valid_until, revoked), a playbook that records its provenance (derived_from), and — the one I have never seen in a home-grown document — what to do when the playbook itself fails (workflow_exception).

Here is a filled-in header. Not a template with angle brackets; a real one, of the kind that should sit at the top of every scenario playbook in Chapter 14.

playbook:        Business Email Compromise and Payment Fraud
id / version:    PB-BEC / v3.2
status:          Active            # Active | Draft | Revoked
owner:           R. Okonkwo — Manager, Detection & Response
                 deputy: Manager, Service Desk
approver:        IR Lead
created:         2025-02-11
modified:        2026-06-30
last_exercised:  2026-05-14  (TTX-2026-02) — 2 gaps found, both closed
next_review_due: 2026-12-30       # CI fails the build after this date
tlp:             TLP:AMBER+STRICT
default_severity: SEV-2
  escalate_to_SEV-1_if: funds have left the account, OR the compromised
                        mailbox belongs to an officer with payment authority,
                        OR mail rules were created on more than five mailboxes
entry_criteria:  see "When to run this"
exit_criteria:   see "When this is closed"
roles:           IC / Ops Lead / Comms Lead / Scribe / Legal Liaison / Exec Sponsor
pre_authorised:  see table §4      # actions requiring no approval
approval_gated:  see table §4      # action → authoriser → out-of-hours reach
evidence:        see §6            # artefacts, order, retention, custody
comms_hooks:     internal / customer / bank / regulator / insurer / counsel
on_playbook_failure: If the identity provider is unavailable or itself suspect,
                     STOP. Switch to PB-IDP and notify the IC. Do not improvise
                     around the missing control plane.
references:      T1078 Valid Accounts; RB-014 revoke-sessions; RB-021
                 mailbox-rule-audit; contact card CC-02 (printed)

Five of those fields do more work than all the rest, and they are the five teams skip.

owner is a person, not a team alias. "SOC" cannot be paged, cannot be asked why a step is wrong, and cannot be held to a review date. A named person with a named deputy can — and when that person leaves, the vacancy becomes visible.

last_exercised is the honesty field. It is the difference between a playbook and a hypothesis. If it is blank, the playbook is Draft. Say so in status, and mean it.

tlp tells the responder at 03:00 whether they may paste this into a vendor's support ticket. That question comes up constantly and gets answered badly under pressure.

on_playbook_failure is CACAO's workflow_exception in plain English, and it separates a playbook from a wish. Every playbook depends on infrastructure. Write down what the responder does when that infrastructure is the compromised thing.

next_review_due is only real if something enforces it. A date nobody checks is decoration.

The full blank template — every field, with guidance notes — is in Appendix B. Do not retype it from this page; copy it from there.

Actionable takeaway: Add owner, last_exercised, next_review_due, status and on_playbook_failure to every playbook you already have, this week, before writing a single new one. If you cannot fill in last_exercised, set status: Draft and let the gap be visible.

#Entry and exit criteria: the two fields everyone skips

A playbook without entry criteria gets opened for the wrong things and then distrusted. A playbook without exit criteria never closes; it just stops having meetings.

CISA's federal playbook carries an explicit "when to use this playbook" box, and — more usefully — a do not use list. Use it for confirmed malicious activity with major-incident potential: lateral movement, credential access, data exfiltration, intrusions involving more than one user or system, compromised administrator accounts. Do not use it for information spills believed to result from unintentional behavior only, users clicking a phishing email where no compromise resulted, or commodity malware on a single machine (CISA Federal Playbooks).

That second list is the one to steal. A "when to use" section alone reads as an invitation; the "do not use" section is what stops your SEV-2 process being invoked for a quarantined attachment at 02:00 on a Sunday for the fourth time this month.

There is a maintenance benefit too. Once entry criteria are written as observable conditions — these alerts, in this combination — every activation that turns out not to meet them is a defect logged against the detection, not a shrug. The peer-reviewed work on alert fatigue describes the mechanism plainly: high volumes with very high false-positive rates desensitize analysts, degrading both detection effectiveness and analyst wellbeing (Tariq et al., ACM Computing Surveys 57(9), 2025). You cannot fix that inside the playbook. You can make every false activation generate a ticket against the thing that caused it.

Exit criteria are harder, because they are gates rather than vibes. CISA's are worth copying in shape. Containment is complete when there are no new signs of compromise — at which point you preserve evidence, adjust detection tooling and move on. Before eradication may begin, three things must be true: all means of persistent access are accounted for, adversary activity is sufficiently contained, and all evidence has been collected. Recovery is validated by enhanced vigilance plus, ideally, "an independent test or review of compromise/response-related activity."

And the loop-back rule, which turns a falsely linear checklist into an honest one: if new signs of compromise appear during containment, return to technical analysis and re-scope; if new adversary activity appears after eradication, contain it and go back to analysis until the true scope and initial infection vector are identified. Write that rule in explicitly, with an arrow back to a numbered step — or your responders will read the numbering as a promise that the incident only travels one way.

Actionable takeaway: Give every playbook a "do not use this playbook for" list and a gated exit condition phrased as an observable absence — "no new signs of compromise," not "we think we got it." Then add one line: if new indicators appear, return to step 4.

#Severity that keys off the business, not the alarm

Severity levels exist to allocate scarce attention. NIST says the quiet part out loud: "Because of resource limitations, incidents should not be handled on a first-come, first-served basis," and prioritization should follow "scope, likely impact, time-critical nature, and resource availability" (NIST SP 800-61r3, RS.MA-02/03).

The most common design mistake is scoring the technical alarm rather than the business consequence. A critical CVSS score on a system nobody uses is not a SEV-1. An adversary with valid credentials on a domain controller is, even though nothing has "broken" yet.

CISA's National Cyber Incident Scoring System is the best public model to borrow from, because it is deliberately multi-dimensional — a weighted mean across eight categories rather than one judgement call. Three of them carry most of the weight for a corporate schema:

• Functional impact — "a measure of the actual, ongoing impact to the organization."
• Information impact — "the type of information lost, compromised, or corrupted."
• Recoverability — "the scope of resources needed to recover," across four levels: Regular (predictable with existing resources), Supplemented (predictable with additional resources), Extended (unpredictable; outside assistance may be required), and Not Recoverable.

(CISA NCISS)

Two further NCISS features are worth importing wholesale. First, location of observed activity, scored on a modified Purdue model running from "unsuccessful" up through business network management (admin workstations, Active Directory, trust stores) to critical and safety systems. That gives you a defensible, non-arbitrary reason why an adversary on a domain controller outranks an adversary on a laptop — a reason that survives an argument with a service owner. Second, the campaign aggregation rule: if three or more component incidents share the same high-water mark, the campaign's priority is raised a level. Most corporate schemas have no mechanism at all for turning many mediums into one severe.

NCISS is candid that its inputs are "a mixture of discrete and analytical assessments" and that "different individual scorers will inevitably have slightly different perspectives." That is the argument for a multi-factor rubric over one person's gut.

Here is a four-level schema you can copy. Take the highest row that applies — severity is a maximum across dimensions, never an average.

And the half everyone forgets — the level is meaningless without an attached obligation:

Three operating rules make the schema work under pressure.

Round up under uncertainty. PagerDuty's public rule is the right one: "If you are unsure which level an incident is… treat it as the higher one," and reassess at the post-incident review, never during (PagerDuty — Severity Levels). Downgrading is cheap and can be done calmly. Under-calling costs you the first two hours, which are the only two hours you will wish you had back.

Separate escalation from elevation. NIST distinguishes them and most schemas conflate them: "Escalation generally refers to increasing resources or time frames, while elevation usually indicates involving a higher level of management" (NIST SP 800-61r3, RS.MA-04). Write them as two separate gates with two separate triggers. "We need three more engineers" and "the CEO needs to know" are unrelated decisions, and merging them means one of the two always happens late.

Keep severity away from materiality. Your SEV number is an operational resourcing signal. It is not a legal determination and it does not start a regulatory clock. Under SEC rules, Item 1.05 disclosure is triggered by a materiality determination, and the four-business-day clock runs from that determination, not from discovery (SEC press release 2023-139). Two different processes, two different owners. Chapter 15 owns the clocks; Chapter 13 sets this book's operative severity definitions for the response lifecycle. This section is about how you design the schema in the first place.

Actionable takeaway: Publish a severity table where every level names who gets paged and what becomes pre-authorized at that level, and write "when in doubt, round up, and reassess at the review" directly into the definition. A severity level without an attached obligation is a label, not a control.

#Decision points a human can follow at 03:00

Most playbooks contain instructions. The good ones contain decisions — and a decision written badly is worse than no decision at all, because it manufactures a pause at exactly the wrong moment.

A well-formed decision point has five parts, and dropping any one of them breaks it:

1. A question answerable from observable evidence, not from judgement. "Is data currently leaving the environment?" is answerable. "Is this serious?" is a committee.
2. A deadline. How long may the team deliberate before the default fires.
3. A named authority — a role, plus a named deputy. Never a person's name; never a team.
4. Both branches, spelled out, with what each one costs.
5. A default under uncertainty, which is what actually happens when nobody can be reached.

CISA builds its federal playbooks around "illustrated decision trees" for exactly this reason. NIST requires the policy to name "which roles have the authority to confiscate, disconnect, or shut down technology assets." NCSC is blunter still: decision-makers must hold actual authority to approve major actions like taking systems offline, and deputies must be named for when primaries are unreachable (NCSC).

One more structural move, borrowed from CISA and badly underused: put the considerations before the actions. CISA's containment section forces three explicit weighings before any containment action is taken — additional adverse impact on mission and services; duration, resources and effectiveness (full versus partial containment, full versus unknown containment); and impact on the collection and preservation of evidence. That block sits above the action list, physically, on the page. It is a speed bump with a purpose.

Here is a worked decision point, rendered as a decision table. Run down the rows in order and stop at the first Yes.

Row 4 encodes the best-documented containment failure in the literature. Mandiant's articulation: "incident responders must recognize that each defensive action may prompt the adversary to react: organizations should delay implementing actions that will directly disrupt the attacker until they are ready to eradicate the threat completely" (Aldridge, Black Hat USA 2012).

Row 1 exists because that rule has an exception, and Aldridge names it himself — piecemeal containment is still correct when the loss is happening in real time. A decision table that encodes only the sophisticated answer will have a responder watching an estate encrypt while they wait for a fuller picture. Both rows, in that order, or neither is safe.

Actionable takeaway: For every decision in every playbook, write the deadline, the authorizing role, the deputy, and what happens by default if nobody answers. If a decision point has no default, it has no deadline either — it just has a queue.

#Pre-authorized versus approval-gated: the most useful table you will build

If you build only one table from this chapter, build this one. Three columns: Action | Who may authorize | Reach path out of hours.

Its purpose is to make the approval question disappear for the eighty per cent of actions where the answer is obviously yes, so that the remaining twenty per cent get real attention.

NIST places leadership decision-making authority on "high-impact response actions, such as shutting down or rebuilding critical services" (NIST SP 800-61r3, §2.2). It also flags an authority boundary that stays undefined in most organizations until the night it is tested: where an MSSP or cloud provider is involved, the contract must state any restrictions on the provider making and implementing operational decisions, such as immediately deactivating services to contain an incident. If you outsource detection, find out today whether your provider can isolate your production hosts at 04:00 without asking, and whether you want that.

The canonical worked example of authority done right is Colonial Pipeline. CEO Joseph Blount testified that the company learned of the attack shortly before 5am and within roughly an hour decided to shut down the entire pipeline; he later stated that "shutting down the pipeline was absolutely the right decision" (Blount, Senate HSGAC testimony, 8 June 2021). The lesson for playbook craft is not "shut down fast." It is that the decision to stop the business was made in under an hour by a named person who already knew it was theirs to make. Nobody spent that hour discovering who was allowed to decide.

So, per critical service, write down four things: who can stop it, who must be told, what evidence justifies stopping it, and what happens by default if that person is unreachable in fifteen minutes. That last field is the one that gets omitted and the one that gets tested.

Actionable takeaway: Build the three-column table this week and get it signed by the person whose revenue you are proposing to switch off. An authority you have not confirmed in peacetime is an authority you do not have. Not "in principle." Signed.

#Playbooks-as-code — and where the effort stops paying

The field has moved, and the evidence is in how the major publishers maintain their own. Microsoft ships its IR playbooks as Markdown in a public git repo with pull-request review (MicrosoftDocs/security). AWS ships a library and a shared template in git with contributing guidelines (aws-samples/aws-incident-response-playbooks). RE&CT keeps its actions as YAML for machines and Markdown for humans (atc-react). Counteractive keeps a whole plan-plus-playbooks repo in Markdown with info.yml metadata, rendering to docx, html and pdf from source via CI (counteractive/incident-response-plan-template).

The benefits are concrete and none of them are aesthetic: a diffable history that answers "when did this step change and why"; ownership as CODEOWNERS, so a change to the ransomware playbook must be reviewed by its owner; pull-request review as the approval workflow, which is auditable evidence that approval happened; tags as approved versions; issues as the improvement backlog.

The highest-value piece is the CI check, and it is small. Lint every playbook on every commit for: owner set and resolvable; last_exercised within N months; next_review_due in the future; every referenced runbook ID exists in the repo; every contact card referenced exists. Fail the build otherwise. A playbook untested for twelve months flips from Active to Draft automatically — not because someone noticed, but because the pipeline noticed.

Now the honest part, because this is where teams over-invest.

CACAO is worth it if you already run a SOAR platform and want playbook portability between tools rather than lock-in to a vendor's UI; open-source CACAO orchestrators exist (COSSAS/SOARCA). CACAO is not worth it if you have five playbooks and one and a half analysts. The machine-readable representation earns its keep when machines execute it. Until then it is a second copy of the truth, and second copies drift.

The cheap version, in full. A private git repository — free. One Markdown file per playbook. A CODEOWNERS file. A scheduled job that greps the next_review_due field and opens an issue when it passes; twenty lines of shell. pandoc to render PDFs. No CI at all? A recurring calendar invitation for each playbook's review date, with the owner as a required attendee and the rendered PDF attached — it does the same job, worse, for nothing.

And then the thing that survives everything else. Print it. CISA is explicit: "Print these documents and the associated contact list and give a copy to everyone you expect to play a role in an incident. During an incident, your internal email, chat, and document storage services may be down or inaccessible" (CISA IRP Basics). This is the paradox of playbooks-as-code and there is no clever way around it: the source of truth lives in a system that an adversary may take from you on exactly the night you need it. The British Library, with its website and intranet down, fell back to social media and email and WhatsApp cascades (British Library, Learning Lessons from the Cyber-Attack).

Your IR tooling, ticketing, contact list, credential vault and backup catalog must not depend on the identity plane you are about to declare compromised. Neither must your playbook. Print it. Date the printout. Reprint it every quarter. Not eventually. Quarterly.

Actionable takeaway: Put your playbooks in git today and add one CI check — fail the build if last_exercised is older than twelve months. Then print the current set with the contact list and hand a copy to everyone with a role. Both halves, or neither works.

#Maintenance: how playbooks actually die

They do not die dramatically. They die by field.

CISA's cadence recommendation is unusually aggressive and worth adopting as a stretch target: "Review this plan quarterly. The best IRPs are living documents that evolve with business changes" (CISA IRP Basics). NIST SP 800-53 IR-8 makes the frequency an explicit organizational parameter — you must choose one and document it, and "when we get to it" is not a parameter (CSF Tools — IR-8).

Calendar cadence alone produces a review that finds nothing. Add event triggers, taken from where NIST says improvements actually come from: evaluations and audits (ID.IM-01); tests and exercises, rated High priority (ID.IM-02); and the execution of operational processes, also High, where improvements are "often identified when creating follow-up reports for incidents or holding 'lessons learned' [meetings]" (ID.IM-03) (NIST SP 800-61r3, Table 2). Add environmental change: new systems, new suppliers, new regulations, a reorganization that moved an authority.

Write those triggers into the playbook header, so the obligation travels with the document:

CISA's hotwash objectives name the one thing to check every single time, and it is on the list because it is a recurring finding: "Reviewing and updating roles, responsibilities, interfaces, and authority to ensure clarity." Authorities rot faster than steps. A reorganization does not send a notification to your playbooks.

What makes post-incident updates real is pairing each finding with an owner and a due date — the after-action report and improvement plan pattern CISA uses in its tabletop packages (CISA CTEP). A finding without an owner is a paragraph. Chapter 18 covers exercise design; the only maintenance rule that matters here is that exercise output becomes tracked issues, not a slide.

Actionable takeaway: Set a documented review frequency, then add the four event triggers to every playbook header with a deadline attached to each. Assign the post-incident update to the playbook owner with a ten-day due date, tracked where you track everything else that has to actually get done.

#The failure modes, from real post-incident reports

Chapter 13 covers how incident response fails. These are the narrower set: documented ways the document fails. Each has a fix that fits in a header field or a table.

CISA's federal playbook adds a structural one worth budgeting for: segment and manage SOC systems separately from broader enterprise IT, so that "IR and defensive systems and processes will be operational during an attack."

Actionable takeaway: Turn every row of that table into one line on your preparation checklist, with an owner and a frequency. If you can only do one, test the contact cascade — it is free, it takes twenty minutes, and a stale recipient list is the documented reason one of the largest breaches on record got its window.

A playbook is not a document. It is a set of decisions you made while calm, written down where a tired person can find them. Every hour spent in a quiet room arguing about who is allowed to shut down the billing system is an hour bought back at four in the morning, at a very favourable exchange rate. Spend it now. Print the result. Stay rehearsed, stay boring, and never let a plan be the only copy.

#Chapter checklist

• CRAFT-01A written incident response plan exists, is formally approved by senior leadership, and is under fifteen pages with no commands or tool-level steps in it. [IG1] [GV.PO] [CIS 17] [A.5.24]
• CRAFT-02Every playbook has a named individual owner and a named deputy — not a team alias or distribution list. [IG1] [GV.RR] [A.5.24]
• CRAFT-03Every playbook header carries: id, version, status, owner, approver, created, modified, last_exercised, next_review_due, and TLP marking. [IG1] [GV.PO]
• CRAFT-04Every playbook states entry criteria as observable conditions, and a "do not use this playbook for" list. [IG1] [RS.MA] [A.5.25]
• CRAFT-05Every playbook states exit criteria as a gated, observable condition (for example "no new signs of compromise"), not a subjective judgement. [IG2] [RS.MA]
• CRAFT-06Every playbook contains an explicit loop-back rule directing responders back to the analysis step when new indicators are found. [IG2] [RS.AN]
• CRAFT-07Every playbook has an on_playbook_failure instruction covering what to do when the infrastructure the playbook depends on is unavailable or itself suspect. [IG2]
• CRAFT-08A severity schema of four or fewer levels is published, keyed to business impact across at least functional impact, information impact and recoverability. [IG1] [RS.MA-02] [CIS 17]
• CRAFT-09Each severity level names who is paged, the declaration deadline, the executive update cadence, and what becomes pre-authorized at that level. [IG1] [RS.MA-03]
• CRAFT-10The severity definition contains an explicit round-up-under-uncertainty rule, with reassessment deferred to the post-incident review. [IG1] [RS.MA-02]
• CRAFT-11Escalation (more resources) and elevation (higher management) are defined as separate gates with separate triggers. [IG2] [RS.MA-04]
• CRAFT-12Severity classification is documented as operationally distinct from any regulatory materiality determination, with different named owners. [IG2] [RS.CO]
• CRAFT-13Every decision point in every playbook states a deadline, an authorizing role, a named deputy, both branches, and a default action if the deadline passes undecided. [IG1] [GV.RR]
• CRAFT-14A pre-authorized actions table exists, listing actions responders may take with no approval and log afterwards. [IG1] [RS.MI]
• CRAFT-15An approval-gated actions table exists with three columns — action, authorizing role, out-of-hours reach path — and is signed by the executive whose services it covers. [IG1] [GV.RR] [A.5.24]
• CRAFT-16For every critical business service, the plan names who may stop it, who must be told, what evidence justifies stopping it, and the default if that person is unreachable within a stated interval. [IG2] [GV.RR]
• CRAFT-17Contracts with any MSSP or managed provider state explicitly whether the provider may take unilateral containment action on your estate. [IG2] [GV.SC]
• CRAFT-18Containment sections place a considerations block — mission impact, containment duration and effectiveness, evidence impact — above the action list. [IG2] [RS.MI]
• CRAFT-19Playbooks are stored in version control with per-playbook ownership and change review recorded before merge. [IG2] [GV.PO]
• CRAFT-20An automated check fails or flags any playbook whose last_exercised date is older than the documented interval, and such playbooks are marked Draft. [IG3] [ID.IM-02]
• CRAFT-21Playbooks reference atomic, separately-owned runbooks by ID rather than inlining commands, so a tool change is fixed once. [IG3] [GV.PO]
• CRAFT-22A current printed copy of the plan, active playbooks and the contact card is held by every person with an assigned response role, dated and reissued at a documented interval. [IG1] [RC.CO] [A.5.29]
• CRAFT-23A documented review frequency exists, plus four event triggers — real activation, exercise, audit finding, and change of tooling/supplier/authority/regulation — each with a deadline and an owner. [IG1] [ID.IM-01] [ID.IM-03] [A.5.27]
• CRAFT-24Post-incident and post-exercise findings are tracked as owned, dated items in the same system used for other committed work, and closure is verified. [IG2] [ID.IM-03] [A.5.27]
• CRAFT-25The response contact cascade is tested against a stated time limit at least annually, and the test result is recorded. [IG1] [RS.CO] [A.6.8]

#Sources

1. GAO-18-559, Data Protection: Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach
2. Harrison, Y. & Horne, J.A. (2000), The Impact of Sleep Deprivation on Decision Making: A Review
3. CISA, Incident Response Plan (IRP) Basics
4. NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
5. AWS Security Incident Response Guide — Runbooks
6. AWS Well-Architected SEC10-BP04 — Develop and test security incident response playbooks
7. CISA, Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
8. NCSC, Incident management — Plan: your cyber incident response processes
9. RE&CT Framework and atc-project/atc-react
10. OASIS CACAO Security Playbooks v2.0
11. COSSAS/SOARCA — open-source CACAO orchestrator
12. CISA, National Cyber Incident Scoring System (NCISS)
13. PagerDuty Incident Response — Severity Levels
14. SEC press release 2023-139 — Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure
15. Aldridge, J., Remediating Targeted-threat Intrusions, Mandiant / Black Hat USA 2012
16. Blount, J., Senate HSGAC testimony, 8 June 2021 (Colonial Pipeline)
17. MicrosoftDocs/security — incident response playbooks
18. aws-samples/aws-incident-response-playbooks
19. counteractive/incident-response-plan-template
20. CSF Tools — NIST SP 800-53 r5 IR-8, Incident Response Plan
21. CISA Tabletop Exercise Package (CTEP) documents
22. British Library, Learning Lessons from the Cyber-Attack, March 2024
23. Healthcare Dive — Change Healthcare compromised credentials, no MFA
24. CISA — I've Been Hit By Ransomware
25. Cyber Safety Review Board, Review of the Summer 2023 Microsoft Exchange Online Intrusion
26. Tariq, Baruwal Chhetri, Nepal & Paris, Alert Fatigue in Security Operations Centres, ACM Computing Surveys 57(9), 2025