Most organisations have a ransomware recovery plan on paper. Restore from backups. Rebuild affected systems. Notify the ICO within 72 hours. On paper, it looks reasonable. In practice, the plan falls apart within the first hour of an actual incident.
The fatal flaw in most recovery plans is a simple one: nobody tested them. Backup restoration has never been verified end to end. The documented recovery procedures reference systems that were decommissioned two years ago. Key personnel listed in the plan have changed roles. The contact details for your incident response provider are out of date.
Where Recovery Plans Fail
Backup integrity is the most common failure point. Organisations configure automated backups and assume they work. Ransomware operators know this. Modern strains specifically target backup systems, encrypting or deleting shadow copies, snapshot repositories, and backup agents before deploying the main payload. If your backups connect to the same network as your production systems with the same credentials, the attacker encrypts both.
Recovery time expectations also tend to be wildly optimistic. Restoring terabytes of data from cloud or tape storage takes days, not hours. Rebuilding Active Directory from scratch after a domain controller compromise can take a week. Meanwhile, every hour of downtime costs money and reputation.
William Fieldhouse, Director of Aardwolf Security Ltd, comments: “The organisations that recover from ransomware quickly share two traits. They test their backup restoration quarterly, including full system rebuilds. And they maintain offline or immutable backups that ransomware cannot reach. Everything else in the recovery plan is secondary to those two fundamentals.”
Preventing the Need for Recovery
Prevention remains cheaper than recovery. Regular vulnerability scanning services identify the exposed services and missing patches that ransomware operators use for initial access. Closing these gaps before an attacker finds them eliminates the most common entry points.
Conduct internal network penetration testing to assess whether an attacker who gains initial access could reach your backup infrastructure, domain controllers, and critical servers. If a tester can pivot from a compromised workstation to your backup server, so can a ransomware operator.
Building a Plan That Works
Test backup restoration every quarter. Include full system rebuilds, not just file-level restores. Maintain at least one backup copy that is physically or logically isolated from your production network. Document your recovery procedures based on tested outcomes rather than theoretical assumptions.
Communication plans collapse under pressure too. When systems are encrypted and email is unavailable, how does the incident response team coordinate? Pre-established out-of-band communication channels, whether that means a dedicated messaging platform, personal mobile numbers in a printed contact list, or even a group chat, prevent the chaos that derails early response efforts.
Insurance policies often require evidence of specific recovery capabilities. Cyber insurers increasingly ask whether backup restoration has been tested and how long recovery actually takes. Providing honest, tested answers rather than optimistic estimates strengthens your policy position and avoids disputes during a claim.
A recovery plan that has never been tested is a document, not a defence. Test it, fix the gaps, and test it again. When ransomware strikes, the difference between a manageable incident and a business-ending catastrophe comes down to preparation.
