Updated May 2026, by the Ransomnews Research Team.
Most organisations buy a ransomware incident-response runbook the same way they buy fire-drill posters: someone in compliance ticks a box, the document goes into SharePoint, and nobody reads it again until it matters. By then it’s too late to find out the runbook assumed an Active Directory you decommissioned in 2023, references a CISO who left in 2024, and points to a forensics retainer that lapsed last quarter.
This walkthrough rebuilds a ransomware runbook from the ground up using two free authoritative sources, NIST Special Publication 800-61 Revision 3 and CISA’s #StopRansomware playbook, plus the operational lessons we extract from the leak-site listings we track on the Ransomtracker dashboard every day. The deliverable is a runbook that survives quarterly tabletops without rewriting.
The two source documents
- NIST SP 800-61 Revision 3, the US-government standard for incident response. Released April 2025, it explicitly integrates IR with the broader Cybersecurity Framework 2.0 and is the framework most US auditors expect to see referenced. Public link.
- CISA #StopRansomware Guide, a tactical playbook updated annually with current TTPs from named incidents. cisa.gov/stopransomware. Treat it as the operational checklist, not the framework.
Use NIST for structure, CISA for content. EU readers should read both alongside ENISA’s threat-landscape-for-ransomware reports for jurisdictional context.
The four-phase structure
Phase 1, Prepare
The cardinal pre-incident decisions need to be on file before you have a counterparty. Document at minimum:
- Authority matrix. Who can declare an incident, who can authorise containment actions that affect production, who can authorise external communications, who can authorise a ransom payment. With names and after-hours phone numbers, not just role titles.
- Decision tree on payment. Walk through “would we pay?” for three scenarios, encryption-only with intact backups, encryption with corrupted backups, data-extortion-only with regulated PII at stake. The answer can be “we decide at the time,” but the criteria you’d use to decide need to be written down now.
- Retainers. Outside counsel, IR firm, ransom-negotiation firm, communications agency. Verify each is current, including the after-hours escalation path. Most cyber-insurance policies require these to be panel-approved.
- Communications inventory. Customer comms templates, employee messages, supplier notifications, regulator-disclosure templates. Reviewed annually by legal.
- Tabletop schedule. Quarterly minimum; one of the four should include a board observer.
The decision-tree document is the differentiator. Most runbooks defer the hard questions to the incident itself, which is exactly when authority is fragmented and pressure is highest. A board that has already discussed “would we pay if our customer PII is on a leak site?” makes a different decision when the call comes in at 2am.
Phase 2, Detect and triage
Most ransomware incidents in 2026 are detected at one of three places: an EDR alert during the encryption phase (too late for prevention but useful for blast-radius limitation), a user calling the help desk because a network share is unreachable (later still), or, increasingly, your name appearing on a public leak site before any internal alert fires (catastrophic).
Three concrete detections to add if you don’t have them already:
- Honey accounts and honey shares, fake admin accounts in AD with no business use, watched for any login attempt; fake file shares with names attractive to ransomware lateral-movement scripts (
finance-share,backup) watched for any access. - Mass file-modification alerts on file servers, any single account modifying more than ~500 files in 5 minutes is anomalous. Most EDR will surface this; if yours doesn’t, write the rule.
- Leak-site monitoring, automate a daily check of the operators on our Ransomtracker dashboard for any mention of your domain, parent organisation, or recent acquisitions.
Phase 3, Contain and eradicate
The first 60 minutes after detection determine the rest of the response. The runbook needs an explicit, sequenced containment script:
- Isolate. Disconnect affected subnets at the network layer. Not “tell users to disconnect”, block at the firewall. Document which firewall rule, which interface, which approval needed.
- Preserve. Before powering anything off, take memory captures from a representative sample of affected endpoints. Volatile evidence (encryption keys in RAM, attacker tooling, lateral-movement traces) disappears on shutdown.
- Authenticate. Reset every privileged credential. Force re-auth on every administrative session. Revoke session cookies for SSO and VPN. Rotate API keys and service-account tokens with broad scope.
- Verify backups. Don’t trust them, verify. Most backup-system compromises were planned days or weeks before the encryption event; the runbook needs to anticipate “backups exist but are also encrypted or deleted.”
- Identify root cause. Before recovery, identify the initial access vector (IAB-supplied VPN credential? Phishing? Unpatched perimeter app?). Recovery without root cause is invitation to re-compromise.
Two artifacts to produce during this phase: a scope document, what’s encrypted, what’s exfiltrated, what’s still pristine, and a timeline, when did each event occur, in UTC, with source. Both feed regulator disclosure later.
Phase 4, Recover and disclose
Recovery is the longest phase and the one most runbooks treat as an afterthought. Three workstreams run in parallel:
- Technical restore, in priority order, life-safety systems, customer-facing systems, internal collaboration, everything else. The order needs to be on file; arguing about it during the incident wastes hours.
- Regulatory disclosure, SEC four-day rule for US-listed companies, NIS2 24/72-hour reporting in the EU, GDPR 72-hour rule for personal-data breaches, state-level breach laws in the US. The runbook should contain the exact wording for each first-notification channel and the named individual authorised to file.
- Stakeholder communications, employees first, then customers, suppliers, partners, media. Cadence matters: silence is not neutral, it reads as evasion. Pre-approved holding statements give you the breathing room to say “we are aware, we are responding, we will update at X UTC.”
The OFAC and sanctions question
If you’re contemplating payment, the runbook needs to anticipate the sanctions check. The US Treasury’s OFAC has issued advisories that paying ransoms to sanctioned entities can violate US law; UK and EU have followed with similar guidance. The pre-incident runbook needs to spell out:
- Who screens the operator and the ransom wallet against OFAC SDN, EU consolidated, and UK financial-sanctions lists.
- What standard of “reasonable diligence” the organisation is committing to (typically: blockchain analytics report, attribution research, IR-firm corroboration).
- Documentation requirements, the diligence file needs to exist and be retainable, in case of subsequent audit or enforcement inquiry.
- FBI / NCA / national-CERT engagement protocol, most insurers now require this engagement before payment as a coverage condition.
The post-incident review
NIST 800-61r3 places strong emphasis on the lessons-learned phase that most organisations skip. Two artifacts to produce:
- Root-cause analysis. What initial-access vector? What detection gap let the attacker stay inside before the encryption event? What containment friction slowed response? Each finding maps to a remediation owner with a deadline.
- Runbook update, signed off within 30 days. The single most common failure mode in IR programmes is producing the lessons-learned document and never updating the runbook with what was learned.
A two-page incident-commander quick reference
Print a two-page laminated quick reference for whoever’s running the incident. It contains, in order: the authority matrix, the contact tree (insurance / counsel / IR firm / FBI), the first-30-minutes containment script, the regulatory clocks, and the holding-statement templates. The full runbook lives in SharePoint; the quick reference lives on the desk.
Further reading and templates
- NIST SP 800-61 Revision 3, the framework.
- CISA #StopRansomware Guide PDF, the playbook.
- ENISA threat landscape for ransomware, EU-jurisdiction context.
- MITRE ATT&CK, for technique-level mapping during root-cause analysis.
- Our double-extortion explainer for the executive-level framing the runbook supports.
The runbook isn’t a document. It’s a system of decisions made before the pressure starts. Build it that way and the incident becomes a known process; treat it as a compliance artifact and you’ll be writing it during the breach.