← All Blogs

Immutable backup, and the one test that actually counts

By Best IT MSP Editorial Team - Updated October 21, 2026 - 12 min read

The Best IT MSP editorial team maintains this directory's provider data across the US and Canada. We rank providers on verified rating and firmographic data, label paid placement, and do not sell IT services.

What is an immutable backup?

An immutable backup is a stored copy that nobody can alter or delete for a fixed retention window, including an administrator holding valid credentials. The copy stays readable the whole time. It simply cannot be changed or removed until the clock runs out.

The storage industry calls this WORM, short for write once read many. Microsoft describes its own version plainly, saying immutable storage keeps data in a WORM state where data can't be modified or deleted for a user-specified interval. Amazon uses the same model for S3 Object Lock, which it says uses a write-once-read-many (WORM) model to store objects. Two mechanisms do the work. A retention lock puts an expiry date on each recovery point, and a legal hold keeps a copy locked with no expiry date at all until somebody removes the hold.

Your provider may use a different brand name for the same thing. Object lock, retention lock, vault lock, immutability setting and compliance mode all describe one control applied at a different layer. The name does not matter. Who can switch it off does, and that question has a precise answer you are entitled to ask for.

This guide covers immutable backup from the buyer's side. Read it beside Backup and Disaster Recovery: A Complete Guide for the underlying concepts, When was your backup last restored, not just run? for the evidence that a copy comes back, and RTO and RPO explained for the price of every recovery target you set.

Why ransomware made immutable backup non-optional

Ransomware made immutability non-optional because destroying your recovery options is now a standard step in the attack rather than an afterthought. A crew that encrypts your file server and finds the backups still sitting there has no leverage. A crew that deletes them first has your whole business.

The behaviour has a catalogue number. MITRE ATT&CK tracks it as T1490, Inhibit System Recovery, and records that adversaries delete or remove built-in data and turn off services designed to aid in the recovery of a corrupted system. It also documents that attackers delete online backups connected to the network, including folders that sync to cloud services, and that in cloud environments they disable versioning and backup policies and delete snapshots, database backups and machine images.

Government advisories name the behaviour group by group. CISA and the FBI reported that Akira actors use PowerShell commands to delete Volume Shadow Copy Service (VSS) copies on Windows systems, and did so to further inhibit system recovery and impede forensic analysis. The same agencies, writing about Ghost ransomware, recorded that victims whose backups were unaffected by the ransomware attack were often able to restore operations without needing to contact Ghost actors or pay a ransom. That one sentence is the entire business case for a retention lock.

Claims data now shows the same outcome at scale. Coalition, which insures more than 100,000 policyholders, reported that a record 86 percent of businesses refused to pay in 2025 and said the figure suggests that organizations have improved their cyber resiliency with viable data backups and incident response plans. Demands moved the other way, with initial ransom demands surging 47 percent year over year. Coveware, which negotiates these cases, saw the data exfiltration only payment rate drop to a historically low level of 15 percent while the median payment fell by 50 percent to 150,000 dollars.

Read those two trends together. Attackers ask for more because fewer people pay, and fewer people pay because the recovery copy survived. An immutable backup does not stop the attack. It removes the reason to negotiate.

Immutability is a property of the retention lock, not the storage product

Immutability is a property of the retention lock rather than of the storage product, because the same product ships in two modes and only one of them resists your own administrator. Ask which mode you are on and you learn whether the control survives the attack it exists for.

Amazon publishes the difference in plain language. In compliance mode, a protected object version can't be overwritten or deleted by any user, including the root user in your AWS account, and Amazon adds that the only way to delete an object under the compliance mode before its retention date expires is to delete the associated AWS account. In governance mode, users can't overwrite or delete an object version or alter its lock settings unless they have special permissions. Same product, same line on the invoice, completely different answer to the only question that matters.

The governance-mode detail deserves reading twice. Bypassing that lock takes one permission and one request header, and Amazon notes that by default, the Amazon S3 console includes the bypass governance retention header, so a privileged user who clicks delete in the console finds that the operation will succeed. Nothing was misconfigured. The lock behaved exactly as documented.

The locked and unlocked distinction does the same job on Azure

Microsoft draws the same line, between a policy you can still edit and one you cannot. It says both locked and unlocked policies protect against deletes and overwrites, then adds that you can modify an unlocked policy by shortening or extending the retention period and that you can also delete an unlocked policy. A locked policy cannot be deleted, and its retention period can be extended but never decreased. Microsoft states that a time-based retention policy must be locked for the blob to be in a compliant immutable, write and delete protected, state, advises locking it in a reasonable amount of time, typically less than 24 hours, and says not to use the unlocked state for anything other than short-term testing.

So here is the test, in one sentence. Could your own domain administrator, using every credential they legitimately hold, destroy that copy before its retention window expires? A yes means you do not have an immutable backup. You have a storage product with an immutability feature set to the mode that an attacker holding your administrator's password can turn off. Lock the policy properly, and the length of the window becomes the only variable left to argue about.

A provider who can name the lock mode on your retention policy is operating the control. A provider who names the storage product is only selling it.

Price is not the obstacle here. Microsoft states there is no extra capacity charge for using immutable storage and that immutable data is priced in the same way as mutable data. Amazon says AWS Backup Vault Lock is available at no additional charge. A provider quoting a premium for the word, rather than for storage and labour, should explain what the premium pays for.

The trap, a locked copy that lives in the same identity domain as production

A copy inside the same identity domain as production usually fails the test even when the storage advertises immutability, because the account that administers the backup is reachable through the same credential compromise that takes production. One stolen domain administrator password puts the attacker inside both.

Microsoft's own backup documentation treats this as the central design problem. Azure Backup lists disable immutability as a critical operation that a backup administrator can perform on a vault, sitting in the same table as disabling soft delete and reducing retention. To stop that, Microsoft requires a second resource called a Resource Guard, states that a different user must own the Resource Guard instance, and warns that the vault admin must not have Contributor, Backup MUA Admin, or Backup MUA Operator permissions on Resource Guard. It then recommends you place Resource Guard in a subscription or tenant that's different from the one that contains the vaults.

Microsoft also ranks the three possible arrangements by how much they protect, which turns the design into a buying question. The ladder has three rungs.

• Same subscription. Vault and guard together gives the least isolation between the backup admin and the security admin, and is the easiest rung for a provider to run.
• Separate subscriptions, one tenant. This gives medium isolation, and needs two subscriptions to administer rather than one.
• Separate tenants. This gives maximum isolation between the backup admin and the security admin, which provides maximum security, and Microsoft notes it is relatively difficult to test.

Your provider has already picked a rung for you. Almost nobody tells a buyer which one, and almost no proposal mentions that the choice exists. Ask, because the honest answer explains more about your real exposure than the brand of the backup software does.

Credential compromise is not a rare event to design around later. Verizon's 2026 breach report still puts credential abuse behind 13 percent of breaches as an initial access route, down from its previous spot as the leading one. The size of the number is not the point. The point is that a single credential is all that separates a locked copy from a deleted one when the lock and the identity live in the same place. Isolate the backup identity from the production identity, and one stolen password stops being enough.

Immutable or air-gapped? They solve different problems

Immutable and air-gapped are two different controls with overlapping jobs. Immutability stops a copy from being changed while it stays online and reachable. An air gap stops the copy from being reached at all.

The formal definition is far narrower than marketing use. The NIST glossary, quoting the national security standard, defines an air gap as an interface between two systems at which they are not connected physically and any logical connection is not automated, with data transferred only manually, under human control. Tape in a cupboard meets that definition. A cloud bucket on a private link does not, whatever the brochure says.

The UK's National Cyber Security Centre is blunt about why offline still matters against ransomware. It says that with at least one backup offline at any given time, an incident cannot affect all of your backups simultaneously, and that when your offline backup isn't in use it also needs to be digitally disconnected. People skip that second clause. A drive that stays plugged in is not offline just because somebody wrote backup on the label.

Three controls, three different jobs. The list below separates them.

• Blocks change. An immutable backup refuses a delete or an overwrite while the retention lock holds, even from a privileged account, and the copy stays online and quick to restore.
• Blocks reach. An air gap removes the network path, so an attacker cannot send the delete request at all, and recovery is slower because a person has to connect the media.
• Blocks both, partly. A logical air gap keeps the copy online but puts it behind separate credentials, separate network controls and its own retention lock. This is the usual compromise, and it is only as strong as the separation.

Most SMBs end up with a logical air gap plus a retention lock, because genuinely manual handling does not scale past a few servers. That is a reasonable answer. It is not the same answer as an air gap, and a provider who uses the two words interchangeably has told you something about how carefully the design was thought through.

Where the 3-2-1 rule sits now

The 3-2-1 rule is still the floor, and on its own it is no longer the answer. The NCSC describes it as at least 3 copies, on 2 devices, and 1 offsite, then states the part most summaries leave out, which is that it does not require any backup location to be offline.

That single clause explains why the rule aged. You back up to three destinations your own credentials can still reach, and the rule is satisfied. Three copies written by one backup job, under one set of credentials, still fall to one compromised domain administrator. Offsite is a geography word. It says nothing about who can delete the copy once it lands.

Treat 3-2-1 as the starting shape and add two properties to it. One copy carries a retention lock no administrator can shorten. One copy sits outside the identity domain that runs production. CISA and the FBI put the same idea in two sentences, telling organizations to maintain regular system backups stored separately from the source systems which cannot be altered or encrypted by potentially compromised network devices and to ensure all backup data is encrypted, immutable, meaning it cannot be altered or deleted, and covers the entire organization's data infrastructure.

A third property belongs on the list, and we argue it elsewhere rather than here. Continuous replication copies corruption to the second copy as fast as it copies good data, which is why a point-in-time snapshot and a replicated copy are not substitutes for each other. We cover that trade-off and what it costs in RTO and RPO explained.

Seven questions that separate a real immutable backup from the word

Seven questions settle it, and your provider can answer every one in a single email. Send them, keep the reply, and compare it against what the proposal claimed.

• Which mode is our retention lock in, compliance or governance? Good names the mode and the exact product setting. Weak says the storage is immutable.
• How long is the retention window on each copy, and who can shorten it? Good gives days per copy and a named person. Weak says it is set in the policy.
• Could you delete yesterday's recovery point today if we asked you to? Good says no, and explains what would refuse the request. Weak explains the ticket process for doing it.
• Which identity controls the backup repository, and is it the same one that administers our servers? Good names a separate account, subscription or tenant. Weak names their standard admin account.
• Is any copy offline or air-gapped, and how is it disconnected when not in use? Good describes the disconnection step. Weak says the copy is in a different data centre.
• What happens to a locked copy when the retention window expires? Good names the expiry behaviour and the next copy in the chain. Weak has never considered it.
• What would you hand our insurer as cyber insurance evidence that these copies are immutable? Good offers a configuration export, the lock mode and a dated restore log. Weak offers a letter.

Question four is the one that catches a good provider out, because almost nobody asks it. A provider can answer the first three correctly and still hold one administrator credential that governs the production servers and the backup repository together, which puts both behind a single password.

Question seven matters for a duller reason. Underwriters now ask what you have, and an attestation you cannot evidence is worse than a gap you declared. Get the proof into a folder before the renewal, not during it.

Best IT MSP is an independent directory. We rank providers on verified rating and firmographic data across 24,491 roster rows in 730 city datasets, we label paid placement, and we do not sell IT services, so we have no immutable storage to sell you. Put the same seven questions to three merit-ranked firms in your city and the difference in the answers is usually obvious by the second reply.

What an immutable backup does not buy you

An immutable backup does not make you safe, and no honest provider claims it does. It removes one specific failure, which is an attacker deleting your way out, and it leaves three others standing.

The lock expires by design. Amazon states that after the retention period expires, the object version can be overwritten or deleted, so the retention window you picked is the whole of your protection. Microsoft allows an interval between one day and 146,000 days, which is 400 years, which makes the choice yours and the consequence yours too. The lock retains the copy for exactly as long as you told it to and not one day more. Pick a window longer than the time it would take you to notice an intrusion, because a lock that lapses before discovery protected nothing.

Nothing is absolute, including compliance mode. Amazon's Backup Vault Lock documentation says a compliance-mode lock cannot be altered or deleted by a customer, account or data owner, or AWS as long as it contains recovery points, and that the lock only bites after a cooling-off period of at least 3 days, which is 72 hours. It then records the limit honestly. Close the account, and AWS suspends it for 90 days and then deletes the contents of your backup vault, even if AWS Backup Vault Lock was in place. A governance-mode lock, meanwhile, can have the lock removed by users with sufficient IAM permissions.

Immutability also proves nothing about recovery. A locked copy that will not boot is still a copy that will not boot, and only a timed restore test tells you which one you own. Ask your provider to verify the data in front of you and record how long it took. We cover the evidence to demand in When was your backup last restored, not just run?.

And it does nothing about theft. Coalition found that dual extortion, meaning encryption plus data exfiltration, accounted for 70 percent of all ransomware claims, and that incidents involving data theft were more than two times more expensive. A flawless retention lock still leaves a copy of your data on somebody else's server. Immutability protects your ability to keep trading. It does not protect your confidentiality, and the two need separate controls.

Start with the mode. If nobody at your provider can tell you whether your retention lock sits in compliance mode or governance mode, you already have your answer. For the service itself, see backup and disaster recovery.

FAQ

What is an immutable backup?

An immutable backup is a copy that cannot be altered or deleted for a defined retention window, by anyone, including an administrator with valid credentials. Microsoft describes the same idea as a WORM state where data can't be modified or deleted for a user-specified interval. The copy stays readable throughout, and only the retention lock expiring releases it.

Can an immutable backup be deleted?

Yes, in the looser of the two lock modes. Amazon says a governance-mode object cannot be deleted unless users have special permissions, and that the S3 console sends the bypass header by default, so a privileged delete will succeed. A compliance-mode object can't be overwritten or deleted by any user, including the root user until its retention date passes.

Is an immutable backup the same as an air-gapped backup?

No. Immutability stops a reachable copy from being changed. An air gap stops the copy from being reached, and NIST defines it as systems not connected physically where data moves only manually, under human control. Most SMBs run a logical air gap plus a retention lock, which is reasonable but is not an air gap.

Does the 3-2-1 rule still apply?

Yes, as a floor rather than a finish line. The NCSC defines it as at least 3 copies, on 2 devices, and 1 offsite and notes that it does not require any backup location to be offline. Three reachable copies written under one credential satisfy 3-2-1 and still fall to one compromised domain administrator.

How do I prove to an insurer that our backups are immutable?

Ask your provider for the lock mode, a configuration export showing the retention window per copy, the identity that controls the backup repository, and a dated restore log. Coalition reported that a record 86 percent of businesses refused to pay in 2025, crediting viable data backups and incident response plans, so the evidence pays twice.

← All Blogs