What is an immutable backup? It's a backup copy that cannot be changed, encrypted or deleted — not by a misconfigured script, not by an admin with valid credentials, not even by an attacker who has taken over your entire environment — for a period you set in advance. That single property is why "do you have immutable backups?" has gone from a nice-to-have line item to a question your cyber insurer now asks on almost every renewal, and increasingly checks rather than just takes your word for.
If you've been told your backups are "safe" because they're encrypted, stored offsite, or covered by a retention policy, none of that is the same thing. This guide covers what immutability actually is, how it differs from air-gapping — a related but separate control people conflate constantly — where it actually lives in practice, and what it costs to add at different budgets.
What is an immutable backup, exactly?
An immutable backup uses write-once-read-many (WORM) protection: once a backup version is written, the storage layer itself refuses to modify or delete it until a retention clock you set in advance expires. It doesn't matter who's asking — the backup software's own delete function, a compromised administrator account, or ransomware that has already taken over Domain Admin. If the retention window says 30 days, that data isn't going anywhere for 30 days, full stop.
This is enforced at the storage layer, not the application layer. That distinction matters because most ransomware that reaches backup infrastructure does it by compromising the backup software's own credentials — deleting jobs, wiping repositories, or reformatting target storage through the tool that's supposed to protect the data. Immutability closes that specific hole: even total administrative compromise of your backup software can't touch data that's already locked.
The best-known implementation is Amazon S3 Object Lock, which requires a versioned bucket and offers two modes. Governance mode lets accounts with specific IAM permissions remove the lock early; Compliance mode can't be overridden by anyone, including the AWS root account, until the retention period actually expires. Most vendors selling "immutable" S3-compatible storage implement the same Object Lock API underneath.
Air-gapped vs immutable: two different controls, often confused
These terms get used interchangeably, and they shouldn't be — they solve different problems, and the strongest setups use both.
Air-gapping is about isolation: the backup copy is physically or logically disconnected from your production network, so an attacker who's already inside your environment simply can't reach it. Classic air-gapping means tape that's physically removed from the network; modern logical air-gapping uses network segmentation, rotating credentials, or storage that's only reachable during a scheduled backup window.
Immutability is about tamper-resistance while still connected. The data stays reachable over the network — for fast recovery — but the storage itself enforces that it can't be altered or deleted, regardless of who's asking.
An air-gapped copy that isn't immutable can still be deleted by anyone who gets access during its brief connection window. An immutable copy that isn't air-gapped is still sitting on a network an attacker can see, even if they can't damage it. Combining both — network isolation plus WORM protection — is what actually closes the gap, and it's what the appliance vendors below build in as standard rather than as an add-on.
Where immutability actually lives
In practice, immutable storage shows up in three places, and most organisations end up combining more than one.
Object storage with Object Lock. Wasabi's immutable buckets implement the same WORM model as AWS S3 Object Lock — once enabled, data can't be modified or deleted for the retention period you set, at a flat per-TB rate with no egress fees. This is the cheapest entry point if your backup software (Veeam, NAKIVO, Commvault, or anything S3-compatible) can already write to an S3 target.
On-premises appliances with built-in immutability. StoneFly's DR365V bakes this in rather than treating it as configuration: automated physical and logical air-gapping runs per backup job, and the appliance's cloud tier (StoneFly Cloud Vault) adds Object Lock immutability on top for offsite retention. For Veeam shops specifically, that's the air-gap-plus-immutability combination above, built into one box instead of stitched together from separate products.
SaaS backup with independent, structurally immutable infrastructure. Keepit takes a different approach for Microsoft 365, Google Workspace and 15+ other SaaS platforms: your backup runs on Keepit's own cloud, entirely separate from Microsoft's or Google's infrastructure, and verified with a blockchain-based Merkle tree rather than a toggle you could accidentally switch off. If your production SaaS tenant is compromised, the backup copy is architecturally outside the blast radius — there's no shared credential or shared infrastructure for an attacker to pivot through.
Virtual machine backup software plays a role too — NAKIVO's immutable repository targets can write to local storage, S3 or Wasabi with the same WORM protection applied at the repository level, so the immutability choice above extends to VM-level backups without a separate product.
Why your cyber insurer keeps asking about immutable backups
Cyber insurance underwriting changed meaningfully through 2026. What used to be a self-reported yes/no question on a renewal form is now something insurers are actively verifying rather than taking on trust — specialists checking that immutable, isolated, restore-tested backups actually work, with the test date documented, not just claimed. Multiple 2026 readiness reviews now list immutable backups alongside MFA and endpoint detection as a non-negotiable underwriting control, not a nice-to-have that merely improves your premium.
The practical effect: without demonstrable immutability, you may not get cyber cover at all, or you'll pay a meaningfully higher premium for a policy that still might not pay out if an auditor later finds your "immutable" backups were actually just retention policies with a longer window. That's the gap this guide opened with — retention isn't immutability, and increasingly, insurers know the difference even when the business buying the policy doesn't.
Matching immutability to your budget
You don't need every layer above to start. A sensible order, roughly cheapest to most complete:
- Already backing up to S3-compatible storage? Turn on Object Lock. If you're on Wasabi, it's a bucket setting, not a new product.
- Running VM backups? Point your NAKIVO repository at immutable storage — local, S3 or Wasabi — so VM-level recovery inherits the same protection.
- Want it built in rather than configured? A StoneFly DR365V appliance ships with automated air-gapping and Object Lock as standard, not settings to remember to enable correctly.
- Protecting Microsoft 365, Google Workspace or other SaaS data? That's a different problem from VM or file backup — native retention policies aren't backups, and Keepit is built specifically to close that gap with infrastructure that's immutable by design.
None of this needs to be a single big-bang project. Most CRS partners layer it in roughly the order above, starting wherever the current backup already writes to S3-compatible storage, and treating ransomware protection as the ongoing programme immutability sits inside, not a one-off purchase.
A quick self-check: if someone holding valid admin credentials to your backup software could delete every recovery point in an afternoon, you don't have immutable backups — you have backups that are one compromised password away from being no backups at all. That's precisely the scenario ransomware crews target once they're inside an environment, and it's precisely the scenario each layer above is built to remove.
If you're mapping out what your cyber insurer will actually accept before your next renewal, get in touch — we distribute the vendors above and can help work out which layer closes your specific gap first.