Ransomware Playbook Template

In a ransomware attack the decisions that matter most are made in the first hour, under pressure, by people who often cannot reach email, the identity provider or the backup console. This template is a ready-to-adopt ransomware playbook covering detection triggers, the first hour, activation and roles, scoping, identity plane checks, backup validation, communications, a ransom demand decision record, law enforcement reporting, recovery sequencing and lessons learned, each with owners and target times. It follows the CISA #StopRansomware Guide, NCSC recovery guidance and NIST IR 8374 Rev. 1, and sits under your [Incident Response Plan]. It is for incident managers, security operations, IT and identity teams, and the executives who approve the hard calls.

How to use this template

• Replace text in square brackets, such as [Organisation], [Incident manager] and [15 minutes], with your own teams, tools and targets.
• "Must" is mandatory; "should" is recommended. Target times run from declaration of the incident.
• Severity, escalation and notification rules come from the [Incident Response Plan]. A confirmed ransomware event is always SEV1.
• Print it. Keep a copy, the contact list and the recovery priority list offline, because the file shares and wiki may be encrypted.
• Commands and product names are worked examples for Windows, Active Directory, Entra ID and AWS; map each step to your own platforms.

1. Purpose

This playbook sets out how [Organisation] responds to ransomware and data extortion: stopping spread, preserving evidence, regaining control of identity, recovering from clean sources, meeting reporting duties and making any ransom decision in a documented, lawful and accountable way. NIST IR 8374 Rev. 1 notes that immediate execution of the response plan "is necessary to stop any continuing exfiltration of data".

2. Scope and detection triggers

The playbook covers encryption of endpoints, servers, hypervisors (including ESXi) and cloud storage, and extortion based on stolen data with or without encryption. Any trigger below must be treated as a suspected ransomware incident until disproved.

3. Activation and roles

The [Incident manager] declares SEV1, opens the out-of-band bridge ([phone bridge or alternate tenant]) and assigns the roles below. Each must have a named deputy.

4. First hour: initial actions

5. Scoping

6. Identity plane checks

Ransomware operators usually hold domain or cloud administrator rights before they encrypt. NCSC states that "trusted identity is a critical dependency for recovery". All actions below must be performed from a trusted device built from a clean source, such as a privileged access workstation, as Microsoft advises.

Stolen machine credentials can carry the attack beyond the network: the Codefinger S3 ransomware used stolen AWS keys to encrypt buckets with AWS's own encryption, and in the Storm-0501 attacks Entra Connect Sync credentials took operators into the cloud. See the Active Directory and Entra ID Hardening Guide and the Service Account Security Guide.

7. Backup validation and clean recovery

1. Assume backups were targeted. NCSC advises responders to "seek appropriate assurance that they are immutable and uncompromised", and warns that backups "may not cover the full environment, including applications, identity systems and sources of trust".
2. Pick a restore point before the earliest attacker activity found in scoping, not just before encryption, and check it for precursor malware and persistence such as scheduled tasks and remote management tools.
3. Restore into an isolated recovery network, scan with current signatures and indicators, and verify integrity before use, as CSF 2.0 RC.RP-03 requires.
4. Rebuild rather than clean where persistence cannot be ruled out; use standard images and infrastructure as code for cloud resources.
5. Reset passwords and update customer-managed encryption keys after the environment is rebuilt, and take care, in CISA's words, "not to re-infect clean systems during recovery".

See the Backup Security and Immutable Backup Guide.

8. Communications

9. Ransom demand decision record

This section records a decision; it is not legal advice and contains no payment instructions. NCSC guidance written with the ABI, BIBA and IUA states: "The ultimate decision whether to pay the ransom is with the victim." In the US, OFAC "strongly discourages all private companies and citizens from paying ransom or extortion demands" and may impose penalties on a strict liability basis where a payment involves a sanctioned person. In the UK, NCSC notes that payments "may not be lawful" if made to a sanctioned entity or area, and that the ICO does not treat payment as a risk mitigation.

NCSC warns "you cannot trust a promise to delete it once a ransom is paid", so the data breach assessment continues whatever is decided. See the Cyber Insurance Guide.

10. Law enforcement and regulatory reporting

OFAC treats a self-initiated, complete and timely report to law enforcement, and full cooperation, as significant mitigating factors.

11. Recovery sequencing

If eviction is uncertain, NCSC warns that "proceeding with recovery carries a risk of the incident restarting". The designated authority declares the incident over on agreed criteria. See the Ransomware Response and Recovery Guide.

12. Lessons learned

• Hold a blameless review within [10 business days] of closure, covering entry point, dwell time, what slowed containment and recovery, and decision quality.
• Record metrics: time to isolate, time to regain Tier 0 control, share of services restored within RTO, data lost against RPO, and credentials rotated against those in scope.
• Add detections for the techniques seen, share indicators with CISA, NCSC or your ISAC, and track actions to closure. See the Ransomware Prevention Guide.

13. Source references

1. CISA: #StopRansomware Guide
2. NIST: IR 8374 Rev. 1 Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile
3. NCSC: Recovering from a highly disruptive cyber attack, recovery and ongoing investigations
4. NCSC: Guidance for organisations considering payment in ransomware incidents
5. NCSC: Mitigating malware and ransomware attacks
6. US Treasury OFAC: Updated Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments
7. Microsoft Learn: AD Forest Recovery, reset the krbtgt password
8. Microsoft Security: Advice for incident responders on recovery from systemic identity compromises
9. MITRE ATT&CK: T1490 Inhibit System Recovery
10. Report Fraud: Report Fraud service goes live

Implementation guidance

1. Pre-authorise isolation: agree in advance that the technical lead may isolate hosts and segments without waiting for executives, and who can approve a full network shutdown.
2. Prepare the offline kit: printed playbook, contacts, recovery priority list, network diagrams, break-glass credentials in a safe, and clean media for admin workstations.
3. Know your NHIs: list the service accounts, backup and hypervisor credentials, API keys and app registrations section 6 must rotate, with owners. See the Secrets Management Guide.
4. Test restores and identity recovery: restore a domain controller and a critical application into an isolated network at least [annually] and time it against the RTO.
5. Rehearse the decision record: run a tabletop with executives, legal and the insurer using section 9.

Small organisations should arrange an IR retainer or insurer panel firm before an incident and can merge roles, keeping one deputy for each. Large organisations should keep per-business-unit recovery orders and tie this playbook to their crisis management and business continuity plans.

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Ransomware Response and Recovery Guide · Ransomware Prevention Guide · Backup Security and Immutable Backup Guide · Incident Response Guide · Ransomware Groups Guide