WORM (Write Once, Read Many) and immutability get used as synonyms, and they are not. Both stop data being changed after it is written, but one is a property of storage and the other is an outcome you design for, and the difference decides what you can actually buy. Here is what separates them, and how Catalogic vStor uses both.
What Is WORM?
WORM is storage that accepts a write once and refuses every later attempt to change or remove it, for as long as its retention term runs. Finance, healthcare and legal all have rules requiring records to survive unedited for a defined period, which is where it earns its keep.
WORM in Action
WORM started in hardware, where the guarantee came from physics. Write-once optical media and LTO WORM tape cartridges cannot be rewritten because the medium will not allow it.
Most WORM in use today is enforced by policy instead: S3 Object Lock, Azure immutable blob storage, and filesystem-level controls that refuse the write. That is weaker in principle, since correct software rather than physics is doing the enforcing, and far more practical, because policy can be scoped to a retention period rather than applied to an entire cartridge.
A financial institution uses WORM storage to keep transaction records unalterable for a mandated retention period. That is what rules such as SEC Rule 17a-4, FINRA and SOX are asking for: records that can be produced later and demonstrably have not been edited.
GDPR is the interesting counter-example, and it is often cited here by mistake. GDPR grants a right to erasure, so blanket immutability works against it rather than for it. Retention periods and scoping matter precisely because the two obligations pull in opposite directions.
What Is Immutability?
Immutability is the property of data that cannot be changed after it is written. Where WORM names a storage behaviour, immutability names the guarantee, and several different mechanisms can deliver it. That distinction is why the two words are not interchangeable even though they describe overlapping things.
Immutability in Action
Immutability can be applied at various levels within a storage environment, from file systems to cloud storage solutions. It often works alongside advanced technologies like snapshotting and versioning, which create unchangeable copies of data at specific points in time. These copies are stored separately, protected from any unauthorized changes.
For instance, a healthcare organization might use immutable storage to keep patient records safe from alterations. Once a record is stored, it cannot be modified or erased, helping the organization comply with strict regulations like HIPAA and providing a trustworthy source for audits and reviews.
WORM vs. Immutability
WORM is one way to implement immutability; it is not the only one. Immutability can be enforced by software-defined controls in the storage layer, by object-lock policies in cloud architectures, or by snapshot protection in a backup repository. The useful way to hold the distinction: WORM describes what the storage refuses to do, immutability describes the outcome you want.
A healthcare provider protecting patient records runs into the obvious objection: records get amended. Immutability handles that by versioning rather than editing. The amended record is written as a new version and the earlier one stays intact and readable, which is what makes the audit trail worth having.
Key Differences Between WORM and Immutability
- Scope: WORM is a specific method for making data unchangeable, while immutability refers to a broader range of technologies and practices.
- Implementation: WORM is often hardware-based but can also be applied to software. Immutability is typically software-defined and may use various methods, including WORM, to achieve its goals.
- Purpose: WORM exists mainly to satisfy retention rules, keeping data unchanged for a set period. Immutability is aimed at integrity and security more broadly, which is why it shows up in ransomware defence rather than only in compliance conversations.
Catalogic vStor: Immutability and WORM in Action
Catalogic vStor applies WORM-style protection through software rather than through the medium, which is where the two ideas meet in practice.
How vStor implements it
Protection is applied as a deletion lock, and it is deliberate rather than automatic. You place a lock on a snapshot, a volume, or an individual file within a volume, and you set a retention period that defines how long it holds.
There are two kinds, and the difference is who can undo them:
- Fixed protection cannot be changed once set. It releases when the retention period expires and not before, which is the closest software equivalent to a WORM cartridge.
- Flexible protection covers the same retention period but can be adjusted or removed, authenticated with an MFA code.
This is the same protection layer described in detecting and preventing ransomware attacks from spreading, viewed from the storage side rather than the detection side.
That MFA requirement is doing real work. The common ransomware pattern is not defeating encryption, it is acquiring administrator credentials and then using the backup console the way an administrator would. Requiring a second factor before protection can be lifted breaks that path.
Replicated data can carry protection too, applied on the target as snapshots arrive. This matters because replication on its own moves a copy without protecting it, and a second copy that can be deleted as easily as the first is not the insurance the architecture diagram implies.
Why Choose Catalogic DPX with vStor Storage?
Catalogic DPX with vStor gives the backup repository WORM-style guarantees without the hardware that traditionally carried them.
- Against ransomware: a locked recovery point cannot be removed by an attacker holding administrator credentials, which is the specific failure that turns an incident into a catastrophe. Pair it with GuardMode to find out whether the recovery point is clean as well as intact.
- For retention rules: locks carry explicit retention periods, so records stay unchangeable for a defined term rather than indefinitely. Whether that satisfies a particular regulation is a question for your auditor and the specific rule, not something any storage vendor can answer for you.
- Without specialised hardware: vStor is software-defined, so WORM-style protection applies to storage you already run.
Securing Your Data’s Future with DPX & vStor
The short version: WORM describes what the storage refuses to do, immutability describes the guarantee you are buying, and WORM is one way to deliver it. Asking a vendor “is it immutable?” is less useful than asking what applies the lock, how long it holds, and who can lift it early.
For the mechanism in more depth, what is immutable storage covers deletion locks and, more usefully, what immutability does not protect against. For the product view, see immutable storage for backups or request a demo.
Pawel Staniec
CTO
Pawel is CTO at Catalogic Software, where he owns DPX product architecture and technology direction and works with our developers, alliance partners and customers across EMEA to keep what we build aligned with how our data protection products are actually deployed. He writes about the engineering behind our releases, including NDMP backup management, Proxmox VE protection, and where hypervisor-native backup tooling stops being enough.
