Your immutable backup has a permission that deletes it

"Our backups are immutable." A lot of security meetings end on that sentence, and it is an incomplete one. Immutable is not a property of the product: it is a retention mode, a period and a list of who is allowed to override it. Change any of the three and the same word describes two different situations.

Everything that follows is in the vendors' public documentation. In Amazon S3, the same feature —Object Lock— offers two modes. In one, not even the account's root user can delete. In the other, anyone holding one specific permission can delete, and the AWS web console sends, by default, the header needed to override it. Both are called immutability. Both look equally green on the monthly report.

93% ask for it, 16% say they have it

On 1 September, Omdia published a study with a figure that has travelled a long way: 93% of the leaders surveyed regard absolute immutability in backup storage as a critical requirement against ransomware, and only 16% say their current environment meets that standard. There is another figure in the same study that we find more interesting and that has stayed out of the headlines: 89% say a vendor's immutability claims cannot be taken at face value without third-party validation.

Before using those numbers, the study deserves two caveats. First: it is commissioned and paid for by Object First, which sells an immutable storage appliance, and which Veeam acquired in January 2026. That does not make the answers false —Omdia does the fieldwork— but it does shape which questions get asked and which headline gets pushed. The second caveat matters more to you: the sample is 700 people at organisations with 1,000 to 9,999 employees in the US, UK, Ireland, France and the DACH region, interviewed between late February and late March 2026. Not one Spanish SME. If your company has forty people, that 16% is not describing your house.

What does carry over is the shape of the gap: the distance between what people believe they have and what they have configured. And that distance does not close by buying anything. It closes by reading three things that are already written down somewhere: the mode, the period and who holds the exception.

Two modes that sound identical in conversation

Amazon S3 Object Lock is the mechanism nearly every S3-speaking backup product leans on, so its documentation is worth reading slowly. There are two retention modes, and the difference is not one of degree:

That header requirement sounds like deliberate friction: you have to ask for it separately, by hand, on purpose. But AWS's own documentation adds a note that switches it off in the most common case. Verbatim: "By default, the Amazon S3 console includes the x-amz-bypass-governance-retention:true header. If you try to delete objects protected by governance mode and have the s3:BypassGovernanceRetention permission, the operation will succeed."

So if that identity holds the permission and somebody opens the web console and hits delete, it gets deleted. No manual header, no special warning, no dialogue different from the one for any other file. The friction exists in the API and vanishes in the interface where almost everything gets done at three o'clock on a Friday afternoon.

Governance mode is well designed and does what it promises. AWS explicitly recommends it for testing retention periods before committing to compliance mode, and for cases where somebody does need to be able to correct a mistake. What breaks happens earlier: the test mode and the final mode have the same name in the meeting and differ only in the configuration.

Three more details from the same page, and the first is the one most often got wrong. The retention period can always be extended by anyone with s3:PutObjectRetention; shortening it is only possible in governance mode and with the override permission —the bypass header sits in the signature of that very call— whereas in compliance mode it can never be done. Second: a legal hold, which locks with no expiry date, "can be freely placed and removed by any user who has the s3:PutObjectLegalHold permission". And third, the one almost nobody mentions: there is a variable retention with event holds that AWS recommends in so many words for "a configurable recovery window against ransomware or accidental deletion", fixing the date when you release the hold.

The mode that does hold has a bill attached

The temptation, having read that, is to put everything in compliance mode and sleep soundly. It is worth knowing what you are signing. In that mode, if you get the retention period wrong you pay for that storage to the end: there is no way to shorten the period or free the space. And the blast radius moves: the only remaining lever for destroying that data early is closing the account. Your backups stop depending on the backup server's credentials and start depending on nobody touching —or losing, or failing to pay for— the account that hosts them.

We wrote it ourselves in July, about the wiping of the Romanian land registry: design your backup assuming the attacker already has the admin credentials. That sentence is right and it falls short, which is why we are coming back to it. Saying "immutability" there is the start of the conversation, not the end. The joint advisory on Gunra that we covered in August describes attackers who deleted backup data at both the primary and the disaster recovery site, before and after deploying the encryptor. Against that playbook, a repository in governance mode with the bypass permission handed out inside the domain they have just compromised becomes one more step on their list.

The obvious check returns the wrong answer

Suppose you want to check it yourself, which is exactly what that 89% who distrust vendor claims are asking for. The intuitive test is to try deleting an object and see whether it lets you. That test lies, and the documentation says so: if you issue a simple delete, without specifying the version ID, S3 returns 200 OK and places a delete marker on top. The object is still there, intact and protected, but what you saw was the response of a successful deletion.

The mistake runs in both directions. Whoever ran the test walks away convinced immutability is broken and opens a ticket nobody needed. And the attacker who deletes that way walks away convinced of the opposite. Name the version and you do get a useful answer: a permanent delete against a protected version returns 403 Forbidden. That 403, though, confirms a lock exists without telling you which kind —an object in compliance mode and one in governance mode probed by somebody without the override permission both return it—. The mode is not deduced from a deletion: you read it with get-object-retention and get-object-lock-configuration.

And one precondition that is obvious and still gets forgotten: Object Lock only works in buckets with versioning enabled. Without versioning there is no retention at all, because it never comes into existence.

Your policy's period is not the real period either

The third setting is the period. Veeam applies a mechanism to object repositories called block generation: it groups the blocks written within one window so they share an expiry date, so the lock on older blocks does not have to be rewritten every night. The reason is cost —fewer API calls, less traffic— and the effect is that this period is added to the one you configured. In the documentation for its Windows agent that is 30 days on Amazon S3 and Google Cloud Storage and 10 days on other object stores; the list varies by product and provider, so the number that applies to you has to be read in your own version rather than in this paragraph.

With those values, you set 30 days of immutability on S3 and what is written on the object is 60: more protection than you asked for and also more storage than you budgeted, for twice as long. The number you wrote in the policy is not the number on the object, and here the difference works in your favour. It does not always.

And where does the Microsoft 365 backup land?

We already covered how Microsoft 365's native backup never leaves Microsoft, which is a design limitation rather than an oversight. When you buy a real third-party backup, that data ends up written somewhere, and that somewhere is usually object storage with the same three dials: mode, period and permissions.

The purchasing conversation, though, stops one step short. People talk about retention —seven years sounds right, although that figure does not come from the GDPR, which sets no periods and in fact requires the opposite, but from commercial and tax law— and not about mode. They are different things: retention says how long the data is kept; mode says who is allowed to shorten that. In a Microsoft 365 backup, the mode and the period have to be written into the handover alongside the retention. If they are not, the word "immutable" in the contract cannot be verified.

The sentence whoever runs your backups has to be able to finish

You do not need an audit or a tool. You need a sentence with four blanks. Ask whoever operates your backups —your team, your provider, or us if we are the ones running them— and listen to how long they take:

If it takes more than a minute, you already have your answer. Not because they are bad at their job: because those four values live in four different places —the backup product's policy, the bucket configuration, the IAM policy and the credential store— and they have almost never been looked at together. The last blank is the one most people skip, and it decides everything: if those credentials live in the same directory as the rest of the company, the attacker who owns the directory also owns the bypass permission.

When none of this applies to you

A post that opens with a study sponsored by a maker of immutable appliances ought to end by telling you to buy one. We are not going to do that. If your backups end up on a tape that somebody ejects and puts in a cupboard, you have absolute immutability and it cost you neither a licence nor an IAM policy: an object connected to nothing cannot be deleted over the network. It is inconvenient, it is slow to restore and somebody has to remember to eject it; it is also the only mode with no checkbox that switches it off.

And we say this knowing which side we get paid on: we sell managed backup and disaster recovery, so a post titled "your backups are not what you think" suits us. Hence the counterweight: if you can finish the sentence above without asking anybody, the hard part is done and you need to hire nothing. The one with the problem is whoever finds out the bucket's mode on the day they go to restore.

What we are not claiming

Sources (verified on 29 September 2026): the compliance and governance retention modes, the s3:BypassGovernanceRetention permission, the note about the header the console includes by default, variable retention with event holds recommended against ransomware, legal holds and s3:PutObjectLegalHold, the rule that a retention period can only be shortened in governance mode and with the override permission, the versioning requirement, and the behaviour of a simple delete (200 OK plus marker) versus a permanent one (403) — Amazon S3 documentation, "Locking objects with Object Lock"; the block generation period of 30 days on Amazon S3 and Google Cloud Storage and 10 days on other object stores, and its stated purpose (fewer requests, less traffic, lower cost) — Veeam documentation for the Windows agent, "Block Generation"; the study figures (93% / 16%, 89% requiring third-party validation) — the Object First-sponsored Omdia study release (1 Sep 2026), with the methodology (700 respondents, organisations of 1,000 to 9,999 employees in the US, UK, Ireland, France and DACH, fieldwork between 26 February and 25 March 2026) as reported by Compare the Cloud; Veeam's acquisition of Object First, confirmed on 14 January 2026, and the company's founding in 2022 by Ratmir Timashev and Andrei Baronov — Blocks & Files.