Immutable Backups Explained: Object Lock & WORM 2026

Why immutability is the control that survives when backups get hit first

Traditional backup security relies on access control: only certain admin accounts can delete or modify a backup job's retained copies. The problem is that ransomware operators increasingly compromise those same admin accounts before they encrypt anything, specifically so they can delete or corrupt the backups first and remove the defender's option to simply restore and move on.

Object Lock and WORM (write once, read many) change where the control sits. Amazon Web Services describes S3 Object Lock as protecting object versions from accidental or intentional deletion and overwrite — the protection is enforced by the storage platform itself, beneath the backup application, not by a permission flag inside it. That distinction is the entire point: an attacker with full admin rights over the backup software still cannot touch a locked object version until its retention window expires.

What exactly counts as "immutable"? WORM and Object Lock defined precisely

AWS uses a WORM model for S3 Object Lock, working together with S3 Versioning, so that locked object versions cannot be permanently deleted or overwritten. Versioning is the prerequisite: without it enabled, there is no discrete object version for the lock to attach to.

IBM's Cloud Object Storage documentation is explicit that Object Lock preserves object versions in a non-erasable, non-rewritable manner until a specified date, or until a legal hold is removed. MinIO adds the detail that matters most for auditing coverage: locking is applied per-object version, and each version is independently immutable until its lock expires or is explicitly lifted. That means immutability is not a blanket setting over an entire bucket or filesystem — it is a property of individual stored versions, which has direct implications for what you actually need to check during a compliance review.

How the lock works day to day: retention periods versus legal holds

IBM describes two protection modes under Object Lock: a retention period, which defines a fixed timeframe during which an object cannot be modified or deleted, and a legal hold, which is open-ended and stays in force until someone explicitly removes it. Wasabi's implementation mirrors this — its Object Lock prohibits modification, overwriting, or deletion of specific object versions for a configured retention period, or indefinitely.

OVHcloud states that retention can be defined in days or years, with a minimum of one day and no maximum limit at all. That flexibility matters for UK teams: you are not locked into a vendor-imposed ceiling, so retention can be set to match an incident-response window, an audit cycle, or a statutory record-keeping period, rather than whatever the platform happens to default to.

A common misconception is that a locked object can't be touched at all. Backblaze's documentation clarifies this: data can be restored on demand during the locked period, while still being protected from alteration or deletion. Immutability blocks changes and deletion — it does not block reading or restoring, which is exactly what you need it to do during a real recovery.

The UK angle: what NCSC guidance actually asks for, and what it doesn't

The UK's National Cyber Security Centre sets out 3-2-1 backup guidance within its 10 Steps to Cyber Security: three copies of data, on two different types of media, with one copy held offsite or offline-equivalent. This is a resilience principle, not a prescriptive mandate that names Object Lock or WORM specifically — but Object Lock is, functionally, the cloud-native way to satisfy that third, offsite/offline-equivalent copy without physically shipping tapes.

For UK procurement, the practical checklist follows from how the lock is enforced. First, confirm the immutability control sits below the backup software layer, at the storage platform itself — a retention flag set inside backup software alone can still be altered if the backup application's admin account is compromised. Second, check where the data actually resides; UK or nearby data residency matters for internal governance even where the brief doesn't prescribe a specific statutory location requirement. Third, get contractual clarity on exactly who can set, extend, or remove a retention period or legal hold, and whether that requires a separate authorisation path from routine backup administration. These three questions do more to determine real-world resilience than any headline feature list.

Pricing is also part of the procurement picture, not just an afterthought. If a vendor quotes price per TB or per object, buyers should confirm whether that price changes once retention or Object Lock is enabled — immutability can affect which storage class is viable, what egress fees apply when restoring locked data, and how the overall operational recovery design is costed, not just the headline backup fee.

Implementing Object Lock: a step-by-step worked walkthrough

The mechanics are broadly consistent across S3-compatible platforms (AWS, IBM Cloud Object Storage, Wasabi, OVHcloud, and self-hosted MinIO), even though the exact console workflow differs slightly by provider. The sequence below reflects the documented requirements from each.

• •Enable object versioning on the target bucket first — AWS's Object Lock explicitly depends on S3 Versioning being active; without it there is no object version for the lock to attach to.
• •Choose the protection mode for the workload: a time-bound retention period for routine backup sets that need to survive a defined incident-response window, or a legal hold for data that must stay locked indefinitely until someone explicitly removes it (per IBM's two-mode model).
• •Set the retention length to match your actual recovery and audit needs rather than a default — OVHcloud's one-day minimum with no maximum means you can dial this in precisely instead of accepting a vendor's arbitrary ceiling.
• •Confirm the lock is applying per object version (MinIO's model): each backup job that overwrites a file should be creating a new locked version while the prior version remains separately protected, not merely updating one mutable object.
• •Run a test restore while the lock is active to confirm recoverability isn't blocked — Backblaze notes explicitly that restoring is permitted during the lock, only alteration and deletion are prevented.
• •Document the authorisation path for removing a legal hold or letting a retention period lapse, so a later audit can show exactly who unlocked what, and when.

Vendor-neutral comparison: how the major platforms actually differ

Feature names vary, but the underlying enforcement model is consistent: storage-layer WORM applied to specific object versions. The real differences UK buyers should weigh are retention flexibility, self-hosted versus managed control, and how strictly the platform prevents any override during the lock.

• •AWS S3 Object Lock — WORM enforced together with Versioning; well suited to organisations already standardised on AWS-native backup tooling.
• •IBM Cloud Object Storage — offers both a fixed retention period and an indefinite legal hold, useful where some data needs a firm expiry and other data needs to stay locked until a case or investigation formally closes.
• •Wasabi — retention can be fixed or indefinite, and is often positioned as a straightforward, cost-conscious option for SMBs that don't need the full complexity of a multi-mode enterprise platform.
• •MinIO — self-hosted, per-object-version locking, giving full control over where data physically sits, which matters for UK organisations wanting the data to stay on infrastructure they operate directly.
• •OVHcloud — retention configurable from one day up to no defined maximum, giving the widest flexibility for matching lock duration to specific audit or legal-hold requirements.
• •Backblaze — explicitly states that no one, including the data owner and the provider itself, can alter or delete data during the lock, which is the strictest framing of "no override" among the sources reviewed here.

The gap nobody talks about: coverage, testing, and the missing "0"

The most dangerous assumption in an immutable backup strategy is that turning on Object Lock somewhere in the environment means everything important is now protected. It doesn't. Immutability applies to the specific object versions it is configured against, in the specific bucket it's configured on — not automatically to every backup job, every repository, or every data source across the business. A retention setting inside the backup application itself is a different thing entirely from storage-layer WORM, and the former can still be altered if the backup system's own admin account is compromised. Auditing coverage means checking, bucket by bucket and job by job, that the storage-layer lock is actually engaged where it matters, not assuming a single platform-wide toggle covers everything.

This is where the often-cited "0" in an extended 3-2-1-style rule earns its place: a locked backup that has never been test-restored is not a validated recovery point, it's an assumption. Recovery drills should specifically exercise restoring from a locked object version, confirming both that the restore works and that the retention or legal hold hasn't quietly been shortened, removed, or misapplied. Pair that discipline with the broader resilience thinking in immutable backup architectures and the practical distinctions covered in immutable vs. air-gapped backup, and size the underlying storage and retention footprint properly using a backup and DR sizing calculator before committing to a retention regime you can't easily unwind. Immutability is one control within a wider set of ransomware protection strategies — it's the last line, not the whole fence.

Sources

Every figure in this article traces to the sources below.

• •Amazon Web Services — S3 Object Lock WORM model and Versioning dependency
• •OVHcloud — Object Lock retention minimum/maximum documentation
• •IBM — Cloud Object Storage Object Lock retention periods and legal holds
• •Wasabi — Object Lock immutability and compliance documentation
• •MinIO — Object Locking per-object-version immutability documentation
• •Backblaze — Object Lock restore-during-lock and no-override policy
• •UK NCSC — 10 Steps to Cyber Security, 3-2-1 backup guidance