Why Ransomware Now Targets Your Backups First

Ransomware groups no longer treat backups as an afterthought. Backup repositories are now the first infrastructure attackers try to reach, because destroying the restore path is what forces a ransom decision. That shift is rewriting what insurers, regulators, and clients expect a functioning BCDR stack to look like, and it is raising the operational bar for every MSP that runs one.

How often do ransomware attacks actually target backups?

Nearly every attack now includes a deliberate attempt to reach backup infrastructure. Veeam's 2025 Ransomware Trends Report, surveying 1,300 organizations, found 89 percent had backup repositories targeted, and attackers modified or deleted an average of 34 percent of those repositories once inside. Sophos' State of Ransomware 2026 report, based on a survey of 2,158 IT and security leaders across 17 countries whose organizations were hit in the prior year, put the average total cost of a ransomware incident at 1.7 million dollars.

A working backup is what changes that outcome. Sophos found that where victims recovered through backups, they did so in 66 percent of attacks where data was encrypted, up from 54 percent the year before. Sophos also found attackers succeeded in encrypting data in 56 percent of attacks overall, meaning close to half of all victims kept their data from being encrypted at all, almost always because a clean, working backup or fast detection stopped the encryption before it finished.

Why backups became the primary target instead of a fallback

Encrypting production data alone gives a victim an escape hatch if backups still work. Attackers know this, so credential based access to backup consoles, storage snapshots, and cloud repositories has become a standard step in the intrusion, not an opportunistic afterthought. Once a threat actor can delete snapshots or disable retention locks, the ransom conversation shifts entirely in their favor regardless of how strong the client's endpoint defenses were.

The sequencing matters operationally. Backup platform credentials typically live in the same identity system as everything else on the network, so an attacker who reaches domain admin also reaches the backup console, and repository access does not require a separate exploit chain most of the time. That is why a mutable backup target sitting on the same network as production, protected only by the same account set an attacker already compromised, offers almost no resistance once the intrusion reaches that stage. It also means the fix is architectural rather than procedural. This is a distinct problem from whether an organization tests its recovery process on schedule. It is about whether the backup copy still exists to test at all.

What do cyber insurers now require for backup architecture?

Underwriters increasingly treat an immutable, offline backup copy as a baseline control, not an optional upgrade, alongside multi factor authentication and endpoint detection. The traditional 3-2-1 backup rule is being extended in practice to what the industry now shorthands as 3-2-1-1-0:

• Three total copies of the data
• Stored on two different media types
• With one copy kept offsite
• At least one copy immutable or air gapped, so it cannot be altered even by a compromised admin account
• Zero errors, meaning restores are actually verified rather than assumed to work

Carriers are asking for evidence that this architecture exists, not just a policy document describing it, because a workable restore path is what keeps a claim from becoming an eight figure loss.

Regulators are moving in the same direction, at least for regulated sectors. New York's cybersecurity regulation for financial services, 23 NYCRR 500.16, requires covered entities to maintain a written business continuity and disaster recovery plan that includes procedures for backing up information essential to operations and keeping backups adequately protected from unauthorized alteration or destruction, alongside a separate incident response plan that explicitly addresses recovery from backups. For an MSP serving banks, credit unions, or insurance agents in New York, that is not a best practice suggestion. It is a compliance obligation a client's examiner will ask about directly.

Does having immutable backups actually solve the problem?

Not by itself, and that is the part most MSPs get wrong. Most backup platforms support immutability today, so the gap is rarely whether the feature exists. It is how it gets configured. Veeam's own product guidance notes that immutable repositories still sit on a network path an attacker can reach, and on some platforms a user with high enough privileges can override the lock before the retention period expires.

An attacker who already has domain admin, which is how most ransomware operators reach the backup console in the first place, can be exactly that privileged user. That is the real operational work: verifying, per client, that the immutable configuration cannot be overridden by the same credentials an attacker would already control if they compromised the network, not just confirming a checkbox is turned on somewhere in the backup console.

That verification is not a one time project. It means storage tiering decisions per client, retention lock configuration that has to be tested rather than assumed, and documentation an insurer or examiner can actually read during renewal or after an incident. Every one of those steps has to be repeated per client, per backup target, and re-verified whenever a client adds a new workload or moves to a new cloud tenant, which is a very different staffing load than running a nightly job and checking a green checkmark.

None of that shows up as billable break fix work, which is exactly why it gets skipped at MSPs running lean on senior engineering time. Standardizing that build out and verification across a client base, instead of re solving it client by client, is the kind of onboarding and provisioning overhead the Catalyst platform is built to absorb, so a verified immutable copy becomes a checklist item instead of a custom project every time.

What this means for margin and client retention

A client whose backups get destroyed alongside their production data does not blame the ransomware group first. They ask why the MSP responsible for their backup strategy did not have a working immutable copy in place, and that conversation happens right when the relationship is most fragile. Pricing and staffing a BCDR offering that can actually survive a targeted attack, rather than one built for accidental data loss, is table stakes now, not a premium tier.

That repricing conversation is easier to win than most owners expect, because the underwriting shift gives MSPs a concrete, third party reason for the cost that has nothing to do with upselling. A client who resists paying for a verified immutable copy is not arguing with the MSP anymore. They are arguing with their own cyber insurer's renewal questionnaire, and that is a much easier position to hold. If you are not sure whether your current stack meets the 3-2-1-1-0 bar for a given client segment, running it through stack-builder is a faster way to find the gap than auditing each client manually, and the product catalog shows where a BCDR specific offering fits alongside what you already sell.

None of this replaces testing your recovery process on a real cadence. It sits upstream of that question entirely. A tested recovery plan built on a backup copy an attacker can still reach and override is not protection, it is a false sense of one. Insurers, examiners, and increasingly clients themselves are starting to ask the architecture question first and the testing question second.

Where to start

Start with the clients most exposed to regulatory scrutiny or the largest potential loss, not the easiest to schedule. Confirm which backup copies are actually immutable and unreachable by a compromised admin account today, versus which are merely described that way in a runbook, then work outward from there.

See the full stack built to support that kind of BCDR delivery without adding headcount for every client conversion.

Sources: Sophos State of Ransomware 2026 | Veeam 2025 Ransomware Trends Report | NYDFS 23 NYCRR 500.16 via Cornell Law School Legal Information Institute.