Immutable backup: what the word actually guarantees

An immutable backup is a copy that the storage layer refuses to alter, overwrite or delete until a defined date has passed — not because permissions forbid it, but because the storage will not accept the operation from anyone. Microsoft's documentation states the formal definition plainly: immutability is storage that cannot be altered, deleted, or overwritten for a specified period of time. That matters for ransomware for one narrow reason. An attacker who reaches your tenant arrives holding valid credentials, and almost every native safety net in Microsoft 365, Google Workspace, Slack and Atlassian Cloud is scoped by permissions. Immutability is the one property that does not care how privileged the attacker is. It is also a word applied to plenty of things that do not meet the definition, so here is how to test the claim.

Three things have to be true at once

A backup copy is immutable only if all three of these hold:

1. The restriction lives in the storage, not the application. A greyed-out delete button in a console is an application check, and application checks are bypassed by talking to the API underneath. Immutability means the storage itself rejects the write, whichever client issues it.
2. There is a defined period, and it ends. Immutability is always time-bounded — there is a retain-until date. "Immutable forever" is either a commercial commitment dressed up as a technical one, or loose language; it also collides with the deletion obligations you carry under GDPR.
3. It survives the highest privilege in the system. This is the test that separates real implementations from soft ones, and it is the one most often quietly failed.

WORM — write once, read many — is the older name for the same idea, and you will still see it in compliance documentation. It describes the behaviour rather than the mechanism.

Governance or compliance: the setting that decides whether it is real

S3 Object Lock is the most widely documented implementation of this model, and the reference point a great many backup platforms build on, so it is a useful way to see what the word conceals. It makes the critical distinction a configuration choice rather than a marketing adjective, with two retention modes:

• Governance mode. Users cannot overwrite or delete a protected version or alter its lock settings unless they hold special permissions. It stops ordinary accounts and ordinary mistakes. It does not stop someone who holds those permissions — or has stolen an identity that does.
• Compliance mode. A protected version cannot be overwritten or deleted by any user, including the root user of the account. The retention mode cannot be changed and the retention period cannot be shortened. The only thing that releases the object is the passage of time.

Separately, a legal hold can be applied with no retention period attached at all. It prevents overwrite and deletion and stays in force until someone explicitly removes it, which makes it a different tool for a different job — evidence preservation rather than ransomware resilience.

The practical upshot: if a provider tells you backups are immutable and does not tell you which of these models is in force, you have not been told the part that matters. The follow-up is a single sentence. Can anyone in this system shorten a retention period or destroy a copy before its date — and if so, who?

Why an immutable backup matters for ransomware, and not much else

Ransomware against SaaS rarely looks like an intrusion. Encryption arrives authenticated — through a sync client holding a valid token, an OAuth grant an employee approved, or an administrator account bought from a broker. Every action the malware takes is an action that credential was entitled to take.

That is precisely why native safety nets underperform at the moment you need them. The OneDrive and SharePoint recycle bin gives you 93 days from the original deletion, but it is a bin, and a sufficiently privileged account can empty it. Retention settings can be edited by whoever administers retention. Version history can be exhausted by an attacker who simply writes enough versions. None of these were designed against an adversary who owns the credentials; they were designed against accidents.

Immutability changes the question from did the attacker have permission to has the retention period expired. That is a much duller question, and duller is the entire point.

One thing should be said plainly, because the marketing around this word is not careful about it: immutability does not stop an attack. It does not detect one, it does not prevent your live data being encrypted, and it does not shorten an incident. It decides exactly one thing — whether a clean copy still exists when you go looking for it.

What the four platforms actually give you

None of Microsoft 365, Google Workspace, Slack or Atlassian Cloud ships storage-level immutability as part of ordinary native recovery. What each gives you is a time-boxed, permission-scoped undo. Walking the gap is worth the paragraphs, because this is where most buying decisions are actually settled.

Microsoft 365 is the most interesting case, because Microsoft documents the nuance honestly and most summaries of it do not. The Microsoft 365 Backup add-on stores restore points on append-only storage, so existing backup data cannot be modified or overwritten by the service. But Microsoft's own page draws the line explicitly: the product follows the immutability definition except for disallowing deletion. Deletion is deliberately left available so customers can offboard, with a fixed 90-day grace period to recover backups afterwards and multi-admin notifications as a guard — described as approximating full immutability rather than delivering it. Elsewhere on the same page the backups are summarised as immutable unless expressly deleted by the Backup tool admin, which is true, and is also the whole question restated. We covered the add-on's other boundaries in what Microsoft 365 backup actually covers.

Microsoft does ship one genuinely lock-like control, and it deserves to be better known: Preservation Lock on a Purview retention policy. Once applied, nobody — including a global administrator — can turn the policy off, delete it, or make it less restrictive. It can only be extended. Microsoft positions it for regulatory requirements and to help safeguard against rogue administrators, and deliberately keeps it out of the admin UI: you apply it through PowerShell, and you cannot undo it afterwards. It is not a backup — it is a retention control, it protects what the policy scopes rather than an independent copy, and it will not help you if the tenant itself becomes unavailable. But it is the closest native thing to compliance-mode enforcement inside Microsoft 365, and if your objection to immutability has been "an admin can always undo it", this is the counter-example.

Google Workspace gives administrators a 25-day window to restore a deleted user's data, plus the ordinary trash windows, and Vault states outright that it is not a data archive — it exports, it does not restore. Neither mechanism is immutable in any sense: both are administrative functions, available to administrators. How to back up Google Workspace sets out what each of the four available routes does and does not cover.

Slack and Atlassian Cloud sit further from the idea again. A Slack export is a point-in-time file that you are then responsible for storing, so whatever immutability it has is whatever you give the destination. Atlassian's native exports behave the same way — the export is a file, and the file is your problem.

The pattern across all four is consistent. The platform guarantees the availability of your data and gives you a short undo. Where an independent copy lives, how long it is pinned, and who can destroy it early are questions the platform hands back to you — the same shared responsibility split that decides everything else about SaaS recoverability.

Six questions to ask before you accept the word

1. Which enforcement model is in force? Governance-style, where a privileged override exists, or compliance-style, where nobody has one? Get the answer in writing rather than in a slide.
2. Who can shorten a retention period? If the answer is "an administrator can", the immutability is a policy rather than a property.
3. What happens on offboarding or non-payment? Many implementations release or purge copies when the commercial relationship ends. That is exactly the moment an attacker holding your billing identity will choose.
4. Is the copy in a separate trust boundary? An immutable copy living inside the tenant it protects shares that tenant's fate — a lapsed subscription, an administrative compromise, a tenant-level problem.
5. Which workloads does it actually cover? Immutability that covers files but not chat, mail, issue history or permission structures covers the part that was easy.
6. When did you last restore from an immutable copy? Immutability guarantees the bytes are still there. It says nothing about whether you can get them back into a working state, or how long that takes.

The last question is the one almost nobody asks, and it is the one an incident answers for you. A copy you have never restored from is a belief, not a control — and the difference only ever surfaces on the worst day.

Where we fit

We are not the platform and we do not run your tenant. What we do is work out what your real recovery requirement is — which workloads carry risk, how far back you must be able to go, how independent the copy has to be, and which enforcement model your compliance position actually needs — then help you choose the right fit for your stack and get it deployed and running. You own and operate it from there.

If you would rather have the immutability question answered against your own environment than in the abstract, a recovery assessment walks your workloads, your retention obligations and your current native windows, and shows you where the gap really is.