Data & Databases

WORM Storage (Write Once Read Many)

Term 51 of 68 in the ERPStack technical glossary

What is WORM Storage (Write Once Read Many)?

WORM (Write Once, Read Many) storage is a data storage technology that allows data to be written only once and prevents it from being deleted or modified — satisfying SEC 17a-4, FDA 21 CFR Part 11, and HIPAA audit trail immutability requirements.

WORM Storage (Write Once Read Many) at a glance

Guarantee: Write once, read many — 0 modifications and 0 deletions before the retention period ends
Enforcement: Object-lock retention in the storage layer, so even an administrator cannot shorten it
Regulatory driver: Electronic records rules such as 21 CFR Part 11, in force since 20 March 1997
Pairing: An append-only database journal for detail, WORM object storage for the sealed artefact
Built with: AWS object-lock storage provisioned with Terraform, beside an append-only PostgreSQL 18 journal written through Drizzle ORM 0.45, with RBAC and SSO over the retrieval path
Numbers that matter: 0 edits and 0 deletes before expiry; 1 retention period per record class; 21 CFR Part 11 dates from 20 March 1997; 2 layers, journal and sealed object
Compare with: An append-only PostgreSQL 18 table through Drizzle ORM 0.45, Microsoft Azure immutable blob storage, or a Redis log an administrator can flush
Commonly paired with: AWS object lock or Microsoft Azure immutable blobs, Terraform provisioning, an Immutable Audit Trail in PostgreSQL 18, RBAC and SSO on retrieval, and HIPAA, GDPR or FDA 21 CFR Part 11 Compliance retention rules
Retention conflict: 1 GDPR erasure request against a 7-year retention lock needs a documented decision, not a 0-thought default
Regimes that require it: HIPAA retention, FDA 21 CFR Part 11 Compliance, FERPA Education Compliance and SOC 2 or ISO 27001 evidence — 4 regimes reading the same sealed object.
Where the sealed copy lives: AWS object lock or Microsoft Azure immutable blobs provisioned with Terraform, indexed from PostgreSQL 18 through Drizzle ORM 0.45, retrieval gated by RBAC and SSO.

How WORM Storage (Write Once Read Many) works in production

For financial institutions, healthcare providers, and government contractors, regulatory frameworks mandate that audit records cannot be altered or deleted — even by system administrators. WORM storage satisfies this requirement through AWS S3 Object Lock, Microsoft Azure immutable blob storage, or cryptographic append-only log tables in PostgreSQL. Any attempt to modify or delete a locked object returns an error at the storage layer itself.

The ERPStack approach to WORM Storage (Write Once Read Many)

We configure AWS S3 Object Lock policies in Governance and Compliance mode for all audit log exports, satisfying SEC 17a-4 and FDA 21 CFR Part 11 requirements for immutable record retention.

Related Resources

Frequently asked questions about WORM Storage (Write Once Read Many)

What does Write Once Read Many storage guarantee?

That an object cannot be altered or removed until its retention period expires, regardless of who asks. The Read Many model matters because ordinary access control is revocable — an administrator can always change a permission — whereas an object lock is enforced by the storage service itself. That difference is what makes the record credible to an auditor rather than merely well-intentioned.

Why isn't an append-only table enough?

Because a table can be dropped. An append-only journal in PostgreSQL 18 is excellent for detail and querying, but anyone with database administration rights can alter it. A Read Many object store with a retention lock removes that possibility for the sealed artefact. Most regulated designs use both: the journal for working history, immutable storage for the record that must survive scrutiny.

Which regulations drive WORM requirements?

Electronic record rules, primarily. FDA 21 CFR Part 11, published at 62 FR 13464 on 20 March 1997, governs electronic records and signatures for regulated life-science processes, and similar retention expectations appear in financial and legal contexts. What they share is a demand that a record be attributable, contemporaneous and unalterable — the Read Many property is the storage-level answer to the last of those.

How long should records be retained?

Exactly as long as the governing rule requires, and no longer. A Read Many lock is deliberately irreversible, so an over-long retention period is a commitment you cannot undo — including for personal data that a subject may later ask you to erase. Setting the period per record class, from the actual regulation rather than a default, is the part teams most often get wrong.