WORM

Two Different Promises People Confuse

WORM stands for Write Once Read Many: storage you can write to once and
then only read, never change or delete, for as long as the retention
period says. It is old technology, it used to mean literal optical
media you physically could not rewrite, and it is having a second life
because two modern problems, tamper-proof audit trails and ransomware,
both want the same thing: data that cannot be altered after the fact,
even by an administrator.

Before going further it is worth separating two promises that get
treated as one, because confusing them is where most WORM projects go
wrong.

The first promise is write prevention. The storage layer refuses to
overwrite or delete the data. This is what S3 Object Lock and its
equivalents give you: the API rejects any destructive call against a
locked object until its retention expires. It is a claim enforced by
the storage system.

The second promise is integrity proof. You can prove the data has not
changed, to a skeptical third party, without trusting the storage
system's word for it. This is what a cryptographic hash gives you: the
data hashes to a known value, and any change produces a different hash.
It is a claim anyone can verify.

These are not the same, and neither one implies the other. A locked
object can still be trusted only as far as you trust the lock. A hashed
record proves it did not change but does not stop anyone from deleting
it. Real immutability wants both, and knowing which one a given
requirement actually needs is the whole decision.

Where WORM Genuinely Earns Its Place

Three cases justify real write-once storage, and they share a shape:
someone who is not you, and who does not trust you, has to be able to
rely on the record later.

Audit logs and security logs. The entire value of an audit log is that
it records what happened including things people would want to erase.
An attacker who gets in wants to delete the log lines that show how. An
insider doing something they should not wants the trail gone. If the
log lives on storage the same admin can rewrite, it protects you only
against honest mistakes, not against the exact adversaries an audit log
exists for. WORM breaks that: once a line is written, nobody removes it,
not the attacker, not the insider, not the administrator, not the root
account. The log becomes evidence rather than a convenience.

Financial and transaction records. This is the oldest regulated WORM
case, and it is regulated precisely because the incentive to quietly
alter a transaction after the fact is enormous. Broker-dealer records
under the US SEC's Rule 17a-4, and equivalents elsewhere, have long
required non-rewritable retention for exactly this reason: a
transaction record you can edit is a transaction record a regulator
cannot trust. When the question is "did this transaction happen, in
this amount, at this time, and can you prove nobody changed it since,"
write-once storage is answering a real requirement, not a
box-ticking one.

Ransomware-resistant backups. This is the newest driver and the most
practically urgent. Modern ransomware does not just encrypt your live
data; the playbook now includes hunting down and destroying your
backups and snapshots first, because a victim who can restore does not
pay. An immutable backup copy short-circuits that entire tactic. If the
attacker reaches your backup storage with full credentials and the
objects are under a compliance-mode lock, the destructive calls are
simply rejected. The retention window is the guarantee that a recovery
point survives the attack. This is why "at least one immutable copy" has
become standard backup advice, and it is the one WORM case that applies
to almost everyone, not just regulated industries.

The common thread: WORM earns its place when the threat model includes
a privileged insider or an attacker with your credentials. That is
exactly the threat ordinary access controls cannot stop, because
ordinary access controls assume the privileged user is trusted. WORM
removes the ability to destroy, from everyone, including the people who
normally could.

How It Actually Works Now

You do not buy optical media anymore. Modern WORM is object storage with
a retention lock, and S3 Object Lock is the reference implementation
that everything else copies. It has two modes, and the difference
matters more than anything else in this post.

Governance mode prevents deletion and overwrite for normal users, but a
sufficiently privileged user with a specific permission can still remove
the lock. It protects against accident and against most insiders, but
not against someone with the top-level override. It is the reversible
one. Use it when you want strong protection but need an escape hatch for
genuine mistakes.

Compliance mode prevents deletion and overwrite by everyone, including
the root account, for the entire retention period, with no override
path at all. Not the administrator, not the account owner, not support
without a documented formal process. This is the one regulators accept,
because "nobody can change it" has to actually mean nobody. It is also
genuinely dangerous, which is the part people skip: a compliance-mode
lock cannot be undone. If you lock the wrong data, or lock it for a
hundred years by mistake, you are paying to store it for a hundred
years. Activate compliance mode as a deliberate change-control event,
never as a checkbox someone ticks in a hurry.

The same capability exists across the major clouds and in on-prem
S3-compatible systems, so this is not an AWS lock-in. But the mode
distinction is universal, and choosing compliance mode without
understanding that it is irreversible is the single most common
expensive mistake in this area.

The Alternative Most People Actually Want: Hash Chains

Here is the part the storage vendors are quieter about. For a large
share of "we need tamper-proof logs" requirements, you do not need
write-once storage at all. You need a hash chain, and it is cheaper,
simpler, and in some ways stronger.

A hash chain works like this: each log entry includes a cryptographic
hash of the previous entry. That links every record to the one before
it, all the way back to the start. Change any entry, even a single
character, and its hash changes, which breaks the link to every entry
after it. The tampering is not just prevented, it is detectable by
anyone who recomputes the chain. You cannot quietly alter record number
five hundred without every record after it no longer matching.

What this buys you: tamper-evidence without special storage. The log
can live on ordinary disk, in an ordinary database, and you can still
prove to an auditor that it was not altered, because the math does not
depend on trusting the storage. Publish the latest hash somewhere
external periodically, an email, a second system, a printout, and you
have even pinned down the timeline, because the chain up to that hash is
frozen by having been witnessed.

What it does not buy you: it does not stop deletion. A hash chain proves
record five was not changed, but nothing in it prevents someone from
deleting the whole log. That is the trade. Hash chains give you
provable integrity; WORM gives you enforced retention. This is why the
strongest real systems combine them: write the hash-chained log to
WORM storage, and you get both, the storage layer stops deletion while
the hash chain proves integrity independently of whether you trust that
storage layer at all. The SEC's own modernized 17a-4 now accepts
exactly this pairing, an audit-trail-with-reconstruction approach, as an
alternative to traditional pure WORM.

For most teams building an audit trail, the honest recommendation is:
start with a hash chain, because it is a library and a schema decision,
not an infrastructure project. Add WORM storage underneath it only when
the threat model genuinely includes someone deleting the log, or when a
regulator names it. Blockchain, which comes up in every one of these
conversations, is almost never the answer: a hash chain gives you the
same non-repudiation at a fraction of the cost and complexity, without
the distributed-consensus machinery you do not need for your own logs.

The Sharp Edges

WORM is not free of downsides, and pretending otherwise is how it turns
into a liability.

It fights the right to be forgotten. If your WORM store holds anything
containing personal data, and someone exercises a GDPR erasure request,
you have a direct conflict: the law says delete it, the storage says you
cannot, for years. The resolution is to keep personal data out of
immutable stores wherever possible, or to store only hashes or encrypted
references and destroy the key instead of the record. But this has to be
designed in from the start, because a compliance-mode lock over personal
data is a problem you cannot fix after the fact.

The lock protects the object, not the meaning. A storage lock prevents
overwriting the bytes. It does nothing about the retention policy
itself, the access controls, or the metadata around it, which often are
mutable. And it does not detect tampering that happens before the write
or through a bug in the provider. This is exactly why the hash matters:
the lock is a claim about write-prevention, the hash is proof of
integrity, and a serious system does not rely on the lock alone.

It is not a backup. Immutable and recoverable are different properties.
WORM stops your one copy from being altered; it does nothing if that
copy is lost, corrupted at write time, or in a datacenter that burns
down. WORM complements a backup strategy, it does not replace one. The
three-independent-layers thinking I have written about applies here too:
immutability is a property you add to a copy, not a copy you have
instead of others.

Do not WORM everything. The cost and the inflexibility are real, and
they scale with how much you lock. Over-applying WORM produces expensive
storage full of data nobody needed to make immutable and cannot now
clean up. Lock the records that genuinely need it, the audit trail, the
regulated transactions, the one immutable backup copy, and leave the
rest mutable.

The Point

WORM answers a specific question: can you guarantee this record was not
altered or destroyed after it was written, even by someone with full
control of the system. When the honest answer needs to be yes, because
an auditor requires it, because a regulator names it, or because
ransomware will come for your backups, write-once storage is the right
tool, and compliance-mode object lock is how you get it, with the
permanent understanding that compliance mode cannot be undone.

But separate the two promises before you reach for it. If you need to
prove a record did not change, a hash chain does that with no special
storage and lets an auditor verify it independently. If you need to
guarantee a record cannot be deleted, that is when you add WORM
underneath. Most audit-trail requirements are satisfied by the hash
chain alone; the write-once storage is for the cases where deletion, not
just alteration, is the threat. Reach for the lighter tool first, add the
heavier one when the threat model actually demands it, and keep personal
data out of anything you cannot unlock.