Ransomware recovery is a control. Test it like one.
Most organizations can show that backups run. Far fewer can show that they could rebuild identity, restore critical services in a known order and do it while an adversary may still be present. Recovery capability should be evidenced, not assumed.
- Published
- May 27, 2026
- Reading time
- 10 minutes
- Written by
- MarkTillson Enterprise Resilience Practice
Ask an organization whether it is prepared for ransomware and you will usually hear about prevention: endpoint detection, email filtering, patching, multifactor authentication. All necessary. Yet the question that determines whether a ransomware event is a bad week or an existential crisis is different: how quickly, and in what order, can we restore the services the business depends on, starting from a position where we cannot trust our own environment?
That capability is rarely tested end to end. Backups are monitored for success; restores of individual files are performed when users ask; disaster recovery plans are walked through annually. None of that proves recovery from a deliberate, destructive attack. This article sets out why, and how to evidence recovery as a control.
Why ransomware recovery is different from disaster recovery
Traditional disaster recovery plans assume an accident: a data center fails, a region goes down, a storage array corrupts. The infrastructure you recover with is trustworthy, and the cause is gone. Ransomware breaks both assumptions.
- The adversary targets recovery. Modern ransomware operators routinely seek out and destroy or encrypt backups, snapshots and backup catalogs before triggering encryption, and often steal data for extortion as well.
- The environment is untrusted. Restoring into the same network, with the same compromised identities, can reintroduce the attacker. Recovery has to be sequenced with containment and eradication.
- Identity goes down first. If directory services are encrypted or compromised, almost nothing else can be restored until they are rebuilt, because everything authenticates through them.
- Everything fails at once. Disaster recovery plans are often written per system. Ransomware hits hundreds of systems simultaneously, so the order of restoration becomes the plan.
What a recoverable organization can show
We assess recovery capability against five properties. Each one can be evidenced.
| Property | The question | Evidence that answers it |
|---|---|---|
| Survivable backups | Would backups survive an attacker with domain administrator rights? | Immutable or logically air-gapped copies; separate administrative identities for the backup platform; retention locks; tested deletion attempts |
| Recoverable identity | Can you rebuild directory services from a known-good state? | Documented, rehearsed identity recovery procedure; offline copies of what it needs; a record of the last rehearsal and its duration |
| Known order | Which services come back first, and what do they depend on? | Dependency-mapped restoration sequence derived from business impact analysis, not from server lists |
| Clean rooms | Where will you restore while the main environment is untrusted? | A designed isolated recovery environment, or a documented approach to building one quickly |
| Measured time | How long does recovery actually take? | Timed restoration exercises for critical services, compared with recovery time objectives and impact tolerances |
Testing recovery properly
Recovery tests that build genuine confidence share some characteristics.
They start from the attacker’s assumptions
Before testing restoration, test destruction. Can an account with the privileges an attacker would plausibly obtain delete backups, shorten retention, disable immutability or remove the backup catalog? If so, the backup design is the first finding, regardless of how well restores perform.
They restore services, not files
Restoring a virtual machine proves the backup is readable. Restoring a whole service (the application, its database, its integrations, its identity dependencies and its configuration) in an isolated environment and showing that a business user can complete a transaction proves recoverability.
They include identity
Directory forest recovery is complex, rarely performed and frequently undocumented beyond vendor guidance. A rehearsal in an isolated environment, even annually, transforms it from a theoretical capability into a timed one.
They are timed and compared
Every exercise should record how long each step took and compare the total with the recovery time objective agreed with the business. The gap between the two is the most useful number a board can see.
They involve decision-makers
Tabletop exercises should rehearse the decisions technical tests cannot: who declares the incident, who communicates with regulators, customers and law enforcement, how a ransom demand would be considered, and what legal and sanctions constraints apply. US Treasury’s Office of Foreign Assets Control, for example, has published advisories on the sanctions risks of facilitating ransomware payments.
Pick the single most important business service. In an isolated environment, restore it from backup, including its identity dependencies, without using any credential or system from production. Time it. The result usually reshapes the recovery program more than any maturity assessment.
Where the frameworks point
Several frameworks now treat recovery as a first-class capability. The NIST Cybersecurity Framework 2.0 includes a Recover function covering recovery plan execution and communication. NIST’s ransomware profile (NIST IR 8374) applies the framework specifically to ransomware risk, and NIST SP 800-184 provides guidance on recovery planning. For EU financial entities, DORA requires backup policies and restoration and recovery procedures, with backups that are segregated from the source systems, and periodic testing of those procedures. The joint US government #StopRansomware guide offers practical prevention and response checklists.
None of these frameworks will tell you whether your organization can recover in time. Only testing will.
Building the program
- Agree what “recovered” means for each critical service, in business terms, with impact tolerances or recovery time objectives the business has signed off.
- Map dependencies from each critical service down to identity, network, data and third-party components.
- Harden the backup platform as a tier-zero asset: separate identities, immutability, monitoring of deletion and retention changes.
- Design the clean room and write the identity recovery procedure.
- Test, time and report at least annually and after major changes, with technical exercises for restoration and tabletops for decisions.
Key takeaways
- Backups that run are not backups that survive. Test whether an attacker could destroy them.
- Identity recovery comes first and is rarely rehearsed.
- Restore services, not files, into an environment the attacker cannot reach.
- Time everything and compare it with what the business agreed it can tolerate.
- Rehearse decisions as well as restores.
Sources
- NIST, Cybersecurity Framework 2.0, February 2024, Recover function.
- NIST IR 8374, Ransomware Risk Management: A Cybersecurity Framework Profile.
- NIST SP 800-184, Guide for Cybersecurity Event Recovery.
- CISA, FBI, NSA and MS-ISAC, #StopRansomware Guide.
- Regulation (EU) 2022/2554 (DORA), Article 12, backup policies and restoration and recovery procedures.
- US Department of the Treasury, OFAC, advisory on potential sanctions risks for facilitating ransomware payments.
Our ransomware resilience assessments start from the attacker’s assumptions: we try to destroy your backups, then time your recovery from a clean room. Find out how long your critical services would really be down, before an attacker tells you.
