Ransomware Recovery Readiness Checklist
The uncomfortable question isn't "could we get hit?" — it's "if we did, could we actually recover?" This is the checklist our readiness review runs against. Work through it honestly; every box you can't check is a place an incident could turn into a catastrophe.
1. Backups that exist and actually work
Green backup jobs are not the same as a proven recovery.
Every critical workload is backed up — production servers, databases, and SaaS (Microsoft 365, Google Workspace, Salesforce), not just the file server.
You have completed a full test restore in the last 90 days — not just verified that jobs ran green.
Backup coverage matches a defined RPO — you know how much data you'd lose per workload, and it's acceptable to the business.
Someone owns backups — a named person is accountable, and failures generate an alert someone acts on.
2. Immutability — backups an attacker can't destroy
Modern ransomware hunts your backups first. If they can be encrypted or deleted, they don't count.
At least one backup copy is immutable — write-once, cannot be altered or deleted within its retention window, even by an administrator.
Immutable retention is sized correctly — long enough to outlast a dwell period where the attacker sits undetected for weeks.
The 3-2-1 rule holds — three copies, two media types, one off-site or off-account.
3. Isolation — separate blast radius
If your backups share the domain and network with production, one breach takes both.
Backup infrastructure is isolated from production identity — separate credentials, not the same domain admin that runs everything else.
Network paths to backups are restricted — a compromised production host can't freely reach and encrypt the backup store.
Anomaly detection is on — unusual deletion or encryption activity against backups raises an alert.
4. Recovery you've rehearsed
The first time you run your recovery plan should not be during a real incident.
You have a documented recovery runbook — step by step, executable by someone who isn't the one person who built it.
You've run a recovery exercise — ideally into an isolated clean-room environment, not over the top of production.
You know your real RTO — measured in a rehearsal, not estimated in a meeting.
Recovery restores clean — you can rebuild without re-introducing the malware, and you'd know where to rebuild to.
5. Incident response & the human side
Technology recovers systems; a plan recovers the organization.
You have an incident-response plan — roles, contacts, and decisions defined before the pressure is on.
You've run a tabletop exercise — the humans have practiced their part, including who talks to whom.
You know your forensic posture — you can preserve the compromised environment as evidence instead of destroying it during recovery.
Escalation and outside help are pre-arranged — you know who to call before you need them.