What Is a Ransomware Playbook? A Guide for IT Professionals

Picture the scene that security teams describe again and again. A ransom note appears on a finance laptop at 2:47 AM. Someone calls whoever they think is in charge, a video bridge spins up, and people start arguing about whether to pay before anyone has confirmed what's even encrypted. That chaos is exactly what a ransomware playbook exists to prevent.

A playbook replaces improvisation with a rehearsed sequence. It says who leads, who isolates systems, who talks to legal, and what the first ten actions are, so the team executes instead of debating. For any IT professional responsible for systems that ransomware could reach, having one is no longer optional.

Playbook vs runbook: a quick clarification

The two terms get used interchangeably, and that's mostly fine, but there's a useful distinction. A playbook is the scenario-level plan for an incident type, covering decisions, roles and the overall flow of a ransomware response. A runbook is the granular technical procedure for a single task, like the exact commands to isolate a host or reset the krbtgt account. A strong playbook reads like a conductor's score and points to the detailed runbooks for each instrument.

The six phases of a ransomware playbook

Nearly every credible framework, NIST SP 800-61, CISA StopRansomware and SANS PICERL, organises response into the same arc. Here is each phase with what belongs in your playbook.

1. Preparation

This is the only phase you get to do calmly, and every hour spent here saves several during a real incident. Your playbook's preparation section should lock down:

• Roles and backups for each role. Name an incident commander, a technical lead, a communications lead, a legal liaison, and a deputy for each in case someone is unreachable.
• Out-of-band communications. Ransomware often encrypts email and chat first. Pre-agree a separate channel, such as an encrypted app on personal devices, so the team can still coordinate.
• Protected backups. Follow the 3-2-1-1-0 rule: three copies, two media types, one off-site, one immutable or air-gapped, and zero errors on a verified test restore.
• An asset inventory and recovery priority list, so you already know which systems come back first.
• Pre-authorised decisions. Senior leadership should approve the playbook in advance so responders can isolate systems or disable accounts without waiting for sign-off at 3 AM.

2. Detection and analysis

This phase confirms you're dealing with ransomware and scopes it. Your playbook should list the indicators worth watching and the first analysis steps.

• Detection indicators: mass file renames with new extensions, ransom notes appearing in directories, deletion of Volume Shadow Copies, abnormal CPU from encryption, EDR alerts, and unusual lateral movement over SMB.
• First analysis steps: capture system and memory images of affected hosts, identify patient zero and the initial access vector, determine the ransomware family, assess which systems and shares are hit, and check whether data was exfiltrated, which signals a double-extortion case.

3. Containment

Containment stops the spread. The defining decision here, and one your playbook must settle in advance, is whether to disconnect everything immediately.

If the encryptor is still actively running, isolate now, because every minute costs more systems. But where you can, isolate from the network rather than pulling power, so you preserve the memory evidence a forensic investigation will need.

Beyond the affected hosts, containment includes disabling compromised accounts, blocking attacker command-and-control traffic, and segmenting the network to protect what's still clean.

4. Eradication

Eradication removes the attacker's foothold, and it is not the same as restoring service. This is where the most expensive mistakes happen.

You cannot call eradication complete until you can answer, in writing, how the attacker got in and what persistence they left behind. That means identifying and patching the initial access vector, auditing Active Directory for malicious scheduled tasks, services and accounts, and hunting for backdoors beyond the ransomware payload itself.

5. Recovery

Now you bring systems back, in a deliberate order, from clean sources. The CISA-aligned recovery sequence looks like this:

1. Rebuild affected systems from known-clean images. Do not decrypt in place.
2. Restore data from offline backups, after verifying backup integrity first.
3. Reset all passwords, including service accounts and the krbtgt account.
4. Scan restored systems with updated EDR before reconnecting them to the network.
5. Re-enable services in priority order: authentication and DNS first, then email and critical apps, then file servers and departmental systems.
6. Monitor restored systems intensively for at least 72 hours for signs of reinfection.

This is also where solid recovery fundamentals matter. If you want a refresher on the underlying mechanics of getting files back from disks and drives, our guide to recovering deleted data covers the building blocks that backup and restore depend on.

6. Post-incident activity

The incident isn't over when service returns. Build a minute-by-minute timeline from the notes your team kept, run a root-cause analysis to find the exact gap that let the attacker in, and document how you'll close it. Track your metrics, Mean Time to Detect and Mean Time to Recover, against previous incidents and drills to prove whether you're improving. Then update the playbook while the details are fresh.

Test it, or it won't work

A playbook nobody has exercised is full of assumptions that break under real pressure. The widely recommended baseline is at least two tabletop exercises a year: one phishing-to-ransomware scenario and one credential-theft or insider scenario. Document what broke during each drill and fix it before the next one. The teams that recover fastest are not the ones with the longest documents, they're the ones who have rehearsed.

A word on paying the ransom

Your playbook should state a position on ransom payment, decided with legal and leadership well before an incident, not in the heat of one. The practical reality is that paying does not guarantee a working decryption key, and organisations that pay are often targeted again. This is exactly why protected, tested backups are the strongest card you can hold: recovery from verified immutable backups is almost always faster, cheaper and more reliable than negotiating with an attacker. Note too that ransom-payment decisions can carry legal and regulatory obligations, so this is a matter for counsel, not a snap call.