Incident Response Playbooks — Five NIST-Aligned Runbooks

What it answers

When an incident lands, the question isn't "do we have a policy for this" — most SOCs do. It's "will the analyst on shift right now execute the same steps, in the same order, with the same escalation triggers, as the analyst who wrote the playbook six months ago?" This repo answers that by giving each of the five most common incident types (phishing, malware, account compromise, data breach, DDoS) its own standalone runbook with an identical section structure — Purpose, Scope, Prerequisites, Detection Criteria, Response Steps by SANS phase, a Mermaid decision tree, an escalation table, an evidence checklist, recovery actions, communication templates, and post-incident activities — so an analyst who's internalized one playbook's shape can navigate any of the other four without relearning the format.

Framework basis — and why it deliberately cites two NIST revisions

The repo is built on NIST SP 800-61 Rev. 2's four-phase lifecycle (Preparation → Detection & Analysis → Containment, Eradication & Recovery → Post-Incident Activity) — still the operational basis CISA's own 2024 federal incident-response playbooks cite, even though it was formally withdrawn. NIST SP 800-61 Rev. 3 (April 2025) is the current official replacement, but it drops the standalone phase model in favor of mapping IR activity across the six NIST CSF 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover) — a governance/risk-integration document, not an analyst run-book. Rather than silently pick one, the README states plainly that Rev. 3 is current while Rev. 2's phase model (via SANS' more granular six-phase derivative) remains what's actually used for day-to-day playbook authoring, and includes an explicit mapping table between all three so the same playbook works whether the person on the other end of an escalation was trained on NIST or SANS terminology.

Scale

Severity model — two layers, on purpose

Every playbook shares the same four-tier severity matrix (Critical / High / Medium / Low) for fast triage — it maps directly to initial response time and who gets notified, e.g. Critical means immediate paging of CISO/IT leadership/Legal, while Low is logged only. For incidents that need to be reported formally to leadership or regulators, the playbooks cross-reference the CISA/NCISS three-axis model instead — Functional Impact, Information Impact, and Recoverability scored independently — specifically because collapsing everything to one severity word hides the difference between a small but highly sensitive data exposure and a large but fully-absorbed DDoS attack; both can be "significant" without being equivalent incidents.

Phishing Incident Response

Covers reported and gateway-flagged phishing, credential-harvesting links, and BEC lures. The playbook's Identification phase makes a specific move: after pulling headers and detonating the URL/attachment in a sandbox, the analyst must search for every other recipient of the same message and classify each one's interaction (no interaction / clicked, no credentials / credentials entered / attachment executed) — because "phishing is rarely single-target," and that per-recipient classification is what actually drives severity, not the reporting user's own outcome alone.

Key decision-tree branch: if a user clicked a link that led to a credential-entry page and entered credentials, severity jumps to High and containment requires a coordinated password reset + session/token revocation + MFA re-registration in one action — then a further branch checks for evidence of post-compromise activity (a new mailbox rule, an OAuth grant, a suspicious sign-in). If that evidence exists, the incident escalates directly into the Account Compromise Playbook, and further into the Data Breach Playbook if data was actually accessed — the trees are wired to hand off into each other, not just to a generic "escalate" endpoint.

Malware Infection Response

Covers AV/EDR-flagged execution, ransomware, and C2 beacon activity tied to a host. The Containment phase is explicit about a common instinct to avoid: never power off an infected host — it destroys volatile memory evidence and, for ransomware already mid-encryption, doesn't even reliably stop the process on battery/UPS power. Network isolation via EDR is used instead, deliberately preserving EDR agent communication for continued visibility.

Key decision-tree branch: confirmed ransomware or active encryption behavior routes straight to Critical severity with full segment isolation and a backup-integrity check performed before any other action touches backup infrastructure — because backups are noted as a common secondary target once an actor has domain-level access. A separate branch checks whether the malware has live C2 connectivity: if beaconing is confirmed, the incident is treated as an active ongoing compromise requiring full forensic collection before reimaging, rather than routine eradication.

Account Compromise Response

Covers stolen credentials, impossible-travel sign-ins, session/token theft, and BEC. A structural detail worth calling out: containment requires revoking sessions and refresh tokens together with the password reset, because the playbook notes a password reset alone does not invalidate already-issued session tokens — a gap that's easy to miss under pressure. Identification also specifically checks for new mailbox rules and OAuth app consents before looking at sign-in logs alone, since those are the most common post-compromise persistence mechanisms and get missed if an analyst stops at sign-in history.

Key decision-tree branch: once unauthorized access is confirmed, the tree branches on what action the account took — a mailbox rule, OAuth grant, or BEC email sent routes to High severity with recipient notification if the BEC went external; sensitive data accessed/downloaded or privilege escalation/new-account creation both route straight to Critical and trigger the Data Breach Playbook in parallel.

Data Breach Response

Covers unauthorized access to or exfiltration of sensitive data, and is explicitly designed to run in parallel with whichever playbook covers the initial compromise (phishing/malware/account compromise), rather than standalone. Its defining structural difference: Legal/Compliance is engaged immediately, in parallel with technical investigation, not after technical confirmation — because notification clocks (GDPR Article 33's 72-hour requirement is called out by name) can start from the moment of awareness, not certainty. This is also the only playbook with a joint ownership line: SOC owns the technical response, Legal & Compliance own the regulatory/notification side.

Key decision-tree branch: the central branch is whether data was merely exposed/accessible (e.g. a misconfigured public bucket with no evidence of access) versus actually accessed versus exfiltrated — each maps to a different severity and a different evidentiary bar for Legal's notification decision. Exposure-only with no access-log evidence of exploitation still gets documented for Legal review rather than closed outright, since exposure itself can trigger notification obligations independent of confirmed access.

DDoS Attack Response

The odd one out by design: the playbook opens by noting this is primarily an availability incident, not confidentiality/integrity, so priority order and tooling differ from the other four. Identification requires explicitly ruling out legitimate-traffic explanations (a viral marketing spike, a misconfigured internal scraper) before committing to mitigation, since misapplying aggressive rate-limiting to legitimate traffic risks causing a self-inflicted outage on top of — or instead of — the real one. Severity is scored on actual customer/business impact rather than raw attack volume: a large attack fully absorbed with zero visible impact can rate lower than a smaller attack that fully takes out a customer-facing service.

Key decision-tree branch: attack vector classification (volumetric/protocol vs. application-layer) determines which mitigation layer is used — upstream scrubbing versus WAF/rate-limiting — and a separate branch checks for an extortion demand, which routes directly to Legal/Executive with an explicit instruction not to engage the attacker directly, preserving the communication as evidence instead.

Reusable templates

Four incident-type-agnostic templates live under templates/, referenced by all five playbooks rather than duplicated inside each one:

• Stakeholder Notification Template — the general format every playbook's incident-specific communication snippets (to affected users, executive leadership, external recipients) are built from.
• Executive Summary Template — used where the four-tier severity matrix isn't precise enough and the CISA/NCISS three-axis impact classification is needed instead.
• Post-Incident Review Template — required within 5 business days of closure for every playbook (immediately, not on the full window, for Critical/ransomware incidents).
• Evidence Chain-of-Custody Log — invoked by name in every playbook's Evidence Collection section for anything that may support HR/legal action, law-enforcement referral, or regulatory inquiry.