The figure gets quoted constantly, usually without a source attached: 96% of ransomware attacks target backup repositories. It comes from Veeam’s 2024 Ransomware Trends Report, where it described attacks that prioritised backup repositories — up from 93% in the 2023 edition of the same survey. It is worth being precise about its vintage, because a number repeated for two years as though it were fresh tends to get treated as folklore rather than evidence.
The evidence, as it happens, holds up well. Sophos, surveying 2,974 organizations hit by ransomware through Vanson Bourne, found that 94% reported attackers attempting to compromise their backups during the attack. Two independent vendor-agnostic surveys converging in the mid-90s is about as solid as this category of data gets. Backup infrastructure is not collateral damage in a ransomware incident. It is an objective, and usually an early one.
What matters operationally is the next question, which the headline figure does not answer: how often does the attempt work, and what changes when it does?
The attempt succeeds a little over half the time
Across all sectors, 57% of backup compromise attempts succeeded. That number carries enormous industry variance — 30% in IT, technology and telecoms, against 79% in energy, oil, gas and utilities. The spread is the interesting part. It tells you this is not a question of attacker capability, which is roughly constant across targets, but of defensive architecture, which is not. Organizations that have separated their recovery copies from their production identity plane survive the attempt. Organizations that have not, mostly do not.
Veeam’s data fills in what “compromised” means in practice: 75% of victims experienced at least partial loss of backup data, and 39% lost their backup repositories entirely. Partial loss is the more common and in some ways more insidious outcome, because it is discovered during the restore rather than before it — the recovery points exist, the console lists them, and the specific ones you need are gone.
Compromised backups change every outcome that matters
This is where the pattern stops being an interesting statistic and starts being a budget argument. The Sophos data compares outcomes for organizations whose backups were compromised against those whose backups held:
- Ransom payment: 67% paid when backups were compromised, versus 36% when they were not. Losing your backups roughly doubles the likelihood you fund the attacker.
- Encryption success: 85% of organizations with compromised backups had data encrypted, against 52% of those whose backups survived. The correlation runs both directions — an attacker with the access and dwell time to reach backup infrastructure generally also has what they need to encrypt production.
- Median recovery cost: $3 million with compromised backups, against $375,000 with intact backups. Eight times the bill.
- Recovery within one week: 26% with compromised backups, versus 46% without.
The eight-times cost multiple is the figure to carry into a procurement conversation. It is not a vendor’s projected ROI model; it is observed median spend across a large survey population. Whatever hardening the recovery tier costs, it is being compared against a $2.6 million median swing in incident cost.
Why the repository is reached so reliably
The mechanism is unglamorous and almost entirely about credentials rather than exploits. Sophos’s 2026 survey attributes 79% of ransomware attacks to an identity-based initial approach, with compromised credentials, phishing and malicious email together accounting for the large majority of root causes, while exploited vulnerabilities fell to 18%.
An attacker holding valid credentials with sufficient privilege does not need to defeat your backup software. They log into it. From there the sequence is predictable: enumerate repositories through the backup console or storage APIs, delete volume shadow copies using built-in operating system commands, encrypt any repository reachable over SMB or NFS, and shorten or purge retention policies so that surviving recovery points age out on their own.
Backup service accounts are unusually attractive for this because their function requires broad reach. An account that can back up everything can, by construction, see everything worth encrypting. When that account is domain-joined and its credentials are cached on production hosts, the backup tier is not a separate security domain at all — it is a particularly well-connected part of the one already compromised.
This is also why “we have immutable backups” is an incomplete claim. Immutability enforced through a setting in a console that the attacker can authenticate to is a configuration, not a control. The question is whether the identity that can delete the retention lock is the same identity an intruder obtains on the production network.
What actually separates the 43%
The organizations whose backups survive the attempt tend to share a small number of structural properties, none of which are products:
- A separate identity boundary for the recovery tier. Backup console authentication that does not resolve against production Active Directory, with phishing-resistant factors. Sophos found 97% of victims had some form of MFA enabled — the qualifier is doing the work, and push-fatigue-prone approval flows on a backup console are not equivalent to hardware-backed authentication.
- Immutability the backup service account cannot revoke. Object-lock in compliance mode, or a retention governance model where shortening retention requires a credential that lives outside the environment being protected. If the backup application can delete its own recovery points, so can whoever holds its token.
- At least one copy with no standing network path. The 3-2-1-1-0 formulation exists precisely for this — the extra “1” is the offline or logically air-gapped copy, and the “0” is verified-zero-errors on restore test. Tape that has been ejected, or object storage reachable only through short-lived credentials issued for the duration of a job, cannot be reached by a session an attacker inherits.
- Restore testing at realistic scale. The 26%-versus-46% recovery-time gap is partly about compromised data and partly about untested runbooks. A restore that has never been performed at production volume has an unknown duration, and unknown durations are how a one-week recovery becomes a one-month one.
The 96% figure has been repeated so often it has lost its edge. Read alongside the 57% success rate and the eight-times cost multiple, it says something quite specific and still under-acted-upon: the recovery tier is a primary target, it falls more often than not, and whether it falls is determined by architecture decisions made long before the intrusion — chiefly whether a stolen production credential can reach it.
Sources: Veeam, 2024 Ransomware Trends Report (96% prioritised backup repositories; 93% in the 2023 edition). Sophos / Vanson Bourne, The Impact of Compromised Backups on Ransomware Outcomes (2,974 organizations, surveyed early 2024). Sophos, The State of Ransomware 2026 (2,158 respondents, 17 countries).