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. In Veeam's 2025 Ransomware Trends survey of 1,300 organizations that had been hit, 89% had their backup repositories targeted as part of the attack — not as an afterthought, but as a first-class objective in the kill chain. Destroying or corrupting the fallback before encrypting production is now standard operating procedure, because it 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 report found that only 54% of organizations used backups to restore data after an attack — the lowest rate in the six years the survey has run. Among organizations that ended up paying more than the attacker's original demand, 38% cited failed or malfunctioning backups as the reason they had no better option. 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, 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 the attacker who has already obtained domain admin credentials. In practice it is enforced through object lock on cloud or object storage, Write Once Read Many (WORM) hardware, or a hardened Linux repository with retention locks enforced at the storage layer, independent of the backup application's own access controls.
The distinction matters because modern ransomware operators actively hunt for backup repositories reachable with production credentials and delete or encrypt them first, before touching primary data. 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 ransomware guidance is explicit on this point: maintain offline, encrypted, immutable backups, verify them regularly, and treat them as the last line of defense rather than the first thing an attacker has to defeat.
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 minimum one copy of critical data that has no standing network path from production at all, whether achieved through 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 research found that organizations prioritizing this kind of layered, isolated resilience recover from ransomware attacks up to seven times faster than those that do not, with materially lower data loss along the way. Isolation is what makes that gap possible: 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 one organizations skip most often — and it shows in the outcomes. In a 2025 industry survey, 62% of organizations reported failing to perform regular backup-and-restore testing exercises, and 37% said they were unable to recover within their required recovery time objective (RTO) specifically because backups were missing or had simply never been validated. Confidence and reality diverge sharply here: more than 60% of organizations believe they can recover from downtime within hours, but only about a third actually do when tested.
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 validation also carries a sharper risk than simple downtime — an estimated 63% of organizations risk reintroducing an infection during restoration because they skip integrity and malware scanning under time pressure, effectively recovering 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 — validated against RTOs the business actually needs, not figures that merely look reassuring in a slide deck.
What it looks like when the three pillars hold
Sophos's 2025 data offers a useful counter-example to the headline statistics: among organizations that did have data encrypted by an attacker, 97% were still able to recover it. The difference between that group and the small minority who could not almost always traces back to one of the three pillars being weaker in practice than it appeared on paper — a retention lock that could be overridden by the wrong role, a "separate" backup network that still trusted the same domain, or a restore that had never actually 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. The average cost to recover from a ransomware attack, excluding any ransom paid, runs to roughly $1.53 million. Only 53% of victims were fully recovered within a week; the rest spent longer than seven days in some state of disruption, with downtime, lost productivity, and incident-response labor compounding 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 determined entirely by decisions 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 point-in-time delta stored on the same datastore as the VM it protects — not an independent copy. It grows unbounded, degrades performance, and disappears the moment the datastore does. Snapshots are a convenience feature for short-lived rollback, 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
At BackupSec, we help enterprise teams operate their backup environments against exactly these three pillars — not by replacing their backup platform, but by making backup security observable, advisable, and provable.
Our approach combines three layers:
- ZeroMON delivers continuous observability over the entire backup estate — Veeam-ready monitoring with real-time job tracking, automated security checks, forensic audit trails for configuration drift, and one-click compliance reports. This is the layer that turns "immutability is configured" from an assumption into evidence.
- ZeroTAM provides dedicated expert advisory for backup architecture, isolation design, and ransomware recovery planning — the human layer most enterprises need to interpret what their backup environment is actually telling them, and to design isolation that survives contact with a real incident.
- ZeroPEN pentests your backup infrastructure the way a real adversary would — targeting management planes, access controls, and immutability settings — and then runs actual restore scenarios to validate that you can recover cleanly, completely, and within your stated RTO, not just that a backup job reported success.
BackupSec is deployed on-premise, connects to your backup applications through read-only API access, and never moves backup data outside your environment.
Talk to BackupSec about your backup security posture →
Ready to find out whether your own backups would hold up? Score your environment with the free Backup Security Assessment.