Appendix D: Incident-Response Playbooks

You cannot improvise a chain of command, a containment strategy, and a notification process at 3 a.m. while your servers encrypt (Chapter 24). You can only execute the plan you already have. This appendix is a starter set of step-by-step playbooks for the incidents a defender is most likely to face, each structured around the NIST SP 800-61 incident-response lifecycle: Prepare → Detect & Analyze → Contain → Eradicate → Recover → Lessons Learned. They are the kind of artifacts Meridian Regional Bank builds in its Chapter 24 Project Checkpoint, made concrete here so you have a model to start from.

⚠️ These are templates, not turnkey procedures. Every organization's tooling, authority structure, regulatory obligations, and risk tolerance differ. A playbook is only useful once it is adapted to your environment — your EDR console, your account-disable runbook, your legal contacts, your statutory notification clocks — and tested in a tabletop (Chapter 24, §24.5) before an attacker tests it for you. Treat what follows as a constructed (Tier 3) scaffold to localize, fill in with your own runbook references, and rehearse. The notification triggers below are illustrative; confirm your actual legal and regulatory obligations with counsel — they vary by jurisdiction, sector, and the data involved.

How to read every playbook. Each one is organized identically so they are usable under stress:

• Trigger / indicators — what makes you suspect this incident.
• First 60 minutes — the immediate triage and declaration steps (Chapter 24, §24.3).
• Containment — the options and the tradeoffs (Chapter 24, §24.4).
• Eradication & recovery — removing the attacker and restoring safely.
• Evidence to preserve — for forensics (Chapter 25) and possible legal/regulatory use.
• Communications & notification triggers — who to tell and when the clock starts.
• Post-incident actions — the blameless-postmortem follow-ups (Chapter 24, §24.6).

Universal pre-conditions that every playbook assumes you prepared (Chapter 24, §24.2): a named incident commander (IC) with authority to decide; an out-of-band communications channel (because the attacker may be in your email); an offline copy of the plan and contacts; a severity matrix (SEV-1–SEV-4); and runbooks for the recurring technical actions (isolate a host, disable an account and revoke its sessions, block a domain). Where a playbook says "isolate the host," that is the decision; your runbook says exactly which buttons to click.

D.1 Ransomware

The destructive, fast-moving incident where every minute of spread is irreversible. Speed dominates (Chapter 24's worked containment example).

Trigger / indicators. Files renamed with an unfamiliar extension; a ransom note (.txt/.html) in many directories; EDR alerts on mass file modification or on shadow-copy deletion (vssadmin delete shadows, an ATT&CK "Inhibit System Recovery" technique); backup-integrity jobs failing en masse; users reporting they cannot open files; a spike in file-write/rename operations across servers.

First 60 minutes. 1. Treat it as SEV-1 immediately. Active encryption attacking the recovery path is the textbook critical incident. Declare; the IC takes the chair before anyone touches a server. Start the scribe/timeline. 2. Open the out-of-band war room (Signal group / bridge). The attacker may be in your email and Teams — do not coordinate there. 3. Scope fast, contain in parallel — for ransomware you do not wait to finish scoping. Identify affected hosts and the account/credential being used to spread (often a privileged or service account — pull the privileged inventory from Chapter 19).

Containment (fast-destructive posture: isolate now, scope in parallel — speed > stealth). - Isolate affected hosts at the network layer but leave them powered on (preserves memory evidence — Chapter 25's order of volatility). Use EDR network isolation if available; pull the segment if not. - Disable the spreading account and force-revoke its sessions and Kerberos tickets domain-wide. - Block command-and-control domains/IPs at the DNS resolver, proxy, and firewall. - Protect the backups now. Verify your offline/immutable backups are intact and disconnected from the network — they are your recovery path and the attacker's target. Do not connect them to a possibly-infected environment. - In extremis (fast lateral spread), consider an emergency segmentation cut to halt propagation.

Eradication & recovery. - Wipe and reimage seriously compromised hosts from known-good media — do not "disinfect" (you cannot prove you found every implant). - Eliminate persistence (scheduled tasks, services, run keys, web shells, rogue accounts) and rotate all credentials the attacker could have reached; for domain-controller compromise, plan the krbtgt double-reset. - Close the initial access vector — patch the exploited flaw or fix the misconfiguration (often a weak/exposed remote-access account). - Restore from known-good, tested, offline backups, staged by business priority (critical functions first), validating integrity as you go. - Heightened monitoring on recovered systems and identities for a defined window before declaring closure. - Do not pay by default. The ransom decision is strategic, legal, ethical, and possibly a sanctions matter — governed by a pre-written ransom policy and escalated only to named executives with counsel and the insurer, never decided by responders in the heat of the moment (Chapter 24).

Evidence to preserve. Memory of affected hosts (capture before reimaging); the ransom note and any attacker contact details; the malware sample (handled safely); relevant logs (EDR, authentication, firewall/proxy, DNS); the timeline; identity of the initial-access vector. Hash everything (chain of custody, Chapter 25).

Communications & notification triggers. - Internal: leadership on a fixed cadence; workforce told clearly ("do not power off your machines; report anything unusual to this number; do not discuss externally"). - Legal and cyber-insurer: often the first external calls — many policies require prompt notice and supply a breach coach/IR firm; late notice can void coverage. - Regulators / law enforcement: if a notification clock applies to your sector (for a U.S. bank, the 36-hour federal banking-incident determination clock; for others, GDPR's 72-hour and various sectoral/state rules), the clock may start before you fully understand the incident — get legal/GRC to the table early. Engage the FBI/CISA for serious ransomware. Confirm your specific obligations with counsel. - Customers / public: coordinated with legal and communications; required if personal data was (or is presumed) exfiltrated under "double extortion."

Post-incident actions. Blameless postmortem within 1–2 weeks: timeline, what went well, what got lucky, root cause (push past the trigger — why could one credential do this much?), and a short list of owned, deadlined, tracked action items (e.g., remove standing privilege from the service account; write the missing krbtgt runbook; enforce immutable backups). Capture MTTD/MTTR. Feed it all back into Preparation.

D.2 Phishing and Business Email Compromise (BEC)

The human-targeted incident (Theme 3). Ranges from a single reported phish to a full BEC fraud where an attacker impersonates an executive or vendor to redirect payments.

Trigger / indicators. An employee reports a suspicious email (your strongest sensor); a click/credential-entry on a phishing page detected by the proxy or identity logs; an unexpected mailbox rule that auto-forwards or deletes mail; an "executive" urgently requesting a wire transfer or gift cards; a vendor "changing their bank details"; impossible-travel or new-region sign-ins to a mailbox; anomalous OAuth-app consent grants.

First 60 minutes. 1. Triage the report. Is it a single phish (likely SEV-3/4) or evidence of compromise/active fraud (SEV-2, or SEV-1 if funds or many users are involved)? Corroborate across sources — did anyone click? did a credential get entered? did a sign-in succeed? 2. For suspected BEC fraud with money in motion, escalate immediately and involve Finance — there may be a recall window on a wire transfer that closes in hours. 3. Identify the blast radius — who received the phish (search the mail environment), who clicked, whose credentials/sessions are at risk.

Containment. - Remove the malicious message from all mailboxes (mail-search-and-purge); block the sender, URL, and any payload at the secure email gateway, proxy, and DNS. - If credentials were entered or a mailbox is compromised: reset the user's password, revoke active sessions/tokens, and re-establish MFA (treat as account compromise — see D.3). - Hunt and remove malicious mailbox rules (auto-forward/auto-delete are classic BEC persistence) and review/revoke suspicious OAuth app grants. - For wire fraud: contact the bank to attempt recall/freeze; notify the receiving institution; preserve the fraudulent instructions.

Eradication & recovery. - Confirm no residual access (rules, app grants, forwarding, alternate MFA methods the attacker added). - Reset affected credentials, restore legitimate mailbox configuration, and verify the user's account is clean. - If the phish delivered malware, pivot to the endpoint (treat as malware: isolate, reimage if needed). - Reinforce the targeted process — for BEC, out-of-band verification of payment/bank-detail changes is the durable fix.

Evidence to preserve. The original email with full headers; the phishing URL and any captured payload; mail-flow and authentication logs; the malicious mailbox rule and OAuth grant details; for fraud, the financial instructions and transaction records. Headers establish the sender infrastructure for blocking and reporting.

Communications & notification triggers. - Internal: warn other potential recipients ("this phish is circulating; do not click; report it"); brief leadership if executives are impersonated or funds are involved. - Finance/bank: immediately for any fraudulent-payment scenario (recall window). - Law enforcement: report BEC fraud (in the U.S., the FBI's IC3) — recovery of funds sometimes depends on speed. - Notification obligations: if mailbox compromise exposed personal/regulated data (a mailbox often contains plenty), a breach-notification obligation may be triggered — assess with counsel.

Post-incident actions. Postmortem focused on the systemic gaps, not the person who clicked (Chapter 24's threshold concept): were email defenses, MFA, least-privilege, and training adequate to make one click survivable? Action items often include tightening payment-change verification, restricting OAuth consent, and a targeted awareness campaign (Chapter 30's click_rate). Track click-and-report rates as a metric.

D.3 Account compromise / credential theft

A legitimate account is now in an attacker's hands — via phishing, password reuse, a breach-exposed credential, or token theft. Identity is the perimeter (Chapter 15), so this is among the most common and consequential incidents.

Trigger / indicators. Impossible-travel or new-region/new-device sign-ins; MFA fatigue (a flood of push prompts) or a sudden new MFA method registered; logins at unusual hours; access to resources the user never touches; a credential appearing in a breach-data feed (the HIBP-style check of Chapter 16); alerts on privilege escalation or new access grants tied to the account.

First 60 minutes. 1. Triage and set severity by the account's privilege and reach — a non-privileged user is SEV-3; a privileged/admin or service account is SEV-2/SEV-1 (a compromised privileged account is presumed to have reached everything it could reach until proven otherwise — Chapter 24's scoping discipline). 2. Confirm it is compromise, not just an anomaly — corroborate the sign-in, location, device, and subsequent actions across logs. 3. Begin identity-pivot scoping: where did the account authenticate, what did it access, what did it have rights to (access reviews from Chapter 18; privileged inventory from Chapter 19)?

Containment. - Disable the account (or force a password reset) and revoke all active sessions and tokens — a password reset alone does not kill a live session or a stolen token, so revoke explicitly. - Reset/re-enroll MFA and remove any attacker-added MFA methods or recovery options (a common persistence trick). - For a privileged or service account: also disable any derived access, rotate associated secrets/keys, and watch for lateral movement to other accounts and hosts. - Block the attacker's source IPs/infrastructure where it does not break legitimate users.

Eradication & recovery. - Remove all attacker persistence on the identity (added methods, app grants, forwarding rules, new keys, new sessions). - Rotate credentials for anything the account could access that may now be compromised (presume breach of reachable secrets). - Restore legitimate access for the user on a known-clean credential and verify MFA integrity. - If the account reached hosts/data, pivot to those systems (endpoint and data-exfiltration playbooks).

Evidence to preserve. Sign-in/authentication logs (source IP, device, geolocation, success/failure); the actions the account performed; details of attacker-added MFA/app grants; the timeline of access. These both scope the incident and support any required notification.

Communications & notification triggers. - Internal: notify the account owner and their manager; brief leadership for privileged-account compromise. - Downstream systems' owners: if the account had access to others' systems/data, those owners need to know. - Notification obligations: if the account accessed personal/regulated data, assess breach-notification duties with counsel (access to data, even without confirmed exfiltration, can trigger obligations in some regimes).

Post-incident actions. Postmortem on why the credential was compromised and why it could do what it did: were phishing-resistant MFA, conditional access, least privilege, and breached-password checks in place? Action items frequently include rolling out phishing-resistant MFA (Chapter 1/16), tightening conditional access, reducing standing privilege (Chapter 19), and adding detections for the technique that succeeded.

D.4 Data breach / exfiltration

Sensitive data has left, or is leaving, your control. This is the incident with the heaviest legal and notification dimension — the regulatory clock is often the most time-critical element.

Trigger / indicators. Large/anomalous outbound transfers (the summarize_flows/top_talkers view from Chapter 10); DLP alerts on sensitive data egressing; data appearing for sale or in a leak/extortion claim; a third party, researcher, or law-enforcement notification that your data is exposed; unusual database queries or bulk exports; access to a sensitive data store from an unexpected identity or location; a storage bucket that became public (the CloudTrail PutBucketAcl event of Chapter 15).

First 60 minutes. 1. Set severity by data sensitivity and volume — confirmed exposure of customer/regulated data is SEV-1. Declare; IC takes the chair; engage legal early because the determination clock may already be running. 2. Confirm and scope the data involved: what data, whose, how much, what classification, and is exfiltration confirmed or claimed? This determination drives every notification decision and is itself a deadline-bound judgment the IC must drive. 3. Identify the exfiltration path and the access used (compromised account? exposed store? insider? misconfiguration?).

Containment. - Stop the egress: block the destination/C2; close the exposed store (revert a public bucket to private, or rely on Block Public Access); disable the account or path being used; cut the connection where you can without destroying evidence. - Preserve the exposed system in place (isolate, do not wipe) so forensics can establish exactly what was accessed. - Apply least-privilege/segmentation around the affected data to prevent further reach while you investigate.

Eradication & recovery. - Close the root cause: fix the misconfiguration, remove the attacker's access and persistence, patch the exploited flaw, or address the insider's access (D.5). - Validate that no other path to the same data remains open. - Restore normal, hardened access controls and add monitoring on the affected data store. - Recovery here is as much legal/communications as technical — the "restore" is restoring trust through correct notification as much as restoring systems.

Evidence to preserve. Logs proving what was accessed and what left (egress/proxy/DLP, database query/audit logs, cloud access logs, file-access logs); the access path and identity used; the timeline; copies of any leaked/extortion material. The forensic determination of scope (Chapter 25) is the basis for legally defensible notification — under-claiming or over-claiming both cause harm.

Communications & notification triggers. This is the playbook where notification dominates. - Legal and insurer first — counsel may direct the investigation under privilege and owns the notification-determination process. - Regulators: deadlines vary widely — e.g., GDPR's 72 hours to the supervisory authority for qualifying personal-data breaches; sector rules (the 36-hour U.S. banking clock); U.S. state breach-notification laws with their own consumer-notice timelines ("without unreasonable delay," with hard outer limits). The clock often starts at determination, before full understanding. Your exact obligations depend on the data, the people affected, and the jurisdictions — confirm with counsel. - Affected individuals: notify per the applicable law, honestly and promptly — and remember the ethical floor exceeds the legal one (Chapter 24): people have a right to protect themselves (freeze credit, change passwords). - Law enforcement / CISA for serious or criminal breaches.

Post-incident actions. Postmortem covering both the technical root cause and the detection gap (a distressing share of breaches are found by outsiders — how long was the data exposed, and why did you not see it?). Action items typically include closing the exposure class with a guardrail (Chapter 15), improving egress/DLP detection (Chapter 10), and tightening access to sensitive stores (Chapters 17–18). Capture the time-to-detect explicitly.

D.5 Insider threat

The threat actor is (or was) trusted — a malicious insider stealing data or sabotaging systems, or a negligent one causing harm. This playbook is unusual: HR and Legal are first-class responders from the start, and discretion is paramount because you may be investigating a current employee.

Trigger / indicators. Access to data unrelated to the person's role; bulk downloads or copies to USB/personal cloud/personal email, especially around resignation or a performance issue; access at unusual times; attempts to bypass controls or escalate privilege; use of a departed employee's still-active account (an orphan_accounts finding, Chapter 18); sabotage indicators (deleted data, altered logs, planted logic bombs); tip-offs from colleagues.

First 60 minutes. 1. Engage HR and Legal before acting — insider cases have employment-law, privacy, and evidentiary implications that can be irreparably damaged by a clumsy first move. The IC coordinates a joint security/HR/legal response. 2. Do not tip off the subject unless safety or active destruction requires immediate action — premature confrontation can trigger evidence destruction or escalation. 3. Quietly scope what the individual accessed, copied, or altered, using identity and data-access logs.

Containment (discretion-driven; balance stopping harm against not tipping off and preserving evidence). - For active sabotage or imminent large-scale theft: move to disable access immediately (account, VPN, building access) and preserve systems — harm prevention dominates. - For suspected-but-not-active cases: covert monitoring under legal guidance, tightening access to sensitive data, and preparing a coordinated access-removal for the right moment (often timed with HR action). - For departures generally: the durable control is a clean offboarding process that disables accounts and access on the last day — preventing the orphaned-account version of this incident entirely (Chapter 18).

Eradication & recovery. - Remove the individual's access completely and rotate any shared credentials/secrets they knew. - Restore any sabotaged data/systems from backups; validate integrity. - Close the access path that allowed the over-reach (excess privilege, missing segregation of duties, an orphaned account).

Evidence to preserve. This is the most evidence-sensitive playbook because it may lead to termination or prosecution. Preserve, with rigorous chain of custody (Chapter 25) and legal guidance: data-access and file-transfer logs; USB/endpoint-DLP records; email and cloud-upload logs; the individual's device (imaged forensically, with HR/legal authorization); and the timeline. Do not let security act alone — evidence gathered improperly may be unusable and may expose the organization to liability.

Communications & notification triggers. - HR and Legal lead all communications about and with the subject; security advises. - Strictly need-to-know internally — reputations and legal outcomes are at stake; over-sharing can be defamatory and can tip off the subject. - Law enforcement if criminal activity (theft, sabotage, fraud) is confirmed and the organization chooses to pursue it — a legal/executive decision. - External notification only if data exposure triggers obligations (assess as in D.4, with counsel).

Post-incident actions. Postmortem focused on systemic controls, not just the individual: were least privilege, segregation of duties, access reviews (Chapter 18), data-loss prevention (Chapter 10), and offboarding adequate? Action items often include tightening access reviews, deploying/expanding DLP, and fixing the offboarding gap. Handle the human dimension with care — insider programs must balance security with employee trust and privacy.

D.6 Lost or stolen device

A laptop, phone, or other device with corporate access or data is missing. The severity hinges almost entirely on one control you set up in advance: was the device encrypted, managed, and remotely wipeable?

Trigger / indicators. An employee reports a lost/stolen laptop, phone, tablet, or removable drive; a device stops checking in to MDM/EDR unexpectedly; a device reported stolen in a theft/break-in; sign-in attempts from a device reported missing.

First 60 minutes. 1. Get the facts and set severity by what the device could expose. A fully encrypted, MDM-managed device with no cached sensitive data is low severity; an unencrypted device holding sensitive files, or one with cached credentials/active sessions to critical systems, is high. The pre-existing controls (FileVault/BitLocker, MDM, screen lock) determine which it is — exactly why Chapter 11 stresses full-disk encryption and central management. 2. Identify what was on it and what it could access — local data, cached credentials, active sessions, VPN/SSO access, saved tokens.

Containment. - Remote-lock and/or remote-wipe the device via MDM (the decisive action — Chapter 14's mobile management). - Revoke the device's sessions, tokens, and certificates, and disable or step up authentication for the user's accounts (assume the device's access is in hostile hands). - Rotate any credentials that were stored or cached on the device. - Suspend the device's VPN/network access and remove it from trusted-device lists.

Eradication & recovery. - Confirm the remote wipe succeeded (or, if the device never reconnects, treat its data as exposed and act accordingly). - Re-provision a replacement device from a hardened baseline; restore the user's data from backups (not from the lost device). - Restore the user's access on new, clean credentials.

Evidence to preserve. The report details (when, where, how it went missing); device identifiers (serial, asset tag, IMEI); MDM records of the device's last state and the wipe command/result; what data and access the device held; any sign-in attempts after the loss. For a theft, a police report is often needed for insurance and may matter for notification.

Communications & notification triggers. - Internal: IT/security and the user's manager; security confirms remote-wipe and access revocation. - Police: file a report for theft (often required for insurance). - Notification obligations: if the device held unencrypted personal/regulated data, this is frequently a reportable breach — note that many breach-notification laws provide a safe harbor for encrypted data (which is precisely why full-disk encryption is the load-bearing control here). If the device was encrypted and remotely wiped before exposure, notification may not be required — but confirm with counsel, because the standard varies and depends on whether the encryption key could also have been compromised.

Post-incident actions. Postmortem with a single dominant question: would this have been a non-event with the right pre-controls? If the device was unencrypted or unmanaged, the action items write themselves — enforce full-disk encryption with key escrow, MDM enrollment, screen-lock and remote-wipe capability across the fleet (Chapters 11, 14). One enforced control (encryption) routinely converts a reportable breach into a lost-hardware inconvenience.

D.7 Using these playbooks

Three points to carry into practice:

1. Build in priority order, by likelihood × impact (Chapter 1's risk thinking; Chapter 24's guidance). For most organizations, ransomware, phishing/BEC, and account compromise are the highest-value playbooks to have first; data-breach, insider, and lost-device follow. Do not wait to have all six perfect before having any.
2. A playbook references runbooks; write both. These playbooks say "isolate the host," "disable the account and revoke sessions," "remote-wipe the device." For each, your environment needs a runbook — the exact tool, screen, approvals, and verification steps — so the action is a thirty-second known procedure, not a 3 a.m. scavenger hunt (Chapter 24, §24.2). The tabletop is how you discover which runbooks you are missing.
3. Rehearse them, then improve them. A playbook that has never been walked in a tabletop is an untested assumption. Run the scenario (Chapter 24, §24.5), find the gaps, and feed them back into Preparation — closing the NIST lifecycle loop. A tabletop that finds no problems was facilitated too gently.

Finally, the lessons-learned phase is non-negotiable and blameless (Chapter 24, §24.6): for learning, the individual is almost never the root cause, and treating them as one destroys your ability to find the real one. Every postmortem produces a short list of owned, deadlined, tracked action items that change the system so the same failure cannot recur the same way — and tracks MTTD/MTTR (Chapter 36) as the honest measure of whether your response capability is actually maturing.