The recovery plan nobody has tested: ransomware resilience as a control

Most organizations can show me a recovery plan. Far fewer can show me evidence that the plan works. A plan that has never been tested under realistic conditions is a hope, not a control, and ransomware is very good at exposing the difference. This article looks at how to treat recovery as a control that is designed, tested, and evidenced like any other, and what leadership should ask before the day they need it.

Why ransomware changes the recovery question

Traditional disaster recovery planning assumed a failure you could see: a data center outage, a hardware fault, a flood. The backups were intact. The question was how fast you could switch over.

Ransomware breaks that assumption. Attackers commonly look for backups and try to encrypt or delete them before they trigger the encryption that everyone notices. They may have been in the environment for some time. Credentials may be compromised. The systems you would use to run the recovery may themselves be affected.

So the recovery question is no longer only “can we restore?” It is “can we restore from something we trust, into an environment we trust, in a time the business can live with?”

Backups the attacker cannot reach

The first line of resilience is a copy of critical data that an attacker with administrative access cannot alter or delete. That usually means some combination of immutable storage, where data cannot be changed for a set retention period, and offline or logically isolated copies that are not reachable from the production network.

Questions I ask when assessing this:

• Which backups are immutable, and for how long?
• Who can change the retention settings, and is that access separate from production administration?
• Are backup system credentials stored and managed separately from the main identity platform?
• Is there at least one copy that would survive a full compromise of the primary domain?

If the same administrator account can delete production servers and the backups that protect them, the backups are not an independent control.

A successful job is not a successful restore

Many backup reports show a green dashboard: jobs completed, no errors. That tells you data was copied. It does not tell you the data can be restored, that it is complete, or that the application will run once it is back.

Real assurance comes from restoration testing. That means restoring a system in full, starting the application, and confirming that the data is usable and current. File-level restores of a few documents are useful for routine checks, but they do not prove you can bring back a core banking platform or an enterprise resource planning system.

A meaningful restoration test records how long the restore actually took, what broke, and what manual steps were needed. Those details are the real output. A test that “passed” with no notes usually was not tested hard enough.

The dependencies nobody planned for

Applications do not restore in isolation. In a ransomware scenario, the supporting services are often the first things lost, and the last things anyone thought to plan for.

Dependency	Why it matters in recovery	Question to ask
Identity and directory services	Nobody can log in to restore anything without them, and they may be compromised	Can we rebuild identity from a trusted state, and in what order?
DNS and network services	Restored systems cannot find each other without name resolution	Is DNS configuration backed up and part of the recovery sequence?
Encryption keys and certificates	Encrypted backups are useless without the keys	Where are the keys held, and are they available if the main environment is down?
Privileged access tooling	Recovery requires elevated access, often through a vault	Can we reach the vault, or is there a documented break-glass path?
Communications	Email and chat may be unavailable or untrusted	How will the recovery team coordinate if corporate systems are down?

Recovery order matters as much as the list. If identity has to come back before anything else, that needs to be documented, tested, and timed.

RTO and RPO belong to the business

Recovery time objective (RTO) is how long a service can be down. Recovery point objective (RPO) is how much data the organization can afford to lose. These are business decisions, not technical settings.

A common gap is that IT has set these targets on its own, or that the business has set targets that the current backup design cannot meet. Both are gaps. The targets should be agreed with business owners, tied to the impact of an outage, and then tested. If a restoration test shows the real recovery time is three days and the agreed RTO is four hours, leadership needs to know that before an incident, not during one.

Tabletop exercises and technical tests are different controls

Tabletop exercises and technical recovery tests answer different questions. Both are useful, and neither replaces the other.

A tabletop exercise walks leaders and responders through a scenario. It tests decisions, roles, communications, and escalation. Who decides how to respond to a ransom demand? Who talks to regulators, customers, and law enforcement? Who has authority to take systems offline?

A technical exercise tests whether the systems actually come back. It shows whether the runbooks are accurate, whether the people who need access have it, and whether recovery times match the targets.

An organization that only runs tabletops knows how it will make decisions but not whether it can execute them. One that only runs technical tests may restore systems efficiently while leadership argues about who is in charge.

Cloud does not remove the responsibility

Moving workloads to the cloud changes how backups are done. It does not transfer accountability for them. Under the shared responsibility model, the provider is responsible for the resilience of its infrastructure. The customer is typically responsible for protecting its own data, configurations, and access.

In my AWS and Azure control assessments, the questions are the same as on premises. Are backups enabled for the services that matter? Are they protected from deletion by the same accounts that run production? Are they stored in a separate account or subscription? Has anyone restored from them? Software-as-a-service applications deserve the same scrutiny, since native retention features are not always designed as a recovery capability.

Where frameworks fit

The NIST Cybersecurity Framework 2.0 includes a Recover function focused on restoring assets and operations after an incident, alongside functions for governing, identifying, protecting, detecting, and responding. It is a useful reminder that recovery is part of the security program, not an afterthought handed to infrastructure. For financial institutions, the FFIEC IT Examination Handbook also addresses business continuity and resilience, and examiners expect to see testing, not just documentation.

Frameworks set expectations. They do not tell you whether your own recovery will work. Only testing does that.

What leadership should ask

If you are an executive or board member, these questions will tell you quickly whether recovery is a control or an assumption:

1. When did we last restore a critical system in full, and how long did it actually take?
2. Do we have backups that an attacker with administrator access could not delete?
3. Are our recovery time and data loss targets agreed with the business, and has testing shown we can meet them?
4. What has to be restored first, and has that sequence been tested, including identity, DNS, and keys?
5. Have we run both a tabletop exercise and a technical recovery test in the last cycle?
6. For cloud and SaaS services, who owns backup, and where is the evidence of a restore?
7. What did the last test reveal, and have those gaps been fixed and retested?
8. How would the recovery team communicate if email and chat were down?

If the answers are vague, the plan has not been tested in a way that matters.

Recovery is a capability you prove

No organization can guarantee it will never be hit by ransomware. What it can do is prove, in advance, that it can recover. That proof comes from immutable copies, full restores, tested dependencies, and targets the business has agreed to. Without it, the recovery plan is a document. With it, it is a control.

---

This article reflects my professional perspective and is general information, not legal or regulatory advice. Apply it in light of your organization’s obligations and risk appetite.