How to Choose Backup Immutability That Survives Ransomware

What happens if a ransomware gang gets your admin credentials tonight and goes straight for your backups? If the honest answer is “they’re gone,” the problem isn’t your backup software. It’s that you never chose real immutability.

Immutability is the one backup feature attackers actively test. Everything else in your backup stack, from scheduling to deduplication, fails politely when a bad actor holds your keys. So this decision deserves more scrutiny than a checkbox on a vendor comparison sheet. Here’s how to choose well.

What Backup Immutability Really Means

Immutable backups are copies that cannot be altered or deleted during a defined retention window, even by someone with full administrative rights. That last part matters. A backup you promise not to delete is not immutable. A backup the storage system refuses to let anyone delete is.

The mechanism is usually one of three things: WORM storage (write once, read many), object lock features on cloud storage, or append-only repositories. Most vendors now layer snapshot retention locks on top. The Wikipedia entry on WORM is a decent primer on the underlying concept, which predates cloud computing by decades.

Here’s the trap: vendors use “immutable” loosely. Some mean storage-level WORM. Others mean a policy that blocks deletion through the normal interface but folds instantly if an attacker compromises the management console. Those are very different products wearing the same label.

Start With Your Threat Model, Not the Feature List

Before comparing vendors, write down what you’re defending against. Immutability configured for accidental deletion looks nothing like immutability built for a determined intruder.

Ask three questions:

• Who is the adversary? A careless admin, a compromised service account, or an attacker with domain admin rights?

• How long does the attacker dwell? Ransomware operators often sit inside networks for weeks before detonating. Your retention window must outlast detection time plus recovery time.

• What’s your recovery point objective? Immutability protects data you already have. It doesn’t help if the last clean backup is thirty days old.

A useful rule of thumb from security practice: assume the attacker knows your architecture, because they often do. Design as if the control plane is already compromised. That mindset pushes you toward logical air-gapping and separate credentials, rather than relying only on a retention setting.

The Four Immutability Models Compared

Most options on the market fall into four buckets. Each has real trade-offs.

The CISA #StopRansomware Guide consistently emphasizes offline, encrypted, and tested backups, and immutability fits squarely inside that guidance. It’s worth reading before you shortlist vendors, because it frames backups as part of incident response rather than just data protection.

For a broader look at protecting the machines that hold your data in the first place, see this guide on how to choose the best antivirus for your computer. Endpoint protection and immutable backups are complementary layers, not substitutes.

Governance Mode vs. Compliance Mode: Get This Right

If you go the cloud object lock route, this is the single most consequential setting, and it’s where most teams stumble.

Governance mode lets users with special permissions bypass or shorten retention. It’s useful for testing and for workloads where flexibility matters. It is also, by design, defeatable by anyone who compromises an account with those permissions.

Compliance mode cannot be shortened or removed by anyone, including the root account, until the retention period expires. That’s the mode you want for ransomware defense.

The catch is real: compliance mode is a one-way door. If you lock a backup for seven years and later face a data-erasure request or a legal obligation to delete, you may be stuck. Privacy regulations and immutability can genuinely conflict. Resolve that tension with legal counsel before you set retention, not after.

A practical middle path many teams use: compliance mode on a narrow, critical dataset, governance mode on the broader estate. You get an unbreakable core without painting the whole organization into a corner.

Retention Period: The Calculation Most Teams Get Wrong

Vendors love round numbers. Seven years, ninety days, one year. Ignore the marketing and do the math.

Your minimum retention should cover:

• Regulatory minimums for your sector and jurisdiction, which vary widely and change

• Your realistic detection window (how long an intrusion could go unnoticed)

• Your full recovery timeline, including rebuild and validation

• A safety margin for the investigation itself

Then add buffer. If detection takes three weeks and recovery takes two, a thirty-day lock is not a safety net. It’s a countdown timer.

The mistake people make in practice is setting retention to the compliance minimum and calling it done. Compliance minimums protect you from regulators. They were never designed to protect you from attackers. Choose the longer of the two numbers.

Don’t Forget the Keys

This is the failure mode that quietly defeats otherwise solid designs. If an attacker can delete or rotate your encryption keys, immutability of the ciphertext buys you very little. The data is intact and permanently unreadable.

Practical safeguards:

• Store keys in a separate trust domain from the backup data, ideally a different cloud account or an on-premises HSM

• Require multi-party approval for key deletion

• Enable key deletion protection where the platform offers it

• Document a key recovery procedure and test it

The same separation logic applies to credentials. Immutable storage protected by a password sitting in the same identity provider as your domain admin account is not protected. Consider a dedicated secure password manager for break-glass credentials, stored offline.

Verification and Restore Testing: The Step Everyone Skips

An immutable backup you’ve never restored is a hypothesis, not a backup. Vendors will happily sell you immutability; nobody sells you confidence.

Build a routine:

• Automate integrity checks on a sample of immutable copies, weekly at minimum

• Run a full restore into an isolated environment quarterly

• Time the restore and compare it to your recovery time objective

• Verify the restored data, rather than only checking that the job completed

• Document what broke and fix it before the next cycle

The NIST Cybersecurity Framework treats recovery testing as part of the Respond and Recover functions, and it’s a reasonable structure to hang your process on. For teams handling large media sets, pairing immutability with solid photo backup solutions keeps irreplaceable files protected without complicating the core backup architecture.

Lock-In, Exit, and the Contract Details That Bite

Compliance-mode retention can outlast your vendor relationship. That’s not a hypothetical; it’s a contractual reality teams discover during migrations.

Before signing, get answers in writing:

• What happens to locked data if we terminate the contract? Can we export it, and at what cost?

• Who controls the retention settings after termination?

• What are the egress charges for a full restore?

• Can the vendor shorten retention on our behalf? (The answer should be no.)

• What’s the notice period for changes to lock behavior?

Also check whether the vendor’s own staff can access your data. “Immutable” should mean nobody, including support engineers with elevated access, can delete it outside the retention window. If that’s not documented, assume it isn’t true.

Matching Immutability to Your Environment

Different environments need different answers, and copying a hyperscaler’s architecture into a small business is a classic mistake.

Small teams often do best with a cloud object-lock bucket in compliance mode, a separate account for credentials, and a quarterly restore test. Low operational overhead, strong guarantee.

Mid-size organizations usually want a dedicated immutable appliance or an append-only repository, plus cloud copies for a second location. The redundancy matters more than the brand.

Enterprises and regulated industries typically run multiple models at once: WORM on-premises for the compliance core, object lock in the cloud for scale, and snapshot locks for fast operational recovery. Complexity is the price of coverage.

Home users and solo operators rarely need enterprise immutability, but the principle still applies. A best external hard drive for backup kept disconnected most of the time is a crude, effective form of air-gapping. Add cloud versioning with object lock if the data truly matters.

One more consideration for anyone running infrastructure at home or in a small office: backup systems need power. A home generator for reliable backup power or a solar generator for home backup power keeps recovery operations running during the outage that often accompanies an incident. It sounds tangential until the night you need to restore and the lights are out. (Backup)

Common Mistakes That Undo Good Immutability

These show up again and again in post-incident reviews:

• Same credentials everywhere. The backup admin account is the domain admin account. Immutability never gets tested.

• Immutability enabled but not verified. A misconfigured bucket policy that silently allows deletion is worse than no policy, because it creates false confidence.

• Retention set to the compliance minimum. See above.

• No offline copy. Immutability protects stored data; it doesn’t protect against an attacker who deletes the entire account or the vendor relationship.

• Keys stored with the data. The classic own-goal.

• Restore never tested. The most common failure of all.

If you’re funding a broader resilience project, home improvement loans and how to choose the right option can cover physical infrastructure like a hardened server room or backup power, though most backup immutability decisions are operational rather than capital expenses.

A Practical Selection Checklist

Run every candidate through this list before you commit:

• Does the vendor enforce immutability at the storage layer, or only in software policy?

• Can anyone, including support and root accounts, delete data inside the retention window?

• Are encryption keys separable from the data, with independent deletion controls?

• Is compliance mode available, and do you understand its irreversibility?

• What does exit look like, including egress costs and locked-data handling?

• Does the vendor support automated restore testing or at least clean integration with your tooling?

• Can you prove it works with a documented test before you rely on it?

If a vendor can’t answer the second question with an unambiguous yes, keep looking.

Conclusion

Choosing backup immutability comes down to a short list of decisions made in the right order: define your threat model, pick a storage-level enforcement model, choose compliance mode for the data that truly matters, size retention to your real recovery timeline rather than the regulatory floor, separate your keys and credentials, and test restores until they’re boring.

The technology is not the hard part. Most modern platforms can enforce WORM storage competently. The hard part is resisting the urge to treat immutability as a feature you enable and forget. Attackers don’t attack the feature. They attack the credentials, the keys, the management console, and the retention setting someone shortened “just for now.”

Get those right, and immutability becomes what it’s supposed to be: the copy that’s still there when everything else has gone wrong. Get them wrong, and you’ve bought a reassuring label on a backup that was never really protected.

FAQ

How long should immutable backups be retained?

Long enough to cover your detection window, full recovery timeline, and any regulatory minimum, plus a safety margin. Many teams land between 30 and 90 days for operational recovery and longer for compliance data. Avoid setting retention to the regulatory floor alone, since that number was never designed to survive an intrusion.

Is cloud object lock the same as true immutability?

It can be, if configured in compliance mode with retention that cannot be shortened. In governance mode, privileged users can bypass the lock, which makes it a policy control rather than a hard guarantee. The distinction matters enormously during an incident, so confirm which mode you’re actually running.

Can ransomware delete immutable backups?

Not directly, if immutability is enforced at the storage layer and credentials are properly separated. Attackers instead target the surrounding weaknesses: admin accounts, encryption keys, management consoles, and retention settings. That’s why immutability must be paired with key separation, logical air-gapping, and tested restores.

What’s the difference between immutability and air-gapping?

Immutability prevents stored data from being altered or deleted during a retention window. Air-gapping physically or logically isolates the backup from the production network. They solve different problems and work best together, since immutability protects the data while isolation protects the path to it.

Do small businesses need immutable backups?

Yes, if the data matters. Small organizations are frequent ransomware targets precisely because their defenses are thinner. A cloud object-lock bucket in compliance mode, a separate credential set, and a quarterly restore test deliver strong protection at modest cost and operational effort.

How often should immutable backups be tested?

At minimum, run integrity checks weekly and a full restore into an isolated environment quarterly. Time each restore against your recovery objectives and document what failed. Immutability without verification is an assumption, and assumptions are exactly what attackers exploit.