Most ransomware recovery plans are backup plans. They answer one question, “can we restore?”, and skip the three that decide how long you are down: what do we restore first, from what point in time, and who decides?
Those are business decisions, not technology decisions. And most organizations have not made them.
We hear it at the end of almost every ransomware tabletop exercise we run. One program leader put it plainly: “We don’t know when we can recover what, in what order.” Another described their cyber recovery readiness this way: “How far back we can go, how safe it would be, how fast we can do it. We don’t know any of that.”
If that sounds like your organization, your ransomware recovery plan is not finished.
Why Backups Alone Do Not Make a Ransomware Recovery Plan
Backups are necessary. They are not a plan. Here is where backup-centric plans break down in a real event:
- You cannot restore everything at once. Restoration capacity, people, and bandwidth are finite. Something goes first, and something waits days.
- Systems depend on other systems. An application restored before identity, DNS, and network services are trustworthy will not run, or will run on a compromised foundation.
- The clean restore point is unknown. Attackers often sit inside a network for days or weeks before they encrypt anything. The most recent backup may already contain them.
- IT tiers do not match business priorities. The system IT labeled “Tier 1” years ago may not be what keeps your company in business this week.
- Nobody pre-decided the trade-offs. Accepting data loss, restoring before forensics finish, or bringing customers back on a reduced service all need an executive decision. In the moment, those decisions stall.
| Old View | New View |
| Ransomware recovery is an IT problem | Ransomware recovery is a sequence of business decisions IT executes |
| Immutable backups mean we can recover | Immutable backups mean we have something to recover from |
| Restore the most recent backup | Restore the most recent clean backup, and decide in advance what data loss you accept |
| Our DR tiers tell us what comes first | Our minimum viable company tells us what comes first |
| We will figure out the order during the incident | We decided the order before the incident and tested it |
Five Decisions Your Ransomware Recovery Plan Must Make in Advance
This is how we think about building the business layer of a ransomware recovery plan. Each decision belongs to a named owner, and each one is made before the attack, not during it.
1. Define your minimum viable company
Start with the smallest set of business services that keeps the company in business: taking orders, paying people, serving customers, meeting regulatory obligations. That set is your minimum viable company.
Your Business Impact Analysis (BIA) should feed this list. If the BIA is out of date, the list will be wrong, and the recovery order built on it will be wrong too.
Get your executives to agree to the list now. During an incident, every executive believes their system is the critical one.
2. Map what is tied to what
For each service in your minimum viable company, map the dependencies all the way down: the applications, the data, the integrations, the third-party services, and the foundation underneath them. Identity (usually Active Directory or its cloud equivalent), DNS, networking, and security tooling sit under nearly everything.
Map from the business service down, not from the server up. Application dependency mapping that starts with an asset inventory produces a list of servers. Mapping that starts with a business service produces a recovery order.
This is where most programs we assess have the biggest gap. The knowledge exists, but it lives in a few engineers’ heads. “We can’t figure out what is tied to what” is a discovery you want to make in a conference room, not on day two of an outage.
3. Write the recovery order as a sequence
A tier list says what matters. A sequence says what happens first, second, and third, and what has to be true before each step starts. A credible sequence usually runs in three phases:
- Restore a trusted foundation: clean identity, network, and the security tools you need to watch the environment as it comes back.
- Restore the minimum viable company, in dependency order, validating each service before the next one starts.
- Restore everything else, in priority order, as capacity allows.
Put estimated durations against each step. When your executives ask “when will we be back?”, the sequence is the answer.
4. Decide how far back you are willing to go
Your recovery point objective (RPO) assumed a clean backup. Ransomware breaks that assumption. Decide in advance, service by service:
- How much data loss the business can accept if the most recent clean backup is a week old, not an hour old.
- How you will validate that a restore point is clean before you build on it.
- Who has the authority to accept the data loss, and how affected customers, regulators, and partners will be told.
5. Decide who decides
The hardest ransomware recovery decisions belong to executives, not engineers. Name the decision-maker in advance for each one:
- When to begin restoring while forensic investigation is still underway.
- Whether to accept data loss to restore faster.
- Whether to bring customers back on a reduced service.
- How to handle the ransom demand, together with legal counsel, your insurer, and law enforcement.
Pre-authorize what you can. A decision made in a calm room on a quiet Tuesday is better than the same decision made at 3 a.m. after two days without sleep.
Test the Order Before You Need It
A ransomware recovery plan that has never been exercised is a hypothesis. Test it two ways.
A tabletop exercise that reaches recovery. Most ransomware tabletops spend their whole time on detection, escalation, and the first public statement. Teams leave saying, “If we’d had another hour, we would have gotten to recovery.” Design the exercise so it gets there. (If you are hiring outside help, here is how to choose a tabletop exercise facilitator.)
A technical recovery test. Restore part of the minimum viable company, in sequence, in an isolated environment. Time it. The gap between the estimated and the actual duration is your most useful finding.
Common Failure Modes
- The order lives in one person’s head. If your recovery sequence depends on a single engineer being reachable, it is not a sequence.
- The minimum viable company was never agreed. IT built the order; the business never signed it.
- Third parties were left out. Your recovery depends on vendors whose own recovery you have never tested.
- The plan assumes the backups are clean. No step validates the restore point.
- The people were forgotten. Recovery takes days or weeks of sustained effort. One chief information security officer told us their biggest concern was “people not being able to sustain an extended period of time.” Plan shifts and relief before you need them.
Where to Start This Quarter
- Get your executives to name the minimum viable company in a 60-minute working session.
- Map dependencies for one service on that list, end to end, and write its recovery sequence with estimated durations.
- Run a tabletop exercise designed to reach recovery, and use what it finds to build the rest of the sequence.
If your team does not have the time or hands to do this alongside its day job, our IT disaster recovery consulting team maps dependencies, defines recovery sequencing, and tests recovery in the real world. Resilience as a Service runs the same work as part of your ongoing program. For the response side of ransomware, see building your ransomware playbook.
Backups give you something to recover from. The plan tells you what to recover first.
Keep Going
A few ways to go deeper if this was useful.
- Read more. Resilience, crisis management, and continuity writing at Bryghtpath Insights, or the structured Ultimate Guide to Business Continuity.
- Test your recovery order. Exercise in a Day® builds and runs a custom ransomware tabletop in one day, designed to reach recovery.
- Get a maturity score. Our Resiliency Diagnosis® is a standards-based review that produces a maturity score and a prioritized roadmap.
- Talk to us. Set up a call to think through your recovery sequence with us.




What a Business Continuity Maturity Assessment Should Tell You (and What an Audit Won’t)