Recoverability Over Frequency: The Backup Standard That Matters

Modern ransomware attacks can target recovery infrastructure alongside production systems, putting backup repositories, administrative credentials, and other components of the recovery environment at risk. If attackers can encrypt, delete, or otherwise compromise those backups, an organization may discover during an incident that months of successful backup reports did not translate into a reliable path to recovery.

The consequences extend well beyond the IT team because delayed or unsuccessful recovery can interrupt operations, increase the financial impact of downtime, create regulatory and insurance concerns, and affect customer confidence. Organizations that want to be prepared for that scenario need to measure backup success differently, with greater emphasis on whether data is protected from the same threats targeting production and whether recovery has been tested well enough to prove that critical systems can be restored when the business needs them.

Backups were once treated as a safety net that could remain largely separate from the broader security conversation, but ransomware has made the recovery environment part of the attack surface. Veeam’s 2024 Ransomware Trends Report found that 96% of ransomware attacks targeted backup repositories, while Sophos reported attempted backup compromise in 94% of attacks, with 57% of those attempts succeeding globally and 66% succeeding in the United States.

There is a clear reason recovery infrastructure has become such an important target. An organization with protected, restorable backups has options after an attack, while one that loses access to its recovery data faces greater pressure to pay a ransom or accept an extended disruption. Compromising backups can therefore increase the impact of an attack by limiting the organization’s ability to restore systems independently. That changes what businesses should expect from their backup strategy. Creating a copy of critical data is not enough if an attacker who reaches the production environment can also modify, encrypt, or delete the backup. The more important question is whether that copy is sufficiently isolated and protected to remain available during an actual attack, and whether the organization has proven that it can use that data to recover.

Ransomware has changed the role backups play in a security strategy because attackers increasingly recognize that disrupting recovery can be as consequential as encrypting production systems. Veeam’s 2024 Ransomware Trends Report found that 96% of ransomware attacks targeted backup repositories, while Sophos reported attempted backup compromise in 94% of attacks, demonstrating how recovery infrastructure has become a deliberate part of the attack.

Recovery infrastructure has become an important target because protected backups give organizations a way to restore operations without relying on an attacker. When those backups are compromised, recovery becomes more difficult, disruptions can last longer, and the pressure to pay increases. By targeting the systems an organization depends on to recover, attackers can reduce the options available to the business when production systems go down.

That changes what organizations should expect from a backup strategy. A successful backup job confirms that a copy was created, but it does not prove that the copy will survive an attack or that critical systems can be restored from it. Backup readiness therefore needs to account for how recovery data is isolated and protected, as well as whether the organization has tested its ability to restore that data when production systems are unavailable.

Protecting a backup from ransomware requires more than creating another copy of the data. That copy also needs controls that prevent an attacker from changing it or reaching it in the first place, which is where immutability and isolation serve different purposes. Immutability prevents backup data from being altered, encrypted, overwritten, or deleted during a defined retention period, while isolation separates the backup from the production environment so an attacker moving through the network has a harder time reaching it. A resilient recovery strategy considers both because protecting a backup from modification does not necessarily mean it is sufficiently isolated from the systems under attack.

How those protections are implemented matters just as much as whether they are enabled. Immutability is strongest when it is enforced at the storage layer through controls such as object lock, hardened repositories, WORM storage, immutable snapshots, or tape. If the same administrative credentials or control plane can change both the backup configuration and its protections, an attacker who compromises that access may be able to undermine the recovery environment along with production.

The 3-2-1-1-0 rule brings these protections together in a practical framework for building greater resilience into the backup environment:

• 3 copies of your data so recovery does not depend on a single copy.
• 2 different media types to reduce the risk that one failure or compromise affects every copy.
• 1 copy stored off-site so a problem within the primary environment does not eliminate every recovery option.
• 1 copy kept offline, air-gapped, or immutable to protect recovery data from attackers who gain access to production systems.
• 0 recovery errors confirmed through testing, providing evidence that the backups can be restored when needed. 

The final zero is what turns the framework from a backup strategy into a recovery strategy. Multiple copies create redundancy, but recovery testing provides evidence that those copies are usable when the business needs them.

Consider a services firm that stores its second backup on an always-connected network drive managed with the same credentials as production. Although the backup report shows multiple copies, one compromised administrative account could potentially expose both environments. Separating the additional copy through an immutable repository with independent access controls creates another barrier between an attacker and the organization's recovery data. Both approaches create backups, but only one is designed around the conditions the organization may face when it needs those backups most.

The impact of a failed recovery extends across the organization, which is why backup resilience cannot sit solely within an IT checklist. ITIC’s 2024 research found that more than 90% of mid-size and large enterprises said a single hour of downtime exceeded $300,000, while 41% placed the cost between $1 million and more than $5 million. The cost of recovering from ransomware is also increasing independently of the ransom itself, with Sophos reporting an average recovery cost of $2.73 million, excluding ransom payments, compared with $1.82 million the previous year.

Regulatory and insurance requirements add another layer to that exposure. Frameworks such as the EU’s Digital Operational Resilience Act and New York’s DFS Part 500 emphasize outcomes that support stronger recovery practices, including data integrity, segregation, and tested restoration. Cyber-insurance underwriting may also examine whether critical backups are offline, air-gapped, or immutable, along with controls such as multi-factor authentication, retention settings, and evidence of restore testing. Together, these expectations make recoverability part of the organization’s broader approach to managing operational and compliance risk.

Ownership can become another weakness when backup and cybersecurity responsibilities are divided across teams. Veeam found that 63% of organizations believed significant improvement or a complete overhaul was needed in the alignment between their backup and cybersecurity teams. An organization can have capable IT and security functions while still lacking clear accountability for proving that critical systems can be recovered from end to end. Leadership should know who owns that outcome, how often it is tested, and what happens when a test identifies a gap.

Recovery planning also needs to account for what happens during a real investigation, when systems may not be immediately available for rebuilding. Veeam found that an average of 31% of infrastructure could not be immediately wiped and reused following an incident because of insurance, legal, or forensic requirements. Faster backups alone cannot solve that constraint, which is why recovery planning should consider where systems will be restored, what infrastructure may be unavailable, and how the business will continue operating while an investigation is underway.

Leaders do not need to become backup engineers to move this forward. They need to ask a small set of questions that surface whether recoverability is real or assumed:

• Can we restore a clean, uninfected copy if production, our administrators, and the backup console are all compromised at once?
• Is our immutability enforced by storage through object-lock or WORM, or only by application permissions an attacker could disable?
• When did we last perform a full recovery test that included application boot, database consistency, and identity recovery, and what was the measured time to resume?
• Who is accountable, by name, for proving recovery works, and does that role sit across both IT and security?

If those questions produce hesitation rather than evidence, the gap is identified. The most useful first action is a single realistic recovery test of a business-critical system, restored into an isolated environment, scanned for malware, booted, and timed against the recovery expectation the business depends on. That one exercise tends to reveal more about true resilience than months of green dashboards. For organizations without the internal bandwidth to run that test rigorously, bringing in a partner to design and execute it is often the fastest way to replace assumption with proof.

We approach ransomware resilience with a straightforward objective of ensuring organizations can recover when their primary environment is compromised. That means looking beyond whether backups are running and evaluating whether critical data is appropriately protected, isolated from production, and regularly tested against the recovery needs of the business.

Our work starts with the current recovery environment, including where backups are stored, how immutability is enforced, who can access them, and whether recovery has been tested under realistic conditions. From there, we help organizations identify gaps, prioritize systems based on business impact, and build a recovery strategy that reduces the chance that production and backup environments can be compromised through the same path.

Recovery is most effective when technology, security, compliance, and business continuity are considered together, so we approach it as part of the organization’s broader technology strategy rather than as a standalone backup project. As a long-term partner, we can help maintain that readiness through recurring recovery testing, ongoing review, and adjustments as systems and business requirements change. The goal is to provide evidence that the organization has a viable path to recovery when those backups are needed the most.