You do not have a recovery plan until you have run it

Every organization we assess says the same two things: we have backups, and we have a disaster recovery plan. Both statements are usually true, and neither answers the question that matters. Could you actually recover, cleanly, inside a window the business can survive?

A backup job that reports success proves one thing: data was copied somewhere. It says nothing about whether the restore path works, whether anyone still has the access to run it, whether the systems come back in an order that lets the application start, or whether the copy you’d reach for is itself encrypted by the thing you’re recovering from. Those questions have answers. Most organizations simply haven’t looked them up.

The difference between a plan and a rehearsal

A plan is a document describing what people intend to do. A rehearsal is a measurement of what actually happens when they try.

The gap between them is consistently larger than anyone expects, and it is not because the plan was written carelessly. It’s because a recovery touches every assumption an environment has accumulated — identity, DNS, secrets, network paths, license servers, the one service that was stood up by hand in 2023 and never written down. Documents don’t test assumptions. Running the thing does.

The first rehearsal at most organizations produces the same short list of discoveries:

• Access. The person who owns the restore credentials has changed roles, MFA is bound to a device that’s gone, or the break-glass account’s password is in a vault that’s inside the environment being recovered.
• Order. Systems come back, but not in a sequence that works. Identity has to precede the application; the database has to be reachable before the app tier stops crash-looping; DNS has to point somewhere real before anyone can test any of it.
• Undocumented state. A configuration change made in a console during an incident two years ago, never reflected in code, silently load-bearing ever since.
• Rate. The backups restore, but at a throughput that turns a stated four-hour RTO into thirty. Nobody had multiplied the data volume by the actual restore rate.
• Scope. The database was backed up. The message queue’s durable state, the secrets store, and the object-storage bucket the application writes to were not.

None of these are exotic. All of them are cheap to fix once found, and expensive to find during an actual outage.

What a real rehearsal requires

An isolated target. Restore into a separate environment, not over the top of production. This is the single thing that makes rehearsals safe enough to do regularly — and it’s also what makes them honest, because restoring into a running environment lets you accidentally borrow the pieces you forgot to back up.

A clock. Start it when the decision to recover is made, not when the first command is typed, and stop it when the application actually serves a real transaction. The number you get is your true RTO. It is usually not the number in the plan.

Recovery from the backup, not from production. Cloning a live system proves you can clone a live system. The scenario worth rehearsing is the one where the live system is gone or untrustworthy.

A defined data-loss target. Note the timestamp of what you actually recovered. The distance between that and the incident is your real RPO, and it is the number your business owners actually care about, whether or not they use the acronym.

A written record. What broke, what it cost in minutes, who fixed it, what changed as a result. Three of these on a shelf is the most persuasive security artifact a small organization can own — with auditors, with insurers, and in the board conversation where someone asks whether the last budget line did anything.

Ransomware changes the shape of it

Ordinary DR assumes the infrastructure failed. Ransomware assumes the infrastructure is hostile — and that changes three things.

Your backups are a target, not a refuge. Modern intrusions look for backup infrastructure early and deliberately, because encrypting or deleting the copies is what converts an outage into a payment. Backups need to be genuinely out of reach of the credentials that run the environment: separate account or tenancy, immutability windows, and restore paths that don’t authenticate through the compromised identity provider.

You cannot restore into the crime scene. If the intrusion path is still present — a persistent implant, a valid stolen credential, a poisoned image — restoring into that environment simply re-infects the restored data, sometimes within hours. Recovery has to land somewhere clean: a fresh environment, built from a known-good definition, into which data is reintroduced deliberately and checked before anything is connected to the outside world.

The original is evidence. Insurers, regulators, and any credible investigation need the compromised environment preserved. That conflicts directly with the operational instinct to tear it down and rebuild, so the hold needs to be a decision made in advance, not an argument held at 2am.

This is why “rebuild from the definition into isolation” is the pattern we build toward: when your environment exists as reviewed code and a recorded as-built, standing up a clean replica is a routine operation rather than a heroic one — and the compromised original can sit untouched under a forensic hold while it happens.

A cadence that survives contact with reality

Annual full-scale DR exercises are common, expensive, and frequently postponed into nonexistence. Smaller and more often beats bigger and aspirational:

• Quarterly, restore one tier-one system into an isolated environment and time it end to end.
• Semi-annually, rehearse the ransomware variant: recover with the assumption that the production identity plane and the primary backup path are both untrusted.
• On every material change, ask whether the new component is in the backup scope. New data store, new queue, new secrets location — that is the moment it’s cheapest to answer.

Scope each exercise so it fits in a day. The organizations that recover well aren’t the ones with the thickest plan; they’re the ones for whom the recovery is boring, because they’ve done it before.

Start with the honest questions

If you want a fast read on where you stand, our Ransomware Recovery Readiness Checklist is a printable page — no email wall, no form. It’s the same set of questions we walk through in an assessment, and it’s designed so you can go through it with your team in under an hour and come out with a short list of things you can’t currently answer.

Those unanswerable items are the plan. Everything else is documentation.