Ransomware Playbook: The Essential 2026 First-Hour Guide

A ransomware playbook exists for the moment a responder finds encrypted files and a ransom note, and has to act before anyone senior has picked up the phone. Ransomware compresses several hard problems into one incident: lost availability, possible data theft, an attacker who may still hold privileged access, and a demand for payment. Each of those needs a decision rule written in advance.

This post sets out a ransomware playbook in six stages: preparation, the first hour, containment and scoping, the payment decision, restoring from verified-clean backups, and recovery validation. It maps each stage to the outcomes in NIST SP 800-61 Rev. 3.

Why ransomware gets its own ransomware playbook

Rev. 3 names ransomware as one of its example incident types in RS.MA-03.R1, and Section 2.3 asks for playbooks with actionable steps for particular scenarios. Under the CSF 2.0 structure Rev. 3 uses (our post on the NIST incident response lifecycle explains it), ransomware touches every Function at once.

Rev. 3 is not ransomware-specific guidance. NIST’s ransomware profile is, and our post on the NIST ransomware profile covers it. The ransomware playbook below uses Rev. 3 as its spine and treats the profile as the deeper reference for preventive controls.

Before the incident: what a ransomware playbook depends on

A ransomware playbook cannot create backups or contacts after the fact. These need to be in place before you need them:

• Backups that survive the attacker. PR.DS-11, the only Protect Subcategory Rev. 3 rates High, asks that backups be created, protected, maintained and tested. Keep at least one copy that an attacker holding administrator credentials cannot alter or delete, such as an offline or immutable copy.
• Tested restores. A backup you have never restored is an assumption. Test full restores of critical systems, not single files.
• An out-of-band channel. Assume email and chat may be visible to the attacker or unavailable. Agree a separate channel and keep the contact list somewhere that does not depend on your network.
• An offline copy of the playbook. If the file share holding your ransomware playbook is encrypted, the playbook is gone.
• Retained help. RS.MA-01.R2 says to contact your incident response service provider if appropriate. Have the contract signed and the number on paper.
• Linked continuity plans. RS.MA-01.R3 says to initiate other plans, such as business continuity and disaster recovery, as needed. Our ransomware business continuity post covers keeping operations running while systems are down.

The first hour of the ransomware playbook

The first hour is about stopping spread and preserving your ability to recover. Investigation comes next. These steps can run in parallel if you have the people.

Action	Owner	Why
Declare the incident, name an incident lead, open a decision log	On-duty handler	DE.AE-08, RS.MA-01.C1, RS.AN-06
Move response communication to the out-of-band channel	Incident lead	The attacker may be reading your email
Isolate affected hosts from the network	Handlers, IT	Stops spread; prefer network isolation over powering off, so memory evidence survives
Protect the backup platform: restrict access, rotate its administrator credentials, check for deleted jobs or snapshots	IT, backup owner	Assume the backup platform is a target until shown otherwise
Disable accounts seen in the attack; plan privileged credential resets	Identity team	Assume privileged credentials are compromised
Preserve the ransom note, sample encrypted files, logs and EDR telemetry	Handlers	RS.AN-07: preserve integrity and provenance
Brief leadership and legal; call the retained IR provider	Incident lead	Elevation and escalation (RS.MA-04)

Score severity with your matrix as soon as the facts allow. Confirmed encryption on production systems puts stage of activity at the top of the scale, so in our own scheme a second critical factor makes it the highest severity tier.

One trade-off belongs in the playbook explicitly. If encryption is spreading faster than hosts can be isolated, the incident lead may need to authorize shutting down segments or services. Write down who holds that authority and the facts they need, so the decision takes minutes, not a meeting.

Containment and scoping

Rev. 3’s RS.MA-03.R3 asks you to balance quick recovery against observing the attacker or investigating more thoroughly. In a ransomware playbook the balance should tilt hard toward containment. RS.MI R1 notes that redirecting an attacker to a sandbox delays containment and eradication, and that legal should be consulted before it is attempted.

Scope wider than the encrypted hosts. RS.AN-08.R1 asks you to look for indicators of compromise and persistence on other potential targets, not only the assets known to be hit, and warns that a superficial look can leave the attacker active elsewhere. For ransomware, answer these questions:

• How did the attacker get in, and is that path closed?
• Which accounts, especially privileged ones, did they use?
• What persistence did they leave: scheduled tasks, new accounts, remote access tools?
• Was data copied out before encryption? If so, this is also a data incident, and the data impact factor changes.
• When is the earliest evidence of compromise? That date drives your restore point.

Eradication under RS.MI-02 means removing persistence and entry points, disabling breached accounts and mitigating exploited vulnerabilities. RS.MI-02.R1 asks you to identify all affected hosts and services so every weakness can be fixed. Do not start restoring into an environment the attacker can still reach.

The ransom payment decision in a ransomware playbook

The decision whether to pay a ransom is reserved to executive leadership, acting with legal counsel. Before that decision is considered, legal counsel must first assess sanctions exposure and reporting exposure. Your ransomware playbook should state this in one sentence and assign it to named roles.

The playbook’s job is to keep the decision where it belongs and to make sure the response does not depend on it:

• No responder contacts the attacker unless executive leadership has authorized it, with legal counsel involved.
• Preserve the demand. The ransom note, any contact address and any proof of data theft are evidence. Record them without engaging.
• Plan recovery as if payment will not happen. Containment, scoping and restoration continue in parallel with any leadership discussion.
• Treat any decryptor as untrusted software. If one is ever obtained, test it in isolation and validate every system it touches exactly as you would a restored one.

Notification runs alongside all of this. RS.CO-02.R3 asks you to notify in compliance with the laws that apply to your sectors and locations, and RS.CO-02.R5 ties law enforcement and regulator notification to plan criteria and management approval. Notification clocks differ by regime and start from different triggers, so legal should begin that analysis at declaration. Our breach notification post covers how those obligations vary.

Restore only from verified-clean backups

This is the step a ransomware playbook most needs to get right. RC.RP-03.R1 asks you to check restoration assets for indicators of compromise, file corruption and other integrity issues before using them. A backup taken after the attacker arrived can restore the attacker along with your data.

1. Pick the restore point from the investigation, not from the encryption timestamp. It should predate the earliest evidence of compromise.
2. Scan and inspect the backup in an isolated environment before it touches production.
3. Restore in priority order. RC.RP-04.R1 asks you to validate that essential services are restored in the appropriate order. Restore identity and core infrastructure before the business applications that depend on them.
4. Weigh precision against speed. RC.RP-02.R1 notes that recovery actions should account for timeliness, precision and reliability, such as restoring only affected files versus everything.
5. Rebuild where you cannot trust. Rev. 3’s Recover notes list rebuilding systems and, against a highly sophisticated attacker whose full scope is unknown, replacing hardware.

RS.MA-05.R2 asks you to consider the operational disruption recovery itself will cause when deciding when to start. A rushed restore into a still-compromised network can put you back where you started.

Recovery validation and closing the incident

Check before declaring recovery complete	Rev. 3 anchor
Restored assets checked for indicators of compromise	RC.RP-05.R1
Root causes remediated before production use	RC.RP-05.R1
Restoration verified as correct and adequate before going online	RC.RP-05.R2
System owners confirm normal operation	RC.RP-04.R2
Restored systems monitored for performance and recurrence	RC.RP-04.R3
Leadership updated on recovery status throughout	RC.CO-03.R2
End of recovery declared against criteria; after-action report written	RC.RP-06.R1

The after-action report should feed changes back into the ransomware playbook itself. Rev. 3 asks for lessons to be shared as soon as they are identified, not held until recovery ends, so update the playbook while the details are fresh.

Ransomware playbook FAQ

Who decides whether to pay a ransom?

Executive leadership, with legal counsel, after counsel has assessed sanctions and reporting exposure. A ransomware playbook should never leave that call to responders.

Should we power off infected machines?

Prefer network isolation so memory evidence survives. If encryption is spreading faster than isolation can stop it, the incident lead may authorize shutdowns.

Does NIST SP 800-61 Rev. 3 include a ransomware playbook?

No. NIST SP 800-61 Rev. 3 names ransomware as an incident type and recommends playbooks, but you write the playbook yourself.

How do we know a backup is safe to restore?

Choose a restore point before the earliest evidence of compromise, inspect it in isolation for indicators of compromise and corruption, and verify restored systems before they go into production.

Our Incident Response Toolkit provides 93 editable templates aligned to NIST SP 800-61 Rev. 3 — including the Ransomware Playbook, the Ransomware Tabletop Scenario and the Incident Handling Checklist — for $99.