Fourteen playbooks written to be executed at 3 a.m. by somebody who did not write them — each one a separate page, so you can open the one you need.
Every playbook from 14.1 to 14.14 uses the same ten-part shape. Learn it once and you can execute any of them cold.
| Part | What it gives you |
|---|---|
| Playbook ID | Stable identifier (PB-RANSOM, PB-BEC, …) for cross-references, ticket templates and exercise records. It never changes, even when the content does. |
| Default severity | The SEV level this incident type opens at, per the schema in Chapter 13. A floor, not a ceiling: if you are unsure between two levels, take the higher one and reassess at the post-incident review, never during. |
| Entry criteria | The observable conditions that justify opening this playbook. If they are not met, you are in the wrong playbook. |
| What you are dealing with | A short threat-model briefing: how this scenario actually behaves, what the current numbers say about it, and the one thing about it that breaks a generic response. Read it in peacetime. Skip it at 03:00. |
| Roles for this incident | The seats this scenario needs, on top of the six incident command roles from Chapter 13 — a Recovery Lead for ransomware, a Parallel Intrusion Watch for DDoS, a named Engineering Authority for OT. It is also where the playbook declares the markers it uses inside its own step tables. |
| The five phases | Detection and Triage → Containment → Eradication → Recovery → Post-Incident. Each phase is a step table: action, owner, done-when, evidence to capture. Scoping is not a separate phase here — it lives inside Detection and Triage, which is roughly where the AWS library puts it too (AWS SEC10-BP04). Phase 5 is not paperwork: it carries the timeline, the lessons learned, the edits back into this playbook, and any regulatory notification still owed. |
| Decision points | Marked [!DECISION], each with a deadline, a named authorizing role, the conditions for each branch, and a default if the deadline passes undecided. |
| Communications triggers | Where internal, customer, regulator, insurer, law-enforcement or counsel contact becomes due, and who owns it. The clocks themselves live in Chapter 15. |
| Automation notes | Which steps a SOAR workflow or agent runs unattended, which need a human gate, and what the automation must log. Design rules are in Chapter 17. |
| Pitfalls | The specific ways this scenario is habitually botched, with the consequence. |
Two markings appear inside step tables and override the printed order of operations. They exist because the two most expensive mistakes in response are both mistakes of sequence.
| # | Playbook | ID | Default SEV | Run this when |
|---|---|---|---|---|
| 14.1 | Ransomware with Data Exfiltration | PB-RANSOM | SEV-1 | Files are encrypted, a ransom note is found, or a demand references your data. |
| 14.2 | Business Email Compromise and Payment Fraud | PB-BEC | SEV-3 | A payment, payroll or bank-detail change was requested or made on a fraudulent instruction. |
| 14.3 | SaaS and Cloud Account Takeover | PB-ATO | SEV-3 | A user session, token or OAuth grant is being used by someone who is not the user. |
| 14.4 | Identity Provider and Privileged Credential Compromise | PB-IDP | SEV-2 | The IdP, a tenant or domain admin, or the credential vault is suspected compromised. |
| 14.5 | Third-Party and Supply Chain Breach | PB-SUPPLY | SEV-2 | A vendor, package, CI action or integration you trust has been compromised. |
| 14.6 | Insider Threat | PB-INSIDER | SEV-3 | An authorized person is suspected of misusing access or exfiltrating on departure. |
| 14.7 | Data Breach with Regulatory Obligations | PB-BREACH | SEV-2 | Regulated, contractual or personal data is confirmed or reasonably suspected to have left your control. |
| 14.8 | DDoS and Service Unavailability | PB-DDOS | SEV-2 | A public service is degraded or unavailable under volumetric or application-layer load. |
| 14.9 | Deepfake and AI-Enabled Social Engineering | PB-DEEPFAKE | SEV-3 | Synthetic voice, video or identity was used to pressure a person into an action. |
| 14.10 | Kubernetes and Container Compromise | PB-K8S | SEV-2 | Container escape, cluster credential abuse, or a workload doing something it has never done. |
| 14.11 | AI System Compromise | PB-AISYS | SEV-2 | A model, agent, RAG store or tool chain acted outside its intended authority. |
| 14.12 | Edge Device and Perimeter Appliance Exploitation | PB-EDGE | SEV-2 | A VPN, firewall or gateway at your perimeter is exploited or KEV-listed and exposed. |
| 14.13 | Web Application Compromise and Mass Exploitation | PB-WEBAPP | SEV-2 | Your public application is compromised, or is being mass-exploited alongside everyone else's. |
| 14.14 | OT and ICS Incident | PB-OT | SEV-1 | Anything touching engineering workstations, control loops, or the safety of a physical process. |
It usually will. Attacks arrive as chains, not categories: an exploited edge appliance yields credentials, the credentials yield the estate, the estate gets encrypted. Akira's operators used a SonicWall vulnerability for initial access (CISA AA24-109A), and Mandiant now ranks "prior compromise" as the most common ransomware initial vector at 30% — ransomware increasingly inherits access rather than earning it (M-Trends 2026). Picking one playbook and filing the rest under "later" is how a chain becomes a catastrophe.
Four precedence rules, in this order:
PB-IDP is primary and every other containment step waits on it. You cannot contain anything through an authentication system the adversary controls — and a password reset alone does not evict an attacker holding a stolen session token or an approved OAuth grant.PB-RANSOM now, not after encryption confirms it. Operators increasingly target your ability to recover, not only your ability to operate (M-Trends 2026).PB-BREACH in parallel at T+0. Notification obligations key off determinations and elapsed time, not off your technical progress. See Chapter 15.PB-SUPPLY runs alongside the technical playbook, because there is often nothing on your side to patch — only tokens to rotate and grants to revoke.Run the relevant playbooks concurrently, as workstreams under a single Incident Commander. Each playbook contributes a workstream lead; none of them contributes a second command structure. Two Incident Commanders produce two timelines, two evidence sets, and two incompatible answers to "is it contained?"
Every playbook that follows carries placeholders in angle brackets — <EDR console>, <IdP admin role>, <out-of-band bridge>. They are deliberate, and they are your homework. A playbook still full of angle brackets is a map of a building nobody has visited.
Three localization steps carry most of the value. Name a deputy for every authority: NCSC's position is that decision-makers must hold real authority to take systems offline, and that stand-ins must be identified in advance (NCSC). Choose the out-of-band channel in peacetime — the British Library ran its response on social media and email cascades with its website and intranet down (British Library review). And print it. CISA is blunt about why: during an incident your internal email, chat and document storage may be unreachable (CISA IRP Basics).
Actionable takeaway: make two passes over each playbook you adopt. First, fill every placeholder. Second, delete every step your organization genuinely cannot perform, and replace it with the one it can — a short playbook you can execute beats a complete one you cannot. Do it before you need it. Not during. Before.