The canonical model, vocabulary, roles and gates that every scenario playbook in this book assumes you already have.
Who needs this: CISO, SOC lead, IR lead, incident commanders, IT operations, Legal, executive sponsors | Read time: 30 min | Maps to: CSF 2.0 DETECT (DE.AE, DE.CM), RESPOND (RS.MA, RS.AN, RS.CO, RS.MI), RECOVER (RC.RP, RC.CO), IDENTIFY (ID.IM), GOVERN (GV.RR) | CIS v8.1 Controls 8, 11, 13, 17 | ISO/IEC 27001:2022 A.5.24–A.5.30, A.6.8, A.8.15
Welcome to Part III, fellow defenders. Everything up to here was about not having a bad night. This part is about the bad night.
Here is the number that should reset your sense of tempo. In Mandiant's 2025 frontline investigations, the median hand-off between an initial-access broker and the group that did the damage was 22 seconds — down from more than eight hours in 2022 (M-Trends 2026). The comfortable assumption that a "commodity" alert can wait for the morning shift is dead. Meanwhile global median dwell time went up, to 14 days: 26 days when an outside party told the victim, 10 when the victim found it themselves, 5 when the adversary announced themselves with a ransom note.
That spread is the whole argument for this chapter. Two organizations can suffer the same intrusion and separate by three weeks of adversary access on the strength of their response discipline alone. Neither of them bought their way out of it. One had a plan that named a decision-maker; the other had a PDF.
The British Library published one of the most useful post-incident reviews in our field, and its fourth lesson is a single sentence: "An in-depth security review should be commissioned after even the smallest signs of network intrusion." Their forensics indicated the attackers likely had access at least three days before the attack became apparent (British Library, Learning Lessons from the Cyber-Attack). Small intrusions are not small. They are the visible 5% of something nobody has scoped yet.
What follows is the shared vocabulary the rest of Part III runs on: the lifecycle, the severity scale, the command roles, the evidence rules, and the gates between phases. Chapter 14 assumes all of it. Chapter 15 owns the notification clocks and the legal machinery in detail; this chapter tells you when to pull those levers, not how to draft them.
Two respectable models are on the table in 2026, and they are not fighting.
SANS PICERL — Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned — is a teaching and sequencing model. Six steps, in order.
NIST SP 800-61 Rev. 3, final since April 2025 and superseding Rev. 2 from 2012, is a program architecture model. It deliberately abandons the circular four-phase lifecycle and restructures incident response as a CSF 2.0 Community Profile (NIST SP 800-61r3). Its stated reason is a description of your job changing under you: the old model assumed incidents were rare, narrow, and "usually completed within a day or two," which made it "realistic to treat incident response as a separate set of activities performed by a separate team."
Rev. 3's replacement is three tiers instead of a circle. The bottom tier — GOVERN, IDENTIFY, PROTECT — is explicitly not incident response; it is the broader risk management that makes response possible. The top tier — DETECT, RESPOND, RECOVER — is the response. Between them sits Improvement (ID.IM) as a permanent connective layer, fed by lessons from every Function at any time, including mid-incident. NIST is blunt that "organizations can learn new lessons at all times."
Two consequences, neither cosmetic. First, most of your response readiness is owned outside your response team — asset inventory, access control, logging architecture, supplier governance. Scope your IR program to DETECT/RESPOND/RECOVER and you have scoped out the work that decides whether it succeeds. Second, "lessons learned" stops being a meeting in three weeks. If your only improvement trigger is the post-incident review, you have implemented PICERL and put a CSF 2.0 sticker on it.
So which does the book use? Both, at different altitudes — which is what NIST recommends, saying outright that "organizations should use the incident response life cycle framework or model that suits them best."
The canonical model for this book. Six elements, five sequential and one continuous: Preparation → Detection and Analysis → Containment → Eradication and Recovery → Post-Incident Activity, with Coordination running across all of them.
That is the structure of CISA's Cybersecurity Incident & Vulnerability Response Playbooks, issued November 2021 under Executive Order 14028 §6 (CISA). It is phase-ordered because a responder at 03:00 needs a sequence, not an architecture diagram. We use 800-61r3 and CSF 2.0 for the program layer — control mapping, board reporting, audit evidence, continuous improvement — and the phase model for the runbook layer. The old sequence also survives inside NIST SP 800-53 Rev. 5 control IR-4, so this is not nostalgia; it is still the language of your auditor.
One caution about the CISA source. It was written for federal civilian agencies, anchored on 800-61 Rev. 2, and it predates most of what makes 2026 hard: CIRCIA, the SEC disclosure rules, identity-plane compromise, cloud forensics, AI systems as assets under attack, and any concept of running the investigation under counsel. Where this chapter follows CISA, it says so. Where 2026 demands more, it says that too.
Actionable takeaway: Pick one lifecycle model, write it into your incident response plan, and make every playbook use its phase names verbatim. Two teams describing one incident in two vocabularies is not a documentation problem. It is a handover failure waiting for a Saturday.
Preparation is the only phase you can do today, calmly, with a coffee. CISA's objective for it belongs above the SOC door: "to ensure resilient architectures and systems to maintain critical operations in a compromised state."
Below are CISA's readiness requirements and the preparation checklist in its own Appendix C, rendered as things you can go and verify this week. Chapter 9 owns detection engineering and logging strategy; Chapter 12 owns backup and recovery. This is the response-readiness slice.
| # | Readiness item | Verify by | Common failure |
|---|---|---|---|
| 1 | IR plan exists, naming the coordination lead role and escalation path | Open it; find the role authorized to declare | Plan exists; nobody can find it |
| 2 | Surge/contingency resourcing with assigned roles | Confirm the retainer is signed, not quoted | Retainer expired |
| 3 | Telemetry: AV, EDR, DLP, IDPS, host/app/cloud logs, flow, PCAP, SIEM | Pick three critical systems; confirm each reports today | Agent silent for six weeks |
| 4 | Baselines for systems and networks | Ask what normal outbound traffic is for your top data store | No baseline; every anomaly is "probably fine" |
| 5 | Log retention exceeding plausible dwell time, crucial sources longest | Compare against 14-day median and 122-day espionage median | Cloud audit logs expire mid-investigation |
| 6 | Trained, exercised personnel | Date of last exercise; over 12 months means untrained | Trained once, at onboarding |
| 7 | Recovery exercises testing failover and restore end to end | Date and measured duration of the last tested restore | Backups verified, restores never attempted |
| 8 | Threat intelligence wired into detections at TTP level | Ask which ATT&CK techniques your detections cover | Feed subscribed; nothing built on it |
| 9 | Out-of-band comms independent of the production identity plane | Try to join the bridge without corporate SSO | War room lives in the tenant you just declared compromised |
| 10 | Printed plan and contact list held by every role-holder | Look at a physical copy | "It's in SharePoint" |
| 11 | SOC segmentation; sensors managed out of band; hardened analyst workstations | Confirm the SIEM does not authenticate against production AD | Analysts locked out at the moment they are needed |
| 12 | Secure evidence storage, responders only | Try to list it as an ordinary admin | Evidence on a shared drive |
| 13 | Forensic capability: disk and memory acquisition, malware handling, sandbox | Name the tool and the last successful use | License lapsed |
| 14 | Case management capturing systems, users, activity type, threat group, TTPs, impact | Read last year's biggest incident record | The record was a Slack thread that has aged out |
| 15 | Agreements pre-signed: IR retainer, outside counsel, forensics engaged through counsel, carrier contacts, MSP/CSP evidence-access clauses | Confirm each is executed with a current after-hours number | Everything is "in procurement" |
Three of those quietly decide the outcome.
Out-of-band communications. CISA is unambiguous: notify users of compromised systems by phone, not email, manage sensors out of band, and do not submit malware samples to a public analysis service — because some adversaries actively monitor your response. Failing to use out-of-band methods "could cause actors to move laterally to preserve their access or deploy ransomware widely prior to networks being taken offline" (CISA). Announcing your investigation in the channel the intruder is reading is like planning the surprise party in the kitchen while the guest of honour makes toast.
The printed copy. Mocked until the day it isn't. CISA: "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). The British Library, website and intranet down, ran on social media plus email and WhatsApp cascades. Your playbooks-as-code repository is excellent engineering and completely unreachable if it authenticates against the directory you are rebuilding.
The cheap version. For a small organization, preparation's minimum viable artefact is one laminated page: who declares, and the numbers that reach the carrier, counsel, the IR firm, CISA and the FBI. Cost: nothing. None of the top five rows above needs an enterprise budget.
Actionable takeaway: Assign each of the fifteen rows an owner and a date, then verify five this week by testing them rather than asking whether they are true. Start with row 9 — try to reach your war room without SSO. Today. Not after the next tabletop.
CISA calls this "the most challenging aspect of the incident response process": determining whether an incident has occurred and, if so, its type, extent and magnitude.
Deconflict first. Confirm the suspected incident is not authorized activity — CISA's own example is a network administrator using remote admin tools for software updates. Build a fast deconfliction path with a named on-call in IT operations who can confirm or deny within minutes. The alternative is either a war room stood up over a patch window or, far worse, a team that has learned to assume every alert is the patch window.
Declaring is not a confession. It is an administrative act that turns on the machinery, and it is reversible.
Three triggers that work because they are observable rather than judgement calls (Google SRE Book): a second team must be involved; customers see a disruption; the issue persists beyond one hour of focused analysis. Add three from CISA's "when to use this playbook" criteria as the book's floor: evidence of lateral movement, credential access or exfiltration; an intrusion involving more than one user or system; a compromised administrator account.
Then write in the rule that ends the 02:40 debate: declare, don't debate. Managed incidents resolve faster, and early declaration prevents miscommunication between teams. Under-declaring costs time you cannot recover. Over-declaring costs a bridge call and an apology.
Scoping means identifying the type of access, the extent to which assets are affected, the privilege level attained, and the operational or informational impact. CISA then supplies the most reusable page in the document — the questions responders must answer, in writing, and keep updating:
Question 7 most often changes the severity. Question 11 starts the regulatory clocks. Neither answers itself.
Preserve during analysis, not after containment. Collect from the perimeter, the internal network and the endpoint, preserving data for verification, categorization, prioritization, mitigation, reporting and attribution — and where possible as best evidence for a law-enforcement investigation. Where a host needs forensic analysis, capture memory and disk before anything else touches it. Mechanics are in the evidence section below.
CISA gates technical analysis on six conditions. Copy them verbatim. Analysis is complete only when the incident is verified; the scope determined; the methods of persistent access identified; the impact assessed; a hypothesis for the narrative of exploitation exists with TTPs and IOCs; and all stakeholders are proceeding with a common operating picture. That last one is not paperwork — it is why handovers fail and why executives decide on stale facts.
CISA's phrasing is that "an incident is scoped over time." Every new indicator feeds detection tools, produces new hits, and widens or narrows the picture — and each widening must be communicated so the common operating picture stays common.
Actionable takeaway: Put the eleven questions and the six-part terminating condition on one page of your plan, and require the Scribe to record an answer or an explicit "unknown" for each before any containment action that is not immediately reversible. "Unknown" is a legitimate answer. Silence is not.
Severity exists to attach a response obligation to an incident, fast and without argument. A level with no obligation attached is decoration.
Two design rules first. Key severity to business impact, not technical alarm — 800-61r3 names the factors as asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization and recoverability, and states the thing most triage queues violate daily: "Because of resource limitations, incidents should not be handled on a first-come, first-served basis" (RS.MA-02). And separate escalation from elevation: "Escalation generally refers to increasing resources or time frames, while elevation usually indicates involving a higher level of management" (RS.MA-04). A SEV-3 running long needs escalation. A SEV-3 that just touched regulated data needs elevation. Write both gates.
This scale governs every playbook in Chapter 14. It compresses the structure of PagerDuty's published five-level schema, which ties severity to customer and business impact rather than component failure (PagerDuty).
| Level | Business meaning | Typical triggers | Response obligation |
|---|---|---|---|
| SEV-1 | Material harm occurring or effectively certain | Enterprise-wide encryption or destruction; confirmed identity-plane compromise (Tier 0, IdP, krbtgt, global admin); confirmed exfiltration of regulated data at scale; safety system affected; critical customer service down with no ETA | IC paged immediately; war room within 30 min; Executive Sponsor and Legal Liaison at T+0; 24×7 shifts with named deputies; notification clocks assessed at T+0; executive update every 30 min |
| SEV-2 | Serious, bounded, credibly capable of becoming SEV-1 | Unauthorized access beyond one host or account; confirmed lateral movement; compromised administrator account; critical service materially degraded; extortion contact received | IC paged; bridge within 60 min; Legal Liaison on standby; Executive Sponsor briefed at first update; extended on-call; executive update every 2 h |
| SEV-3 | Confirmed malicious activity, confined, no evidence of spread | Single compromised account with no lateral movement; single host, commodity malware contained by EDR; non-critical service impaired | Security on-call with a named lead; IC optional; daily summary; loop-back rule still applies |
| SEV-4 | Suspicious activity or policy violation, no confirmed compromise | Phishing reported and not clicked; policy violation; anomalous but explained activity | Ticketed, worked in business hours |
Four rules make the scale work:
CISA's National Cyber Incident Scoring System produces a 0–100 weighted arithmetic mean across eight weighted categories: Functional Impact, Observed Activity, Location of Observed Activity, Actor Characterization, Information Impact, Recoverability, Cross-Sector Dependency and Potential Impact (CISA NCISS). Three belong in any corporate rubric:
Recoverability is the dimension corporate schemas most often omit and the one an executive actually needs, because it converts directly into money and calendar time. Worth stealing too: Location of Observed Activity, scored on a modified Purdue model from 0 (unsuccessful) through 3 (business network management — admin workstations, Active Directory, trust stores) to 6 (critical systems) and 7 (safety systems). That gives you a defensible, non-arbitrary reason why "adversary on a domain controller" outranks "adversary on a laptop" without winning an argument first. CISA is candid that NCISS inputs are "a mixture of discrete and analytical assessments" and that scorers will differ — which is itself the case for multi-factor rubrics over a single gut call.
Actionable takeaway: Write the four-level table into your plan with response obligations attached, and rehearse the round-up rule until nobody argues severity on a live bridge. That argument belongs in the post-incident review.
The roles below derive from the Incident Command System, which Google adopted for the reason emergency services did — "known for its clarity and scalability" (Google SRE Book). Use these names, in these words, in every playbook. Appendix D carries the full RACI.
| Role | Owns | Explicitly does not |
|---|---|---|
| Incident Commander (IC) | Decisions, delegation, tempo, severity, the running objective, the single living incident document | Any technical work whatsoever |
| Operations Lead | Directing technical workstreams; the only person who assigns hands-on tasks | Talking to executives, media or regulators |
| Communications Lead | Internal and external messaging, executive update cadence, holding statements | Making response decisions |
| Scribe | Contemporaneous timeline: what happened, when, and what decisions were made and by whom | Analysis — the Scribe records, never investigates |
| Legal Liaison | Privilege posture, legal hold, regulator and law-enforcement engagement, contract and insurer obligations | Technical direction |
| Executive Sponsor | Business decisions above the IC's authority: stopping a service, spending money, notifying the market | Running the incident |
Three independent sources converge. PagerDuty, to the IC: "You should not be performing any actions or remediations, checking graphs, or investigating logs" — the IC is "the highest-ranking person on any major incident call, regardless of their peacetime position," and deep technical knowledge is explicitly not required (PagerDuty). CISA, on the incident manager: "the IM does not perform any technical duties. During a time of crisis, time dilation affects people's perception of time passing. The IM will monitor the clock to avoid that common problem" (CISA IRP Basics). Google, structurally: a role holder past capacity requests more people rather than freelancing.
The mechanism is not about status. The person with hands on the keyboard has tunnel vision by design — that focus is what makes them good. An IC who is also debugging stops tracking the clock, stops noticing who is blocked, and stops noticing that Legal has not been called. In most organizations the best engineer gets handed the IC role as a reward, which loses you both the engineer and the command in one move. Every. Single. Time.
Name a Deputy IC at declaration, not when the IC is exhausted — a hot-swap standby who tracks severity and can assume command instantly. NCSC states that decision-makers "must hold actual authority to approve major actions like taking systems offline" and that deputies must be named for when primaries are unreachable (NCSC).
The Scribe is not a note-taker. The Scribe produces the artefact three audiences need: responders (what have we already tried?), regulators (when did you become aware?), and reviewers (why did we choose that?). Regulatory clocks almost all run from a subjective state — "aware," "reasonably believes," "determines" — and the contemporaneous log is the only evidence of when that state arose.
Handover is the highest-risk moment in a long incident, and both the emergency-management and SRE traditions script it. FEMA: transfer of command "should include a briefing that captures all essential information for continuing safe and effective operations." Google requires explicit verbal confirmation of the transition, "particularly across time zones." PagerDuty gives the words — the outgoing IC announces "Everyone on the call, be advised, at this time I am handing over command to [X]," and the incoming IC then announces themselves as if joining fresh, forcing a re-baseline instead of assumed shared context.
Use this template: written, read aloud, appended to the incident document.
INCIDENT HANDOVER — [INCIDENT ID] — [UTC TIMESTAMP]
Outgoing IC: [name] Incoming IC: [name]
Outgoing Ops Lead: [name] Incoming Ops Lead: [name]
Current severity: SEV-[n] Changed at [UTC] because [reason]
1. ONE-LINE STATUS — what is true right now, in one sentence
2. CURRENT OBJECTIVE — the single thing this shift must achieve, and by when
3. CONFIRMED FACTS — verified only; mark each observed / assessed
4. OPEN UNKNOWNS — which of the 11 analysis questions are unanswered
5. WORK IN FLIGHT — task | owner | started | expected | blocked by
6. DECISIONS MADE — decision | who decided | rationale | time
7. DECISIONS PENDING — decision | who decides | deadline | default if missed
8. EXTERNAL COMMITMENTS — who we told what, what we promised next, with times
9. CLOCKS RUNNING — clock | started | due | owner
10. EVIDENCE STATUS — preserved what, where, who holds custody, still volatile
11. WHAT I WOULD DO NEXT — outgoing IC's honest recommendation; not binding
Verbal confirmation of transfer given: [ ] Yes, at [UTC]Line 11 does more work than it looks like: it surfaces the outgoing IC's mental model — the part that never fits the status fields — while they are still in the room to be questioned about it.
Actionable takeaway: Name your ICs and Deputies now, publish the rotation, and run one exercise in which the IC may not touch a keyboard. The discomfort in that room is the finding.
Containment is a high priority with a narrow objective: prevent further damage and reduce immediate impact by removing the adversary's access. Strategy is scenario-dependent — CISA's own example is that containing "an active sophisticated adversary using fileless malware" looks nothing like containing ransomware.
Weigh three things before acting. CISA forces these considerations before any containment course of action, and putting them ahead of the action list is deliberate design:
Consideration 2 contains the phrase teams skip: unknown level of containment. "We isolated the host" and "we know the adversary can no longer act" are different claims, and only one is a terminating condition.
The standing tension never goes away. CISA: "Containment is challenging because defenders must be as complete as possible in identifying adversary activity, while considering the risk of allowing the adversary to persist until the full scope of the compromise can be determined." NIST 800-61r3 encodes the same trade-off as a decision, balancing "the need to quickly recover from an incident with the need to observe the attacker or conduct a more thorough investigation" (RS.MA-03). There is no formula. There is a decision, made by a named person, on the record.
| # | Action | Who | Done when | Evidence to capture |
|---|---|---|---|---|
| 1 | Confirm containment strategy against the three considerations; record the decision | IC | Decision and rationale recorded | Decision entry with time and authority |
| 2 | Move all response communication out of band | IC | Bridge confirmed independent of the affected identity plane | Roster of who joined, by what path |
| 3 | Export logs nearing retention expiry; place legal hold | Legal Liaison + Ops Lead | Export complete and hashed; hold confirmed | Export manifest, hashes, hold confirmation, operator, UTC |
| 4 | Capture volatile evidence on in-scope hosts before any state change | Ops Lead | Images acquired and hashed | Memory image, hash, collector version, operator, UTC |
| 5 | Coordinate with law enforcement on preservation, if applicable | Legal Liaison | Confirmed or explicitly declined | Record of contact and instruction |
| 6 | Isolate affected systems and segments — perimeter, internal, host — weighing mission continuity | Ops Lead | Isolation verified from both sides | Timestamps, method, verification output |
| 7 | Block and log egress to attacker infrastructure; block DNS resolution of attacker domains | Ops Lead | Blocks live and logging | Rule IDs, timestamps, hit counts |
| 8 | Revoke sessions and tokens, rotate credentials, keys and service secrets, revoke privileged access — one atomic burst | Ops Lead | All identity actions complete in the same window | Before/after evidence per principal, UTC |
| 9 | Remove attacker-created persistence found so far (rules, forwarding, devices, app registrations, keys) | Ops Lead | Enumerated and removed | Inventory of what was found and removed |
| 10 | Monitor for adversary reaction to containment | Ops Lead | Continuous through the phase | New indicators, times, sources |
| 11 | Re-check scope; any new sign of compromise returns to analysis | IC | No new signs of compromise | Updated, timestamped scope statement |
Step 8 is one row deliberately. Identity containment fails when done in pieces, because the pieces are independent credentials. Microsoft states that password resets and MFA "aren't effective" against illicit OAuth consent grants "because these apps are external to the organization" (Microsoft); that Entra ID "can't directly revoke a session token issued by an application"; and that access tokens can survive up to 28 hours in CAE sessions (Microsoft CAE). AWS is explicit that revoking sessions is not removing permissions — "you must also change permissions for the IAM user or role" (AWS). Chapter 14's identity playbooks carry the exact commands. The principle: reset-then-revoke leaves a live token in the adversary's hands and a locked-out user calling the help desk, which is the loudest possible way to achieve nothing.
Containment's terminating condition, per CISA, is a fact about the world rather than a milestone you can schedule: no new signs of compromise. Then preserve evidence, adjust detection tools, and move to eradication.
Actionable takeaway: Put the three considerations at the top of every containment section in every playbook, and require the IC to record which one drove the decision. When the review asks why you isolated 400 endpoints on a Friday, that line is your answer.
Evidence discipline is cheap during the incident and impossible afterwards.
Order of volatility. RFC 3227 gives the canonical ordering and has not needed updating (RFC 3227):
registers, cache routing table, arp cache, process table, kernel statistics, memory temporary file systems disk remote logging and monitoring data that is relevant to the system in question physical configuration, network topology archival media
The 2026 amendment is not to the ordering but to its weighting: in cloud and SaaS the "remote logging" tier is frequently your most important evidence and your shortest-lived. Entra ID audit and sign-in logs retain 7 days on Free, 30 on P1/P2. CloudTrail Event history is 90 days. Google Workspace admin, login, OAuth and Drive logs are 6 months; email log search is 30 days. A 7-day window expires while you are still scoping. So export before you contain, as a standing first action rather than a decision.
Before wiping a host, the practical minimum: physical memory image; process and network state; the EDR investigation package; Windows event logs including PowerShell script-block and module logging plus Sysmon if present; Prefetch, Amcache, SRUM, ShimCache, registry hives, $MFT and $UsnJrnl; scheduled tasks, services and autoruns; browser artefacts; and a disk image or cloud snapshot where the host is materially in scope. Full bit-for-bit imaging is no longer practical at typical disk sizes — triage acquisition is the default, full imaging reserved for the few hosts that justify it.
Working copies. Analyze copies, never originals. In cloud the pattern is snapshot → copy into a dedicated forensics account → grant the investigative role read-only access (AWS). Where evidence is encrypted and crosses an account boundary, share the key too — a snapshot you cannot decrypt is a very expensive nothing.
Legal hold goes on before containment, because holds are not retroactive and retention windows are short. In AWS, S3 Object Lock legal hold "provides the same protection as a retention period, but it has no expiration date… remains in place until you explicitly remove it," applies per object version and requires versioning (AWS). In Microsoft 365 the instrument is the eDiscovery hold, preserving against both retention expiry and deletion by the custodian.
Chain of custody. RFC 3227's four questions are the entire requirement: where, when and by whom evidence was discovered and collected; where, when and by whom it was handled or examined; who had custody, for what period, stored how; and when custody changed, how the transfer occurred. A form that answers all four:
CHAIN OF CUSTODY RECORD
A. IDENTIFICATION
Evidence ID (unique, sequential) · Incident ID · Description of item
Type: disk image / memory / log export / device / cloud snapshot
Source: hostname, asset ID, IP or cloud resource ARN/URI · System owner
B. ACQUISITION
Acquired by (name, role) · Date/time (UTC, ISO 8601) · Location
Method and tool, with version · Command or console action, verbatim
Hash of artefact (algorithm + value) · Hash verified by (second person), UTC
Reason for acquisition (which analysis question it serves)
C. STORAGE
Location (physical or logical, incl. account/bucket/vault) · Access controls
Encryption at rest (key reference) · Legal hold (yes/no, reference, date)
Retention period · Disposal authority
D. CUSTODY LOG — one row per transfer, no gaps
# | Released by | Received by | Purpose | Date/time (UTC) | Transfer method
| + tracking reference | Integrity re-verified on receipt (hash match, by whom)
E. EXAMINATION LOG — one row per examination
# | Examiner | Date/time (UTC) | Working copy ID used (never the original)
| Tools + versions | Findings reference
F. DISPOSITION
Returned / retained / destroyed · Date · Authority · WitnessTwo disciplines make it real rather than ceremonial. Every timestamp is UTC in ISO 8601 — mixed local times are how timelines become unusable, and international guidance calls for UTC with millisecond granularity as the ideal (Best Practices for Event Logging and Threat Detection). And no gaps in section D — an unexplained custody gap is the easiest thing for opposing counsel to find.
Retention. That same international guidance is blunt: "Default log retention periods are often insufficient… in some cases, it can take up to 18 months to discover a cyber security incident and some malware can dwell on the network from 70 to 200 days before causing overt harm." Note what it does not do: set a numeric minimum. Anyone telling you "CISA says 12 months" is quoting OMB M-21-31, which binds federal agencies.
Actionable takeaway: Make "export logs approaching retention expiry" and "place legal hold" the first two actions of every playbook's containment section, ahead of any isolation step. Evidence you did not export before the window closed does not exist, however badly you need it in month four.
The gate you do not skip. CISA's precondition for entering eradication has three parts, and teams routinely satisfy two and proceed:
"Before moving to eradication, ensure that (1) all means of persistent access into the network have been accounted for, (2) the adversary activity is sufficiently contained, and (3) all evidence has been collected. This is often an iterative process."
Plus a coordination requirement missed at 4am: coordinate with ICT service providers, commercial vendors and law enforcement before initiating eradication. Your MSP rebuilding a server you are mid-way through imaging is a self-inflicted wound.
Root cause, not symptom. Eradication removes artefacts and mitigates the conditions that were exploited. If a specific vulnerability was exploited, the vulnerability response process runs concurrently (Chapter 10). If valid credentials were used, eradication is credential and trust-material rotation, not malware removal. If you cannot answer analysis question 1, you are not eradicating; you are tidying.
| Situation | Action | Why |
|---|---|---|
| Commodity malware, EDR-quarantined, no interactive access | Clean and verify | Rebuild cost not justified by risk |
| Interactive adversary access to the host | Rebuild from a known-good gold image | You cannot enumerate what you did not observe |
| Any evidence of rootkit or firmware implant | Rebuild the hardware | Reimaging does not reach it |
| Tier 0 / identity-plane asset in scope | Rebuild plus trust-material rotation | Everything downstream authenticates against it |
| Ephemeral cloud workload (container, serverless) | Replace from a rebuilt image; capture evidence first if it still exists | A memory image is meaningless for a pod that lived 40 seconds |
The identity-plane case has published, specific mechanics. On-premises AD passwords are reset twice to defeat pass-the-hash under replication delay, and krbtgt is reset twice because the account keeps a two-password history — with at least 10 hours between resets so the first fully replicates (CISA CM0050). Microsoft's forest recovery guidance adds that where intrusion is suspected, all administrative account passwords — Enterprise Admins, Domain Admins, Schema Admins, Server and Account Operators — are reset before additional domain controllers are installed, and gMSA passwords replaced (Microsoft). Order matters: a rebuilt DC that rejoins before those resets is a clean machine trusting dirty keys.
After eradication, keep hunting. Continue detection and analysis to watch for re-entry or new access methods. If adversary activity appears, contain it and return to technical analysis until the true scope and initial infection vectors are identified. Only when no new activity is detected do you enter recovery. Mature teams should consider emulating the observed TTPs to verify countermeasures work — coordinated with the blue team in advance so nobody mistakes the test for the real thing.
Recovery is dependency-ordered, not preference-ordered:
Clean network and out-of-band comms → identity (AD/Entra) → DNS, DHCP, PKI, NTP → certificate and secrets infrastructure → core file and database services → applications → user data → endpoints.
The reason is unforgiving: services restored before identity come up authenticating against something not yet trustworthy. Microsoft's forest recovery procedure is itself a clean-room procedure — restore in isolation with the network cable detached, validate, then connect. Chapter 12 owns backup immutability, isolated recovery environments and restore testing; this chapter's contribution is that identity goes first and nothing rejoins production before validation.
Before production return, per CISA: test systems thoroughly including a security controls assessment; tighten perimeter security and zero trust access rules; maintain enhanced vigilance and controls to validate that recovery executed and no adversary activity remains; and consider an independent test or review of the compromise and response. Independent means someone who was not in the war room.
Actionable takeaway: Write the recovery dependency order down service by service before the incident, with a validation gate between tiers. During recovery every business unit will insist theirs is the exception. A documented order signed by the Executive Sponsor is the only thing that survives that conversation.
The goal, per CISA: document the incident, inform leadership, harden the environment against a repeat, and apply lessons to future handling. Three things must actually happen.
Adjust the sensors. Add enterprise-wide detections for the adversary TTPs that succeeded. Address the blind spots the incident exposed. Keep monitoring for persistent presence. This is the fastest-decaying opportunity in the lifecycle: detection engineering done in the two weeks after an incident is informed by ground truth you will never have again.
Run a blameless hotwash. CISA's instruction is one line and non-negotiable: "Retrospectives must be blameless. For retrospectives to have any value, all participants need to feel free to openly discuss the incident in a safe and supportive environment. Security incidents are rarely the result of one person's action. They are almost always the result of a failure of the overall system" (CISA IRP Basics).
That is not sentiment, it is a research finding. Amy Edmondson's field study of 51 work teams introduced team psychological safety — "a shared belief held by members of a team that the team is safe for interpersonal risk taking" — and found it associated with learning behavior, which in turn mediates between psychological safety and team performance (Edmondson, Administrative Science Quarterly 44(2), 1999). John Allspaw translated it for engineering: a just culture means "investigating mistakes in a way that focuses on the situational aspects of a failure's mechanism and the decision-making process of individuals proximate to the failure," so the organization "can come out safer than it would normally be if it had simply punished the actors involved" (Etsy). The safety-science root is Sidney Dekker's argument that accountability should be forward-looking and systemic rather than backward-looking and punitive.
Current practice formalises the review into eight stages — Assign → Identify → Analyze → Interview → Calibrate → Meet → Report → Distribute — with two moves worth adopting now (Howie: The Post-Incident Guide). First, "Performance Improvement = Error Reduction + Insight Generation": do not only reduce errors, generate insight. Second, the shift from "blameless" to "blame-aware" — everyone works within constraints, and some only become visible after an incident. Calibrate is the stage most teams have never heard of and the one that changes the room most: circulate draft findings before the meeting so nobody is surprised in front of their peers. Ambush ends honest reporting for a year.
CISA's hotwash objectives make a serviceable agenda: confirm the root cause is eliminated or mitigated; identify infrastructure problems; identify policy and procedural problems; review and update roles, responsibilities, interfaces and authority to ensure clarity; identify training needs; improve the tools used to protect, detect, analyze or respond. Objective four is on that list because unclear authority is a recurring real-world finding.
Make the findings survive. Here is where most programs quietly fail: the hotwash produces findings with no owner, no due date and no verification. A finding without those is a feeling.
| Attribute | Requirement |
|---|---|
| Owner | A named individual, not a team |
| Due date | A calendar date, agreed in the room |
| Acceptance test | How we will know it is done, written now |
| Verification | Who checks and when — not the owner |
| Playbook impact | Which playbook changes, and who edits it |
That last row is why this book exists. Every incident is a free test of your playbooks. If the playbook was wrong, ambiguous or silent, the fix is a change to the playbook — not a paragraph in a report nobody opens. Chapter 2 covers playbooks-as-code and the update triggers; an incident is the most important of them. And do not wait for the review to start improving: 800-61r3 is explicit that lessons "should often be shared as soon as they are identified, not delayed until after recovery concludes."
Actionable takeaway: Book the hotwash when you declare, at T+0 for T+10 business days, and track every finding to a verified state in the same system as your vulnerability findings — so it reaches the same executive, on the same report.
Coordination runs across every phase, which is why it is a band and not a box. CISA calls it "foundational."
Internal. One common operating picture, one Communications Lead, one cadence. The British Library's applied rule is worth copying: staff always saw updated external communications before the public, so they could digest developments ahead of user queries.
External. Provide accurate information about impact and avoid hyperbole. NCSC's sharpest rule: "Avoid saying anything that may have to be retracted later. For example… stating that there is no known impact on staff or personal data can be problematic later down the line if this understanding changes" (NCSC). The loop-back rule applies to statements exactly as it applies to scope. Chapter 15 owns message content.
Law enforcement. In the US federal model the FBI and NCIJTF lead threat response — investigation, forensics, interdiction, attribution — CISA leads asset response, and ODNI's CTIIC leads intelligence support. For a private organization: engage early, engage through counsel, and coordinate on evidence preservation before eradication, since eradication destroys what they need. There is a self-interested reason too — OFAC's ransomware advisory lists prompt, complete reporting to law enforcement and CISA, plus full cooperation, among the mitigating factors in an enforcement action (OFAC).
Counsel and privilege. A first-hour decision, and the case law is unkind to retrofits. Three decisions narrowed privilege over forensic reports: In re Capital One (E.D. Va. 2020), where work-product protection failed and the report was produced; Guo Wengui v. Clark Hill (D.D.C. 2021), where the "principal objective in securing the report was utilizing the external security consulting firm's expertise in cybersecurity, not in obtaining legal advice"; and In re Rutter's (M.D. Pa. 2021), where the report "only discussed facts and did not involve 'opinions and tactics'."
The practitioner consensus on structuring for privilege (Morrison Foerster): outside counsel retains the forensics firm, under a separate engagement for each incident, scoped explicitly to legal advice or anticipated litigation — telling an existing vendor to "report to counsel" is not sufficient; be deliberate about report contents, keeping any business or remediation report genuinely distinct rather than a derivative summary; watch agency disclosure, since sharing privileged material with regulators can waive broadly; account for jurisdictions that do not extend privilege to in-house counsel; structure on day one; and discipline the team's writing.
On that last point: internal messages are discoverable and increasingly are the primary evidence — the SEC's action against SolarWinds and its CISO relied on internal presentations, emails and instant messages (SEC). Make it a house rule, stated aloud when the bridge opens: facts and timestamps in the incident channel; opinions, blame, speculation and legal characterizations nowhere. Mark every statement observed or assessed. No guessing at attribution. No record counts before they are verified. No "we should have." That is not an instruction to hide anything — NCSC's counterweight is essential: record decision-making offline or on unaffected systems, because you still need a contemporaneous record for regulators and for the review.
Actionable takeaway: Decide the privilege posture before the incident, in writing, with counsel: who retains the forensics firm, under what agreement, and which channel carries legal-strategy discussion. Structure on day one is cheap. Structure retroactively is not available.
Every one of these is drawn from a published post-incident finding. The organizations involved published so the rest of us could learn; treat them accordingly.
1. Premature containment — whack-a-mole. The clearest articulation is Mandiant's: "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). The failure chain: responders remove the systems they know about → "the responders 'tip their hand' to the attacker" → the attacker, using backdoors on systems nobody found, abandons the burned malware and C2 and secures continued access → "the responders will continue to be blind, and unaware," typically until an outside party notifies the organization again. The alternative is a posturing phase — during which administrators explicitly do not change compromised passwords, block C2 or rebuild — used instead to appoint a remediation lead, secure executive support, build a plan with deadlines and enhance logging, typically four to eight weeks, followed by a remediation event of 24–48 hours. Aldridge is honest that whack-a-mole is sometimes correct, such as cash being stolen in near real time. It should be a choice, not a reflex.
2. No out-of-band comms on a compromised network. Attackers "may monitor your organization's activity or communications to understand if their actions have been detected" (CISA).
3. Backups and identity infrastructure destroyed with the estate. CISA: maintain offline, encrypted backups, because "most ransomware actors attempt to find and subsequently destroy them." The British Library's tenth lesson is the framing for a budget conversation: "Prioritize recovery alongside security: Given that no security is perfect, the ability to quickly recover is essential when (not if) an attack is successful." Its eighth: "'Legacy' systems are not just hard to maintain and secure, they are extremely hard to restore." The operational rule: your IR tooling, ticketing, contact list, credential vault and backup catalog must not depend on the identity plane you are about to declare compromised. If your backup console uses SSO and the domain is encrypted, you cannot log in to restore the domain.
4. Stale distribution lists and missing inventory. GAO's review of Equifax is unusually clear: the Apache Struts vulnerability "was not properly identified as being present on the online dispute portal when patches for the vulnerability were being installed throughout the company… 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." Separately, an expired digital certificate meant traffic "was not being inspected throughout the breach," and unsegmented databases let attackers reach data beyond the entry point (GAO-18-559). Two consequences: your notification distribution list is a controlled asset that must be tested — which is what a call-tree cascade test is for — and triage requires a pre-defined critical asset list so restoration is prioritized against health, safety, revenue and operations rather than volume.
5. Unclear authority and invisibly accepted risk. The British Library's seventh lesson: "Regardless of risk appetite, all IT security risks accepted at an operational level should be flagged to the appropriate levels of senior management… The Library's risk management processes appropriately escalated out-of-appetite security risks for remediation, but were less effective in modeling the amount of low-level risks being carried in aggregate." That is the failure mode where nobody did anything wrong and the sum was still fatal.
6. Policy that exists but is not enforced at the seams. Three published cases, one shape. Change Healthcare: attackers used compromised credentials against a Citrix remote-access portal without MFA enabled, despite policy requiring MFA on all external-facing systems (testimony coverage). Colonial Pipeline: a "legacy virtual private network profile that was not intended to be in use," without MFA. The British Library's third lesson: MFA "needs to be in place on all internet-facing endpoints, regardless of any technical difficulties in doing so. The Library had MFA in place for all end-user technologies, but not on certain supplier endpoints." The policy is always universal; the enforcement is not, and the gap is always at a seam — a legacy system, a supplier, an appliance nobody owns. A playbook cannot fix that, but a preparation checklist can require periodic enumeration of exceptions, each with an owner and an expiry date.
7. Under-investigating small intrusions. Repeated because it is the cheapest lesson here: commission an in-depth review after even the smallest signs of intrusion, because "it is relatively easy for an attacker to establish persistence after gaining access to a network, and thereafter evade routine security precautions."
8. Systemic failure, not individual failure. The Cyber Safety Review Board's review of the Summer 2023 Microsoft Exchange Online intrusion concluded it "should never have happened" and was the product of "a cascade of security failures" — including that manual rotation of consumer signing keys had stopped in 2021 following a major cloud outage linked to the rotation process (CSRB). A safety control abandoned because it once caused an outage is the most human failure on this list, and the one your environment is most likely running right now.
Actionable takeaway: Take these eight to your next tabletop as the scenario injects. You do not need a novel adversary to find gaps. You need the failure modes that have already happened to organizations better resourced than yours.
The CISO MindMap's fourth focus area for 2026-27 is three words: "Take good care of your teams." Responder capacity is infrastructure.
Fatigue does not degrade everything equally, and what it degrades is the dangerous part. Harrison and Horne's review found simple, well-practiced, rule-based tasks relatively robust to short-term sleep deprivation because people mobilize compensatory effort — but sleep deprivation still impairs decision-making involving "the unexpected, innovation, revising plans, competing distraction, and effective communication" (Harrison & Horne, Journal of Experimental Psychology: Applied 6(3), 2000).
Read that against the job. A tired responder can still run a checklist. They are markedly worse at noticing the situation has changed, revising the plan, filtering distraction and communicating clearly — a precise list of what a novel incident demands. This is the empirical case for playbooks: they convert novel judgement into rule-following, which is the cognitive mode that survives fatigue. Four design rules follow. No novel decisions at hour 14 — if a decision requires invention, it waits for a rested person. Rotate the IC on a schedule, not on exhaustion, because by the time someone feels too tired to command they cannot reliably assess that. Script the handover. Pre-write the decisions that require innovation — which is what the decision callouts in Chapter 14 are for.
Welfare is an operational control. NCSC's guidance gives five recommendations: include all staff in the IR plan with practical stress-reducers such as deputy arrangements and out-of-hours cover; build a culture where staff feel safe to say they are overwhelmed and safe to raise concerns about colleagues; plan internal communications; be conscious of concerns about personal impact and job security; and practice the response. Its rationale is that increased workload, pressure and stress lead to "mistakes being made and (if staff welfare goes unchecked) can lead to employee 'burn out'," and that "some personnel are likely to 'thrive' during an incident, others won't" (NCSC).
Plan for the long tail. NCSC notes incidents "often start with an intense period of activity, but many also have a 'long tail' with the impact lasting for months." The initial shockwave gets adrenaline and catering. The aftershocks — leaked data appearing, regulator questions, litigation, the fourth all-staff update — arrive when everyone is depleted and the war room has been stood down. Staff the tail deliberately.
The British Library made this a published lesson: "Proactively manage staff and user wellbeing: Cyber-incident management plans should include provisions for managing staff and user wellbeing. Cyber-attacks are deeply upsetting for staff whose data is compromised and whose work is disrupted." It also recorded that its technology department "was overstretched before the incident and had some staff shortages" — the pre-incident staffing deficit became the post-incident recovery constraint. That is the sentence to read out in the budget meeting.
Alert fatigue is a failure mode with a paper trail. The best peer-reviewed synthesis reviews SOC alert fatigue through an automation/augmentation/collaboration lens and cites industry studies reporting false-positive rates as high as 99% (Tariq et al., ACM Computing Surveys 57(9), 2025). The mechanism is desensitization; the outcome is worse detection and worse retention. The response is not "tune the SIEM" — it is to define, per playbook, which alert combination justifies opening it, and to log every false activation as a defect against the detection. Chapter 9 owns the detection side.
And the rule that keeps the human sensor network alive, from CISA: "Be gracious when people report false alarms. Reward people who come forward to report suspicious events." A false report costs minutes. A culture where people stop reporting costs you the 26-day dwell time.
Actionable takeaway: Add three things to your plan this quarter: a mandatory IC rotation interval, a named welfare owner outside the response chain, and a rule that anyone may call for a rest break without justifying it. Then honour them during the exercise — a team that watches you ignore the rotation rule in a tabletop will assume it is decorative in a real one.
Incident response is not heroism. Heroism is what you get when preparation is missing, and it does not scale past about forty hours. What scales is a named commander who is not typing, a scribe who is, an out-of-band bridge, a severity scale nobody argues about, evidence exported before it expires, and the discipline to go back and re-scope when a new indicator says you were wrong.
Stay scoped, stay out of band, and remember: the incident is never smaller than the first hour suggests.
[IG1] [CIS 17] [A.5.24] [GV.RR][IG1] [A.5.25] [RS.MA][IG1] [A.5.25] [DE.AE][IG2] [A.5.25][IG1] [CIS 17] [RS.MA-03][IG2] [RS.MA-03][IG1] [CIS 17] [A.5.24] [GV.RR][IG2] [RS.AN] [A.5.28][IG2] [A.5.24][IG1] [RS.MI] [A.5.26][IG2] [RS.MI][IG1] [A.5.29] [RC.CO][IG1] [A.5.24] [RS.CO][IG2] [CIS 13] [PR.IR][IG1] [CIS 8] [A.8.15] [DE.AE][IG2] [A.5.28] [RS.AN][IG2] [A.5.28] [RS.AN][IG2] [A.5.28][IG2] [RS.MI] [A.5.26][IG1] [RS.AN] [A.5.26][IG2] [RS.MI] [A.5.26][IG2] [CIS 11] [RC.RP] [A.5.30][IG1] [CIS 17] [A.5.27] [ID.IM][IG2] [A.5.27] [ID.IM][IG2] [A.5.24] [RS.CO][IG1] [A.5.24] [GV.RR]