WORM storage and legal hold: when you need write-once archives
Most document archives are mutable. A file stored on a standard file system or object store can be overwritten, deleted, or silently modified by anyone with the right permissions, including system administrators. For most operational purposes, this is fine. For regulated document retention, it creates a problem: you cannot credibly assert that an archived document is unaltered if the system that stores it could have altered it.
WORM storage and legal hold are the two mechanisms that address this at the storage layer.
What WORM means
WORM stands for Write Once, Read Many. A WORM storage system accepts a write exactly once for each object. After the write is committed, the object cannot be modified, overwritten, or deleted until the configured retention period expires.
This is a physical or logical constraint at the storage layer, not an access control policy. The difference matters: an access control policy can be changed by an administrator. A WORM constraint cannot be circumvented by reconfiguring permissions because the write-once property is enforced by the storage system itself, not by a policy layer on top of it.
Hardware WORM: optical media (CD-R, BD-R), certain enterprise tape formats, and specialized WORM disk arrays enforce this at the physical level. Once written, the data cannot be altered regardless of what software is running on top.
Object storage WORM (software-enforced): most modern S3-compatible object stores support an “Object Lock” mode that implements WORM semantics in software. When Object Lock is enabled with a retention date, the storage API refuses delete and overwrite requests for that object until the retention period expires, even for requests made with administrative credentials.
Retention modes
WORM-capable object stores typically offer two retention modes:
Governance mode: administrators with a specific permission can override the retention lock. Useful for correcting mistakes during the initial retention period setup. Not suitable for regulated archives because it preserves administrative override capability.
Compliance mode: no user, including the root account, can delete or modify the object before the retention date. The retention period can be extended but not shortened. This is the mode required for regulatory compliance in most jurisdictions.
The distinction is significant in audits. An auditor asking “could this document have been modified after archiving?” should get the answer “no, technically impossible” not “no, only admins could have, and we trust our admins.”
What legal hold means
Legal hold (also called litigation hold) is a separate mechanism from retention. Retention defines how long a document must be kept. Legal hold suspends deletion for a specific document regardless of whether the retention period has expired.
When an organization receives a court order, regulatory inquiry, or is notified of potential litigation, it has a duty to preserve all relevant documents. Legal hold enforces this preservation automatically: documents under hold cannot be deleted even if their standard retention period has lapsed.
The hold is lifted by explicit release, typically by legal counsel, once the matter is resolved.
Operationally, legal hold requires tagging documents at the metadata level and having the storage system enforce the tag. In object storage with WORM capabilities, this is usually implemented as an indefinite hold flag alongside the timed retention period.
When WORM is required
Regulatory requirements for immutable storage are sector-specific but increasingly common.
Financial services (EU): MiFID II requires that records of transactions and communications be stored in a format that prevents modification. The requirement is explicitly for tamper-evident storage, which WORM satisfies. Retention periods are five years for most transaction records, seven years for some categories.
Healthcare: GDPR combined with sector-specific rules (in Germany, the Patientendatenschutzgesetz) requires that medical records be retained for 10 to 30 years depending on type, in a form that guarantees integrity. WORM is the most defensible implementation.
Public sector: Many EU member state procurement regulations require that contract documentation be archived in immutable form for the duration of the limitation period plus the retention period, which can exceed 15 years.
Accounting (GoBD, Germany): GoBD requires Unveränderbarkeit (immutability) for archived accounting documents. The guidance explicitly states that archived documents must be protected from subsequent modification. WORM storage satisfies this requirement by design.
WORM does not replace hash chains
WORM storage proves the stored bits have not changed since writing. It does not prove what process produced those bits, or that the process was correct.
A hash chain proves the sequence of processing events was consistent and unmodified. It does not prevent the underlying storage from being modified (unless the storage is also WORM).
Together, they address different threat models:
| Mechanism | What it prevents |
|---|---|
| WORM storage | Post-write modification or deletion of archived files |
| Hash chain | Retroactive falsification of the processing history |
| RFC 3161 timestamp | Backdating of documents or events |
A fully defensible long-term archive uses all three: WORM for the storage layer, hash chains for the audit trail, and RFC 3161 timestamps as external time anchors. Each layer closes gaps the others leave open.
Evidence portability
One risk specific to WORM archives is vendor lock-in at the storage layer. If your WORM implementation uses a proprietary format or a proprietary API, migrating to a different storage provider before the retention period expires may be impossible or legally risky.
The safest architecture separates the evidence from the storage mechanism: the evidence (document + hash chain + timestamps) is self-verifiable regardless of where it is stored. The WORM property ensures it was not modified after archiving, but the evidence pack proves integrity even if the WORM property could theoretically be circumvented.
This means the evidence pack format and the storage format should be chosen independently. PDF/A-3 for documents, standard JSON for audit trails, and RFC 3161 tokens in their standard CMS encoding are all format-independent. They verify with open-source tools without requiring the original storage system.
SealDoc and immutable archiving
SealDoc’s archive mode writes documents to WORM-compatible object storage with compliance-mode retention locks. The retention period is configurable per document type: seven years for invoices, ten years for contracts, custom periods for sector-specific requirements.
Documents stored in archive mode combine WORM storage with hash-chain audit trails and RFC 3161 timestamps, giving three independent layers of tamper evidence. Legal hold can be applied via the API and lifts only on explicit release.
The Legal Evidence Pack generated at archiving time is itself stored under WORM retention, ensuring the evidence artifacts are as immutable as the documents they cover.