How regular recovery testing can strengthen cyber resilience
A mid-sized manufacturer gets hit by ransomware on a Friday night. By Monday morning, the IT director is standing in front of the leadership team explaining that the backups exist, but nobody can confirm they actually work. The restore job hangs at 40%. Nobody on the team has run a full recovery drill in over a year.
This scenario plays out at organizations of every size, and it points to a gap that most companies don’t realize they have until it’s too late. The difference between having backups and knowing those backups will actually bring the business back online.
For many organizations, strengthening cyber resilience means proving that critical systems can be restored when preventive controls fail. Regular recovery testing provides that proof by showing whether backups are usable and whether recovery procedures can bring essential operations back online within an acceptable timeframe.
Recovery testing can expose false confidence
Ask most security leaders whether their organization can recover from a cyberattack, and the answer is usually yes. Veeam’s Data Trust and Resilience Report 2026 found that 90% of organizations express confidence in their ability to recover from a cyber incident. This was based on responses from more than 900 senior IT, security and risk leaders worldwide.
However, the actual outcomes tell a different story. Among organizations that got hit by ransomware, only 28% fully recovered all affected data, and 44% recovered less than 75% of it. Average recovery landed around 72% of what was lost. That gap between belief and outcome shows up again and again in industry research.
That is exactly where recovery testing becomes useful. A written plan can show what should happen after an attack, but only a realistic test can show whether systems can actually be restored within the time the business expects.
Consider an organization that assumes it can recover a critical customer platform within four hours. During a test, the security team discovers that finding the correct backup already takes close to two hours. The restore then takes longer than expected because one supporting service has to be rebuilt first. On paper, the four-hour target still looks achievable. In practice, the test shows that the organization is not ready to meet it.
Regular recovery exercises help replace assumptions with evidence. They reveal whether backups are complete, whether recovery procedures still match the current environment and whether staff can carry them out under pressure. They can also uncover dependencies that were never obvious during routine operations.
Testing reveals dependencies that recovery plans often miss
Recovery plans often focus on individual systems, but business services rarely operate in isolation. A database may restore successfully while the application that depends on it remains unavailable because an identity service has not yet been recovered. In another case, a customer platform may come back online but fail to process transactions because a supporting network configuration was overlooked.
These dependencies are difficult to spot from documentation alone. A realistic recovery test shows how systems behave when restoration begins and which services must return first for the wider business process to work.
For example, a company may believe that it can restore its payroll system within a few hours. During a test, the team could discover that employees still cannot access it because authentication depends on another service that takes much longer to recover. Even if the payroll backup itself is fine, the business outcome still is delayed.
But with regular testing, these hidden connections come to light before they can become a problem during an actual attack. Teams get a clearer picture of how long it actually takes for recovery to complete. Also, you can tell whether the existing recovery time objectives are realistic or not.
This matters because IT environments change constantly. A cloud migration, application update or new integration can introduce dependencies that were not present when the original recovery plan was written. Testing keeps recovery procedures aligned with the systems the organization actually uses rather than the environment it had months ago.
What tested recovery actually buys an organization
The payoff for closing that gap shows up in hard numbers. Sophos’s 2025 State of Ransomware report, drawn from 3,400 organizations across 17 countries, found that 53% of victims fully recovered within a week, up sharply from 35% the year before. Also, the average recovery costs fell 44%, from $2.73 million to $1.53 million over the same period.
The researchers attribute much of that improvement to organizations investing in tested, immutable backup systems that let them restore operations without rebuilding everything from scratch.
Speed matters on the broader breach side too. IBM’s 2025 Cost of a Data Breach Report, based on more than 600 organizations, found the average breach lifecycle dropped to 241 days in 2025. This comprised 181 days to identify and 60 days to contain. Interestingly, this is the shortest span in nine years. Breaches that took longer than 200 days to contain cost $1.14 million more than those resolved faster.
IBM’s own recommendations for reducing both cost and containment time included planning and testing incident response processes regularly to build organizational resilience.
A recovery plan is only as strong as its last successful test. Regular recovery exercises show whether backups, systems and teams can perform when disruption becomes real. By uncovering weaknesses before an attack does, organizations can reduce downtime, restore services faster and build resilience based on evidence rather than assumption.
