Ask a room of engineers whether they have backups and every hand goes up. Ask when they last restored a production system from one, end to end, with the network isolated and the people who normally do it on holiday, and the hands come down. That gap is where most ransomware recoveries are actually lost, and it has been visible in this archive for a decade.
The clearest illustration is not a failure but a success. In January 2017 the St. Louis Public Library lost about seven hundred computers across seventeen locations to ransomware and was asked for roughly thirty-five thousand dollars. It refused, wiped the affected servers, rebuilt from backup and was lending books again within days. Five months later, NotPetya put Maersk in the position of rebuilding four thousand servers and forty-five thousand PCs — a recovery that succeeded partly because one domain controller in Ghana had been offline during the attack. One of those organisations had rehearsed. The other was saved by a power cut.
Four properties, not one
"Do we have backups" is the wrong question because it collapses four separate properties into one word. A backup that fails any of them is a cost centre, not a control.
Reachable by you. If the backup system authenticates against the same directory the attacker now controls, it is not a backup, it is another target. Modern intrusions look for the backup console early and deliberately — Code Spaces was destroyed in a single day in June 2014 when an extortionist with the company's cloud console credentials deleted the instances, the snapshots and the backups together, and the business never reopened. Separate the credentials, separate the identity provider, and keep at least one copy that a compromised administrator account cannot delete.
Older than the intrusion. Dwell time routinely exceeds retention. If the intruder was inside for four months and you keep thirty days, every copy you hold contains them. Retention should be set against the dwell times in your sector's incident reports, not against storage cost.
Complete enough to run the business. Most restore plans cover databases and miss the things nobody calls systems: the certificate authority, the licence servers, the build pipeline, the spreadsheet on somebody's laptop that reconciles two systems that were never integrated. The test for completeness is not "is the data there" but "can we take an order".
Fast enough to matter. A restore that works but takes eleven weeks is an outcome, not a plan. Measure the real figure, on real hardware, with real data volumes, and give the board that number rather than the vendor's.
Four rehearsals worth scheduling
None of these requires new spending, and all of them can be done in a quarter. First, restore one tier-one system to isolated infrastructure and time it, with the usual owner unavailable — recovery documents written by the person who never needs them are the ones that turn out to be readable. Second, rehearse the case where the identity provider itself is gone, which is the scenario most runbooks quietly assume away. Third, verify that at least one copy is genuinely immutable by attempting to delete it with your most privileged account; a control nobody has tried to break is an assumption. Fourth, run the paper day — the hours before any system comes back, when the question is whether the business can operate at all. Hospitals rehearse this and rediscover, every time, that the answer depends on whether anyone still knows the manual process.
The organisations in this archive that recovered well were rarely the best defended. They were the ones for whom the bad day was not the first time they had done any of it. That is a scheduling problem more than a budget one, which is the good news, and it is why the rehearsal keeps slipping, which is the bad.