Why 90% of ransomware recovery plans fail their first real test

The uncomfortable truth about most enterprise ransomware plans is that they are written to satisfy an auditor, not an attacker. The document lists RTOs, RPOs and vendor contacts, gets a signature from the CISO, and then sits untouched in a governance folder until the day it is needed, which is, without exception, the worst possible day to open it for the first time. The plan that looked airtight in the boardroom starts to fray within the first thirty minutes of a real incident, and the gap between the paperwork and the practice becomes the single largest driver of downtime.

The problem

When we reconstruct failed recoveries after the fact, three patterns show up almost every time. Backup jobs were succeeding in the console but capturing data that was already encrypted, because the malware had been resident for weeks before detonation. Restore paths depended on identity systems, domain controllers, MFA providers, secrets vaults, that were themselves offline or compromised, leaving engineers unable to authenticate into the very tools they needed to recover. And the runbook assumed a fully staffed engineering bench available at 03:00 on a Sunday of a long weekend, which no organisation actually fields. The cost of these gaps is not theoretical: the average enterprise ransomware event in India now runs past seven business days of degraded operations, and the reputational damage compounds every hour past the first.

What actually works

A recovery plan that holds up under real pressure is built on a small number of non-negotiable practices. First, immutability at the storage layer, backup targets that cannot be modified or deleted by any credential, including the backup service account itself, for a defined retention window. Second, a clean-room recovery environment that is fully isolated from production identity, network and DNS, so the restore process cannot be re-infected by the very systems it is meant to replace. Third, a quarterly full-restore drill executed end to end by a rotating on-call engineer who has never touched the runbook before, not the author, not the architect, a real stranger with a laptop and the document. Fourth, a defined command structure with named decision-makers for ransom, disclosure and customer communication, rehearsed as a tabletop at least twice a year.

The metric that matters is not the size of the runbook or the number of vendor logos on the incident-response retainer. It is time-to-known-good-restore, measured against a live drill, published to the executive team, and shrunk every quarter. If your last full restore was more than 90 days ago, you do not have a tested plan, you have a document that describes one.

How AMSTAG approaches this

Our cybersecurity practice treats ransomware readiness as an operating discipline, not a product line. Every account we run starts with a live restore drill inside the first 60 days, executed by an engineer who did not design the environment. We rebuild the runbook against what actually happened during the drill, not what was supposed to happen. Then we schedule the next drill, and the next, until the time-to-known-good-restore is a number the CFO recognises and the board can defend. That is the difference between a plan that passes audit and a plan that survives an incident.