Immutable Backups, Precisely: Append-Only Is Not Deletion-Proof

Most backup failures are not hardware. They are a human with valid credentials — a ransomware operator who has phished a Microsoft 365 global administrator, or a departing engineer with standing access. Such a person does not need to defeat your backup; they only need to reach it. If your backups sit inside, or are deletable from, the same tenant and the same identity plane as the data they protect, then the moment those credentials are compromised, the backup is compromised with them. The recovery plan and the thing it depends on share a single point of failure.

What "immutable" actually means

Immutability is a specific technical property, not an adjective. On object storage it is implemented as WORM — write once, read many — through a mechanism called Object Lock. When a backup object is written, the storage layer stamps it with a retain-until date. Until that date passes, the object cannot be overwritten and cannot be deleted: the storage service itself refuses the operation and returns an access-denied error, regardless of who issues it. It is enforced below the permission layer — not a permission you can grant yourself out of.

Compliance mode versus governance mode — this is the whole ballgame

Object Lock has two modes, and the difference is who — if anyone — can override the lock before it expires.

In governance mode, the lock holds against ordinary deletes, but a sufficiently privileged operator holding a special bypass permission can still remove the object. In compliance mode, no one can shorten or remove the lock before it expires — not an administrator, not the storage-account root, not the backup vendor. The trade-off is that compliance mode is irreversible by design, which is exactly the point: a backup you can be argued or coerced into deleting is not one you can rely on in the worst case.

Append-only is not deletion-proof

This distinction trips up a lot of "immutable-ish" claims. A store can be append-only — you can add new versions but not modify old ones — while still permitting deletion of what is there. Microsoft says exactly this about its own native Microsoft 365 backup: it follows the definition of immutability "except for disallowing deletion... Deletion of the backups isn't blocked, giving customers the option to offboard if needed or desired." (Source: Microsoft, "Overview of Microsoft 365 Backup," Microsoft Learn — "Append-only vs. immutable storage overview," as of 4 September 2026.)

Append-only protects against silent tampering — old versions cannot be quietly rewritten. It does not, on its own, stop a privileged actor from deleting the copy outright. Deletion-proof requires the lock to refuse the delete itself. The two words are not synonyms, and the gap between them is exactly where a compromised administrator operates.

Immutable, but not forever: retention and disposition

Immutability is sometimes misread as "keep everything forever," which is both expensive and, under data-protection law, wrong. The correct property is narrower and more useful: a restore point cannot be altered or deleted before the retention period you set has lawfully expired. When that period ends, the data should be disposed of — and disposed of provably.

The evidence-grade way to dispose of data that is still under a lock is cryptographic erasure: destroy the encryption key so the ciphertext is permanently unrecoverable, and issue a destruction certificate that records what was disposed of, when, and by what method, chained into a tamper-evident audit trail. Immutability protects the data during its lawful life; disposition ends that life on schedule, with proof — not a log line that says "deleted."

Independent and immutable — both, or neither counts

Immutability inside the same trust boundary as the primary data is worth less than it looks. If the immutable copy shares the primary tenant's region, its identity plane, and its fate, then a boundary-wide compromise or a region-level event takes both. The property worth paying for is an independent copy — outside the primary tenant, under separate keys the primary's administrators do not hold — that is also immutable. Independence without immutability can still be deleted; immutability without independence can still share the primary's fate. You need both.

Five questions to ask a backup vendor

1. Is the backup written to WORM / Object Lock storage, and in which mode — governance or compliance?

2. Can anyone — including the vendor — delete a restore point before its retention expires? (The answer you want is no. Compliance-mode Object Lock guarantees it outright; a governance-mode lock achieves the same in practice only if the vendor's software never issues a bypass-delete — so ask which safeguard they actually rely on.)

3. Is the copy independent of the primary tenant's identity and region?

4. When retention lawfully expires, how is data disposed of — and is there a destruction certificate?

5. Is "immutable" the default, or an add-on you have to remember to switch on?