Why ransomware makes backups the target, not the safety net
For years, backup was the exception that made ransomware survivable: encrypt production, restore from backup, move on. Attackers have caught up. Veeam's 2025 Ransomware Trends report surveyed 1,300 organizations, 900 of which had suffered at least one ransomware attack in the previous 12 months. Veeam reports that 89% of organizations had their backup repositories targeted by the attacker, and that on average 34% of backup repositories were modified or deleted. Destroying or corrupting the fallback removes the victim's leverage before the ransom note ever arrives.
The result shows up in the recovery numbers. Sophos's State of Ransomware 2025 surveyed 3,400 IT and security leaders whose organizations were hit by ransomware in the previous year. Among the organizations whose data was encrypted, only 54% restored it using backups, the lowest rate in the six years Sophos has run the survey. Of the 151 organizations that ended up paying more than the attacker's initial demand, 38% said their backups had failed or were malfunctioning (respondents typically cited two reasons). A backup that exists on paper is not the same thing as a backup that restores cleanly under pressure.
That gap, between "we have backups" and "we have ransomware-resilient backups", comes down to three pillars: immutability, isolation, and tested recovery. They are not independent controls you can mix and match. Miss any one of them, and the other two do not compensate. An immutable backup an attacker cannot reach is only useful if it actually restores, and a well-tested restore plan is worthless if the backup it depends on was deleted before the drill ever started. The three pillars sit inside a wider set of controls, from identity to monitoring, covered in What is backup security?
The three pillars, in full
1. Immutability: backups an attacker cannot touch
Immutability means a backup cannot be altered or deleted within its retention window: not by a misconfigured retention script, not by a compromised administrator account, and not by an attacker who already holds domain admin credentials. In practice it is enforced through Object Lock on object storage, Write Once Read Many (WORM) hardware, or a hardened Linux repository with retention enforced at the storage layer, independent of the backup application's own access controls.
The distinction matters because ransomware operators go looking for backups they can reach with stolen credentials. CISA's #StopRansomware Guide says so directly: "Ransomware actors often hunt for and collect credentials stored in the targeted environment and use those credentials to attempt to access backup solutions." If the same administrative account that manages your backup software can also delete last month's restore points, immutability is not actually in place. It is a setting a sufficiently privileged attacker can turn off in minutes.
CISA's own backup advice is to "maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario." The same guide is cautious about immutable cloud storage on its own: "Use immutable storage with caution as it does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost." Immutability is a strong control. It does not replace an offline copy or a tested restore.
2. Isolation: a separate identity plane, and a copy attackers cannot reach at all
Immutability protects a backup from being changed. Isolation protects it from being reached in the first place. The two are complementary, not interchangeable, and enterprises that implement only one tend to discover the gap during an actual incident rather than during a design review.
Isolation has two components. The first is a separate identity plane: backup infrastructure should not trust the same Active Directory domain, the same administrative credentials, or the same flat network segment as production. A compromised domain controller should not automatically mean a compromised backup environment; if it does, the attacker only needed to compromise one thing, not two. The second is a genuinely offline or air-gapped copy: at least one copy of critical data that has no standing network path from production at all. That can be offline tape rotation, a disconnected replication target that is only briefly online to receive data, or a cloud tier with no persistent credentials cached anywhere reachable from the production estate.
Veeam's 2025 report says that organizations that prioritize data resilience "can recover from attacks up to seven times faster and experience significantly lower data loss rates." Veeam credits data resilience as a whole (backup and recovery, proactive security, incident response), not isolation alone. Isolation is still a large part of the picture: it is the difference between an attacker who has to do real additional work to reach your recovery point, and one who already has a session open to it because it shares an identity plane with the systems they just compromised.
3. Tested recovery: proving restorability before you need it
The least glamorous of the three pillars is also the easiest to leave half-done. In Veeam's 2025 report, 98% of respondents had a ransomware playbook, but only 44% had included backup verifications and frequencies in it. Veeam's 2024 Ransomware Trends report, based on 1,200 organizations hit by at least one attack in 2023, found that 63% of organizations were at risk of reintroducing infections while recovering, because teams under pressure to restore quickly skip steps such as rescanning data in quarantine.
Untested restores fail in ways that stay invisible until the moment they matter most: broken backup chains, missing application-consistency dependencies, service-account credentials that expired months earlier, or runbooks written for an infrastructure topology that no longer exists. Skipping integrity and malware scanning carries a sharper risk than downtime: restoring the same payload that caused the outage in the first place.
A genuine tested-recovery program means scheduled, full restore drills into an isolated recovery environment, not just "backup job succeeded" notifications. Measure those drills against the RTOs the business actually needs, not figures that merely look reassuring in a slide deck. Our RTO vs RPO guide shows how to set those targets from a business impact analysis and test them against a real restore.
What the recovery numbers actually say
Sophos's 2025 data has a headline that looks reassuring: 97% of organizations that had data encrypted were able to recover it. The breakdown is less comforting. Just over half (54%) restored from backups, 49% paid the ransom and got data back, and 29% used other means; many used more than one route. Getting data back and getting it back from your own backups are different outcomes. The distance between the two is where weak pillars show up: a retention lock that the wrong role could override, a "separate" backup network that still trusted the same domain, or a restore that had never been rehearsed end to end.
The cost of getting this wrong
The three pillars are not an abstract best-practices checklist. They map directly onto how much a ransomware incident costs and how long it lasts. Sophos's 2025 report puts the average cost to recover from a ransomware attack, excluding any ransom paid, at $1.53 million, down from $2.73 million in 2024. 53% of victims were fully recovered within a week, up from 35% a year earlier. The rest spent longer than seven days in some state of disruption, with downtime, lost productivity, and incident-response labor adding up daily.
Backup posture is one of the few variables in that equation an organization fully controls. Whether an attacker's opening move against your backup repository succeeds or fails is decided largely by choices made months earlier, not during the incident itself. By the time a threat actor has domain admin credentials and is probing for your backup platform, immutability, isolation, and tested recovery are either already in place or they are not; there is no opportunity to retrofit them under pressure.
Common mistakes that quietly undermine all three
A handful of patterns show up repeatedly in post-incident reviews:
- Confusing snapshots for backups. A VMware snapshot is a change log of the original virtual disk, not an independent copy. Broadcom's snapshot best-practices article is blunt: "Do not use VMware snapshots as backups." The snapshot file keeps growing the longer it is kept, which can fill the datastore and hurt performance, and if the base disks are lost, "the snapshot files alone are not sufficient to restore a virtual machine." Snapshots are a convenience feature for short-lived rollback (Broadcom advises keeping a single snapshot no more than 72 hours), not a recovery strategy.
- Treating "immutable" as a checkbox rather than a verified property. Object Lock and retention policies must be tested against the exact administrative role that manages the backup platform, not just documented in a configuration guide.
- Calling a second copy in the same identity domain "isolated." If the same credentials that were compromised in production can authenticate to the backup repository, geographic or platform separation does not provide real isolation.
- Measuring success by backup completion, not restore verification. A green checkmark on last night's job tells you data was written somewhere. It does not tell you that data is retrievable, application-consistent, and free of the malware that necessitated the restore in the first place.
Where BackupSec Comes In
BackupSec does not replace your backup platform. Three of our services map onto the pillars above:
- ZeroMON monitors Veeam Backup & Replication. It runs on-premises as an OVA, connects with a read-only account, and sends nothing to BackupSec or any third party. It tracks job health, records configuration changes in its Forensic & Audit module (who changed what, and when), runs a Security Analyzer checklist, produces reports, and alerts by email and in-app notification. It shows each repository's immutability status as Veeam's own repository settings report it and flags when that setting changes. It reads Veeam's configuration; it does not verify object-level locks on the storage itself.
- ZeroTAM is a dedicated backup-security advisor, not software: architecture and isolation design, capacity planning, ransomware recovery planning, and priority support during a crisis.
- ZeroPEN is a threat-led penetration test of Veeam Backup & Replication, Veeam ONE, and Enterprise Manager. It simulates a ransomware kill chain mapped to MITRE ATT&CK in eight stages: initial access, discovery and inventory, credential abuse, Veeam server compromise, repository access, backup neutralization, exfiltration simulation, and proof of encryption capability. It never deletes real backups, performs real encryption, or stops production or backup services. You get audit-ready evidence, and critical findings are retested. The engagement also includes restore-integrity and immutability verification. It is a point-in-time test, so the regular restore drills in pillar 3 still need to run.
Talk to BackupSec about your backup security posture →
Want to see how your own backups would hold up? The free Backup Security Assessment asks 28 questions across seven areas, from backup strategy and access control to recovery testing.