Immutable Backups Explained: WORM, Retention Locks and Why They Matter

“Immutable” has become a checkbox on every backup data sheet. But immutability comes in different strengths — and the details decide whether your backups survive an attacker with admin rights.

What immutability means

Immutable backups are stored so they cannot be modified or deleted until a retention period ends. This is often called WORM — write once, read many.

Where immutability can live

• Storage-level locks on appliances or object storage (for example S3 Object Lock).
• Platform-level immutability built into the backup software.
• Hardened repositories that restrict who can change retention.

Governance vs compliance modes

Many platforms offer a flexible mode that privileged administrators can override and a strict mode that nobody — including the vendor — can shorten. Strict mode is stronger, but must be planned carefully because mistakes cannot be undone.

Questions to ask

1. Who can shorten retention or disable the lock?
2. Is the system clock protected from tampering?
3. Are immutable copies kept long enough to outlast attacker dwell time?
4. Is at least one immutable copy isolated from production credentials?

Immutability is necessary, not sufficient

Immutability stops existing backup copies from being changed. It does not stop an attacker from disabling future backup jobs, poisoning new backups with malware, or simply waiting until retention expires. That is why immutability should sit alongside strong access control, monitoring of backup activity and an isolated copy of critical data.

It also matters where the lock is enforced. A lock enforced by the storage itself is generally harder to bypass than one enforced only by backup software that an administrator can reconfigure.

• Monitor for failed or disabled backup jobs as a possible attack indicator.
• Review retention settings after every platform upgrade or policy change.
• Test that you can actually restore from the immutable tier.