82% of Backup Systems Have Automated Testing Switched Off. Most Teams Find Out During the Attack.

A green checkmark on a backup dashboard confirms exactly one thing: a job completed. It says nothing about whether that copy is complete, recent, or able to actually bring a system back online. Most companies only learn the difference between "backed up" and "recoverable" during a live incident, which is the single worst moment to find out.

Recent platform telemetry puts a number on how widespread this gap is: 82% of disaster recovery setups have automated restore testing set to "never," with only 18% configured for even monthly tests. 85% of recovery servers have RPO monitoring disabled entirely, meaning there's no automatic check on whether backups are even current. If a backup job silently stops running, nobody is told. The first sign is usually discovered during an actual failover, when the newest available copy turns out to be days or weeks old.

92% of organizations report having backups in place. Despite that, 31% still fail to recover their data when ransomware actually hits. Over half of businesses test their disaster recovery plan once a year or less, and a third test infrequently or never at all.

There's a wider version of this same gap in how organizations perceive their own readiness. One industry survey found 69% of businesses believed they were well prepared to respond to ransomware before an attack occurred. When an attack actually happened, only 22% recovered within 24 hours. That 47-point gap between confidence and reality tends to belong to organizations with a written incident response plan that was never actually tested under pressure. Separately, 60% of organizations believe they can recover within hours of an incident, but only 35% actually do.

Modern ransomware doesn't just encrypt production data. It goes after the backups first, on the logic that a working restore is the one thing that lets a victim refuse to pay. Veeam's ransomware research has repeatedly found that backup repositories are targeted in the large majority of attacks, and Sophos's own 2025 survey of 3,400 organizations found that reliance on backups to restore encrypted data has fallen to a four-year low, with several respondents pointing to reduced confidence in whether their backups would actually still be there and usable after an attack.

The financial difference this makes is stark. Organizations that kept their backups intact through an attack had a median recovery cost of roughly $375,000. Organizations whose backups were also compromised faced a median cost closer to $3 million, an eightfold difference driven almost entirely by whether the backup itself survived and could be trusted.

Most disaster recovery plans were designed with outages in mind, not adversaries. They quietly assume production systems are clean, identity services are intact, and the recovery environment can be trusted. An active ransomware incident breaks all three assumptions at once, which is exactly why recovery procedures that were never tested under realistic attack conditions tend to fail precisely when they're needed.

The CDK Global attack in June 2024 is a useful illustration of how far downstream this gap can reach. A single ransomware attack against one software vendor paralyzed operations at more than 15,000 automotive dealerships for weeks, with downstream losses across the industry estimated at over a billion dollars, not because any individual dealership lacked backups, but because the recovery path for a supply-chain-adjacent system took far longer than anyone had planned for.

Sophos's State of Ransomware research found average recovery costs actually dropped 44% between 2024 and 2025, a trend attributed largely to organizations investing in tested, immutable backup infrastructure rather than rebuilding from scratch. But that improvement isn't evenly distributed: small and mid-sized businesses with 100 to 250 employees still face average recovery costs approaching $640,000 excluding any ransom payment, a figure that can be existential for an organization with limited cash reserves.

Some environments make untested recovery even riskier by design. Industrial control systems and operational technology networks, the systems that run production lines, PLCs, and SCADA equipment, often can't be restored from IT-style backups at all. When ransomware spreads from IT into OT, recovery can mean rebuilding control system configurations from scratch, halting physical production for weeks rather than hours.

This is also why the classic 3-2-1 backup rule (three copies, two media types, one offsite) is increasingly treated as necessary but not sufficient. Industry guidance has shifted toward 3-2-1-1: the same three copies and two media types, plus one copy that is genuinely immutable, meaning it cannot be modified or deleted by anyone, including an attacker who has obtained administrative credentials, for a defined retention window.

The uncomfortable truth in most of this research is the same: a "successful" status on a backup dashboard doesn't rule out missing file permissions on the restored data, broken application dependencies that stop the software from actually running, or a recovery time far outside your defined RTO. All three of those failure modes only surface once someone actually attempts a restore, which is precisely the step 82% of setups skip.

Closing that gap doesn't require new backup software. It requires proof: an inventory of what's actually protected, immutable and geo-redundant copies that can't be altered even if an attacker gets administrative access, a written disaster recovery plan mapped to real ransomware and breach scenarios, and a recurring, timed test restore that confirms the recovered system boots and the data opens within your recovery-time target, not just that the backup job finished.