Your Backups Are a Hypothesis: Lessons from Ransomware Simulations

The untested assumption

Ask a leadership team whether they can recover from ransomware and the answer is almost always yes — 'we have backups.' Backups you have never restored under pressure are not a control; they are a hypothesis. The simulation exists to test it before an operator does.

We run these safely: benign payloads that mimic ransomware behavior across the kill chain, with encryption routines that only ever touch planted test files. The goal is never to damage data — it is to measure prevention, detection, and above all recovery, honestly.

How operators reach the backups

Modern ransomware crews do not encrypt on day one. They spend time finding and neutralizing recovery first, because an organization that can restore does not pay. That makes the backup plane a primary target, not an afterthought.

The recurring weaknesses are predictable: backup service accounts with sprawling privileges, management consoles reachable from the ordinary network, and shadow copies an attacker can simply delete. If the same admin identity can both run production and destroy backups, the backups are inside the blast radius.

The restore nobody timed

The most sobering number in these exercises is time-to-restore. Teams quote a recovery-time objective from a policy document; the simulation measures the real one, and the two are often far apart.

The gap usually is not the backups themselves — it is everything around them: unclear restore order, dependencies discovered mid-recovery, credentials stored only in the systems being restored, and runbooks that assume a calm afternoon rather than a crisis.

Detection was never the whole story

Strong detection helps, but ransomware resilience is ultimately about what happens after prevention fails. An organization that detects late but recovers fast survives; one that detects early but cannot restore still suffers a very bad week.

So we score the whole chain — prevention, detection, response, and recovery — and weight recovery heavily, because it is the control most often assumed and least often exercised.

Designing for the bad day

The resilient pattern is consistent: at least one immutable or offline copy of critical data outside the reach of production credentials, an isolated recovery environment you can rebuild into, and a restore process that has actually been walked end to end.

Pair the technical test with an executive tabletop so the decision-makers rehearse their side of the incident too. The organizations that handle ransomware well are not the ones that were never hit — they are the ones that had already practiced the bad day.