Organizations have spent years strengthening their backup infrastructure to protect against ransomware and other cyber threats. Maintaining copies of critical data is useful, but offers little assurance that applications and business operations can be restored after an attack. Recovery depends on the integrity of those copies, the systems that support them, and the organization's ability to execute restoration procedures under pressure.

Veeam's 2026 Data Trust and Resilience Report found that 90% of surveyed security leaders expressed confidence in meeting their recovery time objectives, but only 28% of organizations affected by ransomware fully recovered their data. Even when organizations have viable backups, the process of bringing applications and interconnected systems back online can expose complications that recovery plans have failed to anticipate.

Successful backups don't guarantee application recovery

Applications, databases, and supporting infrastructure evolve, creating dependencies that older backups may no longer satisfy. Christophe Pettus, CEO of PGX, encountered this problem when a client restored a database backup that was approximately a day old. The restoration itself succeeded, but database migrations completed during the intervening period hadn't been applied to the recovered environment. “They made a bad situation worse. First of all, they've lost data. And second of all, there was a day's worth of migrations that hadn't been applied,” he says.

Recovery testing must extend beyond confirming that data can be retrieved. Organizations also need to verify application compatibility, account for changes across interconnected systems, and establish how much information could be lost between recovery points.

Protecting backup data requires more than immutability

Reliable restoration also depends on preserving backup data against attackers who deliberately target recovery infrastructure. Ransomware operators may attempt to delete stored copies or compromise administrative accounts, leaving organizations without a viable recovery point.

Andrew Stone, CTO for the Americas at Everpure, distinguishes between data immutability and protection against deletion. "Immutability is simply once data is written, it can't be changed," he explains. That protection doesn't necessarily prevent someone with sufficient privileges from deleting the data altogether. To address this vulnerability, Stone describes protected snapshots that require additional authorization and a support process before they can be removed. “And then you have to have a special support process where peer support would come in and actually help delete data that needs to be deleted from the array,” he says.  These protections reflect a broader shift toward making enterprise storage an active component of cyber defense, integrating built-in security, threat detection, and coordinated response to protect data beyond backup integrity.

The focus on protecting data and controlling access also aligns with zero-trust principles, which call for continuous verification and limited privileges. Gerald Caron, CISO at Acronis, argues that these principles should extend across identities, applications, devices, networks, and data. "Reducing the attack surface and preventing the lateral movement is what zero trust has been all about," he says.

The underlying risks of backup contamination

Before restoration can begin, organizations should verify that their backup data hasn't already been compromised. Attackers can remain undetected in corporate environments long enough for malicious files or other evidence of compromise to reach backup systems. Restoring an affected copy could reintroduce the threat into an environment that security teams have just worked to secure.

Chris Patteson, Director of Cybersecurity, GRC, at a large pharmaceutical manufacturing organization, has encountered incidents in which recovery efforts brought malware back into affected systems. "I've seen examples where people have reinfected themselves. [...] You end up reinstalling the infection or the malware back on top of your system. So even your backups could be corrupted," he warns.

Identifying a trustworthy recovery point requires investigators to understand when the intrusion began, which systems were affected, and how far the compromise spread. Clean-room recovery environments can support that process by allowing teams to inspect backups and validate restored applications before reconnecting them to production systems.

The operational realities behind cyber recovery timelines

Recovery objectives often reflect the time required to restore infrastructure under controlled conditions. Actual incidents involve additional work, including containment, forensic investigation, and decisions about when restoration can safely begin.

Aurobindo Sundaram, CISO at RELX, highlights the difference between technical recovery performance and the time an organization may spend dealing with an incident. "The tested recovery time is quite different from the actual recovery time because there's an investigation you have to complete before you do that recovery," he explains. "Accuracy matters more than speed."

Business continuity remains the ultimate measure of cyber recovery

As organizations invest in cyber resilience, evidence of successful restoration is becoming as important as the backup infrastructure itself. Protected recovery copies, tested application dependencies, verified recovery points, and realistic operational exercises all contribute to that assurance. The measure of preparedness is ultimately how reliably an organization can restore the services its business needs after an attack.

"Can you take that backup, go and install it somewhere else, and run your business function?" asks Rick Orloff, VP and CISO at Everpure. "And how quickly can you do that?"