For decades, having backups was the answer to ransomware. So attackers adapted, with brutal logic: before encrypting anything, they hunt down and destroy your backups. Modern ransomware crews spend days inside a network doing exactly this — finding backup servers, deleting cloud copies with stolen admin credentials, wiping restore points — and only then detonating. The counter is a copy that cannot be altered or deleted during a set window, no matter who asks, including an administrator. That’s an immutable backup, and it has quietly become the load-bearing word in modern backup design.
The problem it solves, precisely
The 3-2-1 rule — three copies, two media, one offsite — was built for fires, floods, and failures. Ransomware exposed its blind spot: an “offsite” cloud backup that your admin account can delete is a backup the attacker’s stolen admin account can delete too. In the standard attack sequence, credentials get harvested first, backups get destroyed second, encryption comes last — so any copy reachable with network credentials shares the network’s fate. The attacker’s ransom leverage is exactly equal to your inability to restore. Immutability removes the leverage.
How “can’t be deleted” actually works
Immutability is a storage-level lock, not a permission setting. When a backup lands in immutable storage, it’s committed with a retention timer — say 30 days — during which the storage itself refuses modification or deletion of that copy. Not “requires a higher password.” Refuses. The admin can’t do it; therefore stolen admin credentials can’t either. (The idea is old — banks called it WORM, write-once-read-many; the cloud era made it affordable for everyone.)
Where you get it, in rough order of commonness: cloud backup platforms with immutability or object-lock enabled — most serious business backup products now offer this, sometimes on by default, often not, which is the point of asking; hardened backup appliances whose local copies resist deletion even from inside the network; and the old-school genuinely offline copy — the air gap — which achieves the same end by being physically disconnected. Offline is the most attack-proof and the most labor-dependent; immutable cloud copies are how most small businesses get the protection without the ritual.
The questions that separate marketing from protection
“Ransomware-proof backup” appears on a lot of brochures. Five questions cut through:
- “Is immutability actually enabled on our backups — and can you show me the setting?” Supported-but-not-enabled is the most common real-world gap.
- “How long is the immutability window?” It must exceed your detection lag. Breaches are routinely discovered weeks after they begin; a 7-day lock on a 3-week-old intrusion protects nothing. Thirty days is a sensible floor; align it with your retention policy.
- “Could our own admin delete these copies today?” If yes — through the console, the vendor’s support line, or account closure — an attacker with those credentials can too. The honest answer should involve the vendor being unable, not just unwilling.
- “Does this cover everything, or just the server?” Microsoft 365 backups, file shares, and the line-of-business systems belong under the same protection as the server image.
- “When did we last restore from the immutable copy?” Immutability guarantees the copy exists — only a test proves it works.
Where it fits, and what it doesn’t fix
The modern formulation is 3-2-1-1-0: the classic rule, plus one copy immutable or offline, plus zero errors on verified tests. Immutability is that fourth digit — and it’s now explicitly on cyber insurance applications, because carriers’ claims data shows the ransom gets paid precisely when the backups died with the network. Cost-wise, it’s typically a modest increment on storage you’re already buying — trivial against what it insures.
Worth saying plainly: immutable backups don’t prevent anything. The attack still happens; the data still gets encrypted; the stolen-data extortion angle still exists. What immutability changes is the ending — from a negotiation with criminals to a restore operation. That’s the difference between ransomware as an existential event and ransomware as a very bad week.
The bottom line
Attackers destroy backups because it works. An immutable copy — locked at the storage level, sized past your detection lag, tested like you mean it — is the direct counter, and it’s the single upgrade that most changes how a ransomware story ends. If you don’t know whether your backups have it, that’s this week’s question for whoever manages them. It’s a one-setting answer with a very large blast radius.