What this template is for
This is a working document, not a policy. A ransomware response playbook tells the person on call, at the moment of highest stress, what to do first, who decides, and what must be written down. This template gives you the skeleton — phases, decision points, contact fields, and evidence requirements — so you can fill in the blanks with your own names, systems, and authority levels instead of writing a playbook from a blank page.
Use it when you need to answer three questions fast:
- Is this actually ransomware, and how far has it spread?
- Do we contain it now, or keep systems up long enough to gather evidence?
- Who can authorize a shutdown, a rebuild, or a payment-related decision, and who talks to whom?
The template deliberately stops short of two things. It does not decide whether to pay a ransom — that is a legal, financial, and business decision your leadership makes with counsel and your insurer. And it does not replace backups, segmentation, or endpoint detection. A playbook is the procedure you follow using the controls you already built.
If the document cannot be read without the network, it does not exist. Keep an offline copy.
How to use it
Budget half a day to fill it in and one hour per quarter to keep it current.
- Name an owner. One person accountable for the playbook, usually the incident response lead or security manager. Unowned playbooks rot.
- Replace every bracketed field. Names, phone numbers, ticketing queue, evidence storage location, legal counsel, insurer claim line, and communications lead. A blank field is a failure point.
- Define decision authority in writing. State who may isolate a subnet, shut down a server, and approve restoration from backups, plus the backup person for each of those roles.
- Set severity triggers. Decide in advance what escalates to executive leadership and what stays with the on-call analyst.
- Print it and store it offline. Two copies: one in the incident response bag or safe, one with the deputy. Include an out-of-band contact method that does not depend on email or the corporate chat tool.
- Walk it through a tabletop. Exercise the containment decision with realistic constraints — no admin credentials, half the team unreachable, backups of unknown integrity.
- Review after every use and every quarter. Update the template with what you learned while it is still fresh.
What to change before you adopt it: the phase names, the order of steps if your tooling handles some of them automatically, the contact roster, and the notification section. Everything else — the evidence discipline, the containment decision, the restore-verification loop — should stay recognizable. If you cut those, you have a checklist, not a playbook.
The template itself
Copy the block below into a document, replace the bracketed values, and delete any line that does not apply to your environment.
RANSOMWARE RESPONSE PLAYBOOK
Owner: [name] | Version: [x.y] | Last tested: [date]
Offline copies held by: [name], [name]
PHASE 1 - DETECT AND TRIAGE (target: 15 minutes)
[ ] Record time of first alert and who reported it
[ ] Open incident ticket in [queue] and assign severity [1-4]
[ ] Identify the trigger: EDR alert, backup failure, user report,
mass file-extension change, or ransom note
[ ] Determine scope: how many hosts, which shares, which accounts, which sites
[ ] Do NOT power off encrypted endpoints if you still need volatile memory
[ ] Notify the on-call lead: [name] [method] - out of band
PHASE 2 - CONTAIN (target: 60 minutes)
Decision: isolate or observe?
- Encryption still spreading actively -> ISOLATE NOW
- Encryption appears stopped, low spread -> ISOLATE, then collect
- Suspected staging, no encryption yet -> OBSERVE briefly, collect first
[ ] Isolate affected hosts by disabling the switch port or network adapter
[ ] Disable compromised accounts, revoke active sessions and tokens
[ ] Block known command-and-control indicators at the perimeter and DNS
[ ] Protect the backup environment: pause backup jobs, snapshot the backup server
[ ] Freeze changes to affected systems; stop scheduled tasks and patch windows
[ ] Log every action with time, actor, and justification - this becomes the record
PHASE 3 - COLLECT AND PRESERVE
[ ] Memory capture on at least one patient-zero host where feasible
[ ] Preserve logs before rotation: EDR, OS event logs, authentication,
VPN, DNS, firewall
[ ] Note the hash and storage location of the ransom note
[ ] Store evidence at [location]; record custody: who, when, why
PHASE 4 - DECISION POINT: PAY OR NOT
[ ] Convene [role], [role], external counsel [firm], insurer [line]
[ ] Ask counsel whether sanctions screening is required for this actor
[ ] Do not contact the actor without counsel and insurer approval
[ ] Document the decision and the reasoning behind it
PHASE 5 - ERADICATE AND RECOVER
[ ] Identify the initial access vector and close it before restoring anything
[ ] Rebuild from known-good images; never restore over a compromised host
[ ] Restore a small pilot set first, verify integrity, then scale up
[ ] Reset credentials for every account with access to affected systems
[ ] Confirm backups are not themselves encrypted before relying on them
[ ] Re-enable monitoring on restored systems at higher sensitivity
PHASE 6 - NOTIFY AND COMMUNICATE
[ ] Internal: [distribution list], first update within [x] hours
[ ] Executive brief: impact, current state, next decision required
[ ] Legal and regulatory notification triggered by: [confirm with counsel]
[ ] Customer and partner messages approved by [role] only
[ ] Single spokesperson: [name]; no other statements
PHASE 7 - AFTER ACTION (within two weeks)
[ ] Timeline of events with timestamps
[ ] Root cause and control gaps
[ ] Owner and due date for each corrective action
[ ] Update this playbook and schedule the next tabletop
CONTACT ROSTER (keep offline, update quarterly)
IR lead: [name] [mobile] [alt method]
Deputy: [name] [mobile] [alt method]
Legal counsel: [firm] [name] [24h line]
Insurer claim line: [policy] [line] [reference]
Comms lead: [name] [mobile]
Law enforcement contact: [agency] [contact method]
OT or platform vendor: [name] [line]The containment decision and the evidence custody log matter most. Keep both even if you trim other sections.
Adapting it to your environment
Small business with no dedicated IR team. Collapse phases 1 and 2 into a single first-hour checklist for whoever is on call, and name an external provider as your IR lead in the roster. The payment decision point stays; it does not go away because the team is small.
Cloud-first or hybrid. Replace switch-port isolation with cloud-native actions: revoke session tokens, apply a deny-all security group, snapshot the instance before terminating it, and export cloud audit logs to immutable storage. Add a line for identity and key rotation, and note that identity compromise often matters more than host compromise.
Managed service providers. Add a section on tenant isolation — how you prevent one customer’s incident from reaching another — and a contractual notification list, since your obligations to clients may be tighter and faster than your regulatory ones.
Operational technology and industrial environments. Add a stop-work and safety authority, and a written rule that no control-system host is isolated or rebooted without the operations lead’s approval. Availability can outrank evidence on a production line.
Regulated industries. Your notification clock, preservation duties, and reporting thresholds are set by law, contract, and regulator. Have counsel confirm them once, write the actual deadlines into the template, and treat any number you cannot source as unknown. Never guess a deadline mid-incident; call counsel and start the clock conservatively.
Finally, test the roster. Call those numbers once a quarter. A playbook fails less often from a missing step than from a phone that rings in an empty office.
