Regulated archive storage holds records that an organization is legally required to keep, unaltered, for a set period: trade confirmations, patient files, clinical trial data, tax documents, communications. The storage requirement sounds simple and has two halves that are easy to confuse. The records must be immutable, meaning nobody can change or delete them. And they must be retained for a defined period, meaning they stay for at least that long and, under most privacy regimes, no longer than is justified. Getting one right without the other is a common finding in audits.
This post explains how immutability and retention work together in a regulated archive, how object storage implements them and what auditors look for. It is a general overview and not legal advice. Specific obligations vary by sector and jurisdiction.
Immutability is about integrity. It guarantees that a record, once written, is the same record when it is read years later. Retention is about time. It guarantees that the record exists for the required period and defines when it may be removed. A system can be immutable with no retention schedule, in which case records accumulate forever. A system can have a retention schedule with no immutability, in which case an administrator can alter a record or delete it early.
| Requirement | What it means | How object storage meets it |
|---|---|---|
| Non-rewritable, non-erasable | Records cannot be changed or deleted during retention | Object Lock in compliance mode |
| Defined retention period | Each record is kept until a known date | Retain-until date per object, or a bucket default |
| Preservation for legal matters | Deletion suspended when litigation is anticipated | Legal hold flag, independent of retention |
| Integrity verification | Proof that content has not degraded | Checksums verified on read and by background scrubbing |
| Accurate time | Retention measured against a trustworthy clock | Protected time source on the storage system |
| Audit trail | A record of access and administrative actions | Access and audit logging, kept separately |
| Disposal at end of retention | Records removed when no longer required | Lifecycle expiration after the lock ends |
| Durability across decades | Records survive hardware failure and replacement | Erasure coding or replication, multiple sites |
Regulations in this area were written around write-once-read-many media. The S3 Object Lock model provides the same behavior in software. Each object version can carry a retain-until date and a mode. In compliance mode, no account, including the most privileged administrator, can delete or overwrite the version or shorten its retention before that date. The period can be extended and never reduced. A legal hold can be placed on top, with no end date, and stays until it is explicitly removed.
Because the lock applies to object versions, versioning is part of the mechanism. An attempt to overwrite a locked object creates a new version and leaves the locked one intact. An attempt to delete it adds a delete marker without removing the data. That behavior has capacity consequences, discussed in the post on S3 versioning costs, and the wider protection model is covered in backup deletion protection.
Retention in compliance mode cannot be undone, so the period has to be right when the record is written. Three questions decide it. What starts the clock: the date the record is created, or an event such as an account closing or a patient reaching a certain age? Event-based retention means the period is unknown at write time, and the usual pattern is to apply a minimum lock at creation and extend it once the event occurs. Is the period the same for every record in the bucket? If so, a bucket default is simplest. If not, the application has to set it per object. And what is the longest period that could be justified, so that a mistake in configuration does not lock records for a century?
Testing with a short retention in a non-production bucket before applying the real value is cheap insurance. So is separating record classes with different retention into different buckets, as described in the post on data classification policies.
Regulated archives are often designed as if records only ever arrive. Privacy law in many jurisdictions requires that personal data is not kept longer than necessary, and a records schedule normally states a disposal date as well as a minimum. When a lock expires, the object becomes deletable but is not deleted. Something has to remove it: a lifecycle rule that expires objects after the retention period, or an application-driven disposal process with its own approvals.
Disposal should be as demonstrable as retention. That means all versions and delete markers are removed, replicas at other sites are included and there is a log entry to show for it. The post on data deletion verification covers how to evidence that.
Auditors of a regulated archive tend to test the control directly. They ask to see the bucket's Object Lock configuration and the retention metadata of sample records. They may ask for a demonstration that a privileged account cannot delete a locked record. They look at who can administer the storage system and whether those accounts are separate from the people who create records. They ask how the system clock is protected, since moving time forward would release locks early. And they ask for evidence of integrity checking and of how records survived the last hardware change. The posts on object storage integrity verification and archive storage refresh address the last two points.
Some regulations call for a formal third-party assessment of the storage system against the rule. Where that applies, the assessment report for the specific product and configuration is part of the evidence, and it should be requested from the vendor during procurement.
Regulated records frequently carry requirements about where they are held and who can reach them. An archive on infrastructure the organization operates, in a known facility, gives a direct answer to both. Where records must stay within a jurisdiction, that applies to every copy, including replicas for resilience and any metadata that describes the records. The post on metadata residency explains why the second point is often missed.
Scality RING exposes an S3 interface and supports versioning and S3 Object Lock, so the retention behavior described here, including a version under a retention period being protected until that period elapses, applies directly. RING is multi-tenant, with accounts, buckets and policy-based isolation, which allows record classes with different retention to be held separately and administered by different people.
RING is software-defined storage deployed on standard x86 servers in the customer's own facility, which places the hardware, the network boundary and the administrative accounts under the customer's control. Erasure coding and replication are selectable per policy, it can span multiple sites, self-healing runs as a background task and nodes can be replaced across hardware generations without a forklift migration.
A regulated archive has to answer two questions for any record on any day: can it be shown to be unaltered, and is there a reason it is still here? Immutability answers the first and a retention schedule the second. An archive that can answer both, with evidence, is one that passes its audits without drama.