Retention, legal hold and data sovereignty

Cost engineering ended with a defensible number for every tier and a written reason behind each one, and retention is where that habit meets its hardest case. A retention value looks like a cost lever, because shortening it shrinks every copy at once, and it behaves like a legal instrument, because some of those copies exist to answer an obligation that has nothing to do with recovery. The number sitting in the lifecycle rule almost never records which of the two it was. What follows is about restoring that record, about what happens when two obligations point in opposite directions, and about the fact that where a copy physically sits has a legal answer as well as a technical one. It describes mechanisms; it is not legal advice, and none of these values belongs to engineering alone.

Three drivers arguing for three different numbers

The first driver is recovery need, and it is the only one this course can compute. It falls out of the failure model: how long a quiet corruption or a logical mistake can sit undetected before somebody asks for a restore. An estate that has measured its detection latency can defend a figure — ninety days because the slowest defect ever caught took forty-one days to surface, with margin — and an estate that has not measured it is choosing a number by feel. Recovery need attaches to a service, and it is usually the shortest of the three.

The second driver is a regulatory or contractual minimum. It comes from outside, it is expressed in years rather than days, and it attaches to a class of record rather than to a service or to a bucket. That distinction is the one estates lose first. A rule requiring financial records to be retained for seven years is a statement about those records staying available and produceable; it is not usually a statement that every nightly backup containing them must be kept for seven years. Conflating the two turns a record obligation into thousands of full backups nobody asked for.

The third driver is a deletion obligation, and it is the only one that argues downwards. Data-protection regimes and commercial contracts alike require that personal data be erased once its purpose has ended or a valid request arrives. This is a ceiling rather than a floor, it attaches to a data subject or a counterparty, and it is the driver estates discover last — usually when the first request lands and somebody goes looking for every copy.

Three drivers, three scopes, three units, and one field in the lifecycle rule. The collapse is not laziness; it is what happens when the enforcement point can only express one value. Whichever driver was loudest in the room that week wins, and the number becomes unfalsifiable the moment the meeting ends, because nobody wrote down what it was answering.

When the ceiling sits below the floor

The conflict is not hypothetical and it does not resolve itself. An erasure request arrives for a named individual. The live database row goes, the search index entry goes, the log lines age out. The nightly backup taken three weeks ago still contains the row, and that object sits in a bucket whose versions were stamped with a compliance-mode retention as they were written. The obvious move is to delete the version. The storage was configured specifically so that this cannot happen.

$ mc rm --versions --version-id 133fd99f-1f98-41c0-9d08-95e6e2944157 prod/rbdr-immutable/backup-0900.tar

  mc: <ERROR> Failed to remove `prod/rbdr-immutable/backup-0900.tar`. Object, 'backup-0900.tar (Version ID=133fd99f-1f98-41c0-9d08-95e6e2944157)' is WORM protected and cannot be overwritten
>>> exit code: 1

--- can the production identity force it? ---
$ mc rm --bypass --version-id ... prod/rbdr-immutable/backup-0900.tar
mc: <ERROR> Failed to remove `prod/rbdr-immutable/backup-0900.tar`. Object, 'backup-0900.tar (Version ID=133fd99f-1f98-41c0-9d08-95e6e2944157)' is WORM protected and cannot be overwritten
>>> exit code: 1

--- can the FULL ADMIN force it? ---
mc: <ERROR> Failed to remove `lab/rbdr-immutable/backup-0900.tar`. Object, 'backup-0900.tar (Version ID=133fd99f-1f98-41c0-9d08-95e6e2944157)' is WORM protected and cannot be overwritten
>>> exit code: 1

Read that as a design statement rather than an obstacle. Nothing here is broken and nothing is misconfigured. The property that makes the copy survive an attacker holding administrative credentials is the identical property that makes it refuse an erasure request, because both are the same refusal: this storage will not remove this version for anyone, and it will not make an exception for a good reason. A design that wants the first behaviour without the second is asking for a promise with a hole in it, and that hole is what ransomware walks through.

So the resolution has to be architectural. Three shapes are available, and an estate should know which of them it can offer before the request arrives.

The first is segregation. Personal data lives in its own dataset, backed up into its own repository under a short retention that is not locked, while the locked long-retention store holds only material whose regulatory floor genuinely requires it. Erasure then has somewhere to happen, because the copies containing the personal data expire on a horizon the estate controls. It costs design effort at the classification stage and repays it the first time an obligation lands.

The second is cryptographic erasure. The copy is encrypted under a key scoped narrowly enough — per tenant, per subject, per retention period — that destroying the key renders that copy unreadable while the ciphertext sits untouched under retention. NIST SP 800-88 Rev. 1 treats this as a sanitisation technique in its own right, and its correctness rests on two things this course keeps returning to: whether the key scope really matches the material you must erase, and whether another copy of that key survives in an escrow, a KMS backup or an old configuration file. A per-repository key does not give per-subject erasure. Whether crypto-erasure satisfies a given obligation is a legal question rather than an engineering one.

The third is suppression on restore: a documented, exercised procedure that re-applies the suppression list to any dataset recovered from an older backup before the recovered system is exposed. It deletes nothing; it makes the record’s presence in the backup operationally inert for the bounded period the copy still exists. Note what it adds — the suppression list becomes a recovery dependency that has to survive the disaster it will be used after, which puts it in the dependency graph beside the encryption keys and the DNS zone.

A legal hold has to be a state in the storage

A legal hold suspends expiry for named material, indefinitely, until somebody explicitly releases it. Its lifetime is set by the matter rather than by a schedule, which is precisely why it cannot be expressed as a longer retention period: nobody knows the date to put in the field.

The reason it has to live in the storage is that expiry is executed by code that reads nothing else. A lifecycle rule evaluates ages and prefixes; a delete request is evaluated against the version it names. Neither consults a ticket, a wiki page, a change freeze or an email from counsel. Object Lock provides two independent mechanisms here, per the S3 documentation: a retention period carrying a retain-until date, and a legal hold that carries no date at all and stays set until it is removed. Both are properties of an individual object version, evaluated in the storage’s own request path.

That path is what the measurement above demonstrates. The production identity was refused, the same identity passing --bypass was refused, the full administrator was refused, and all three received the same message with the same exit code. A refusal that does not vary with the identity making the request is the signature of enforcement by the storage — the opposite of a documented instruction, whose effect varies entirely with who read it.

There is a second reason holds belong in the storage, and it catches estates that thought they had complied. An ordinary delete request does not remove anything.

$ mc rm prod/rbdr-immutable/backup-0900.tar

  Created delete marker `prod/rbdr-immutable/backup-0900.tar` (versionId=4b3c593c-e8ad-444d-aa87-89e380a1fbae).
>>> exit code: 0

--- is the object still listed? ---

>>> exit code: 0

--- and with versions shown? ---
[2026-08-28 13:28:22 UTC]     0B STANDARD 4b3c593c-e8ad-444d-aa87-89e380a1fbae v2 DEL backup-0900.tar
[2026-08-28 13:28:20 UTC]    38B STANDARD 133fd99f-1f98-41c0-9d08-95e6e2944157 v1 PUT backup-0900.tar
>>> exit code: 0

The plain listing returned nothing, at exit code 0, while the versioned listing showed both the zero-byte delete marker and the original thirty-eight-byte version underneath it. Two consequences follow. Material believed deleted may still be present and therefore still disclosable, which is a problem in exactly the situation a hold exists to manage. And any answer to “has this been removed?” drawn from a default listing is wrong by construction; the question can only be settled against versions.

Governance mode and compliance mode make different promises here, and for a hold the difference cuts the other way from the ransomware case, because a hold must be releasable — matters close. In the capture, a governance-retained version was removed by an administrator passing --bypass at exit code 0 while the compliance-retained one refused every identity, so a releasable mechanism is only as trustworthy as the list of principals holding the bypass right. That list is the thing to review, not the mode name.

Sovereignty is three questions that people answer as one

The first question is where the bytes physically sit, and it has more answers than the architecture diagram shows. The primary repository is on the diagram. The offsite copy, the disaster recovery site, the catalogue and its metadata, the vendor’s own backups of your control plane, support bundles uploaded during an incident, and the key material frequently are not — and each is either a copy or a means of reading one.

The second question is who operates the storage as a legal entity. Choosing a region pins where the disks are. It does not by itself pin which corporate group runs them, where that group is incorporated, or which of its staff can reach the plane serving your objects. Compulsion generally reaches operators, and an operator with a presence in a jurisdiction can be reachable by that jurisdiction’s process irrespective of which datacentre holds the bytes.

The third question is which jurisdictions can compel what, because compelled production and compelled preservation are different demands. An order to preserve is a legal hold imposed from outside, arriving against material your lifecycle rules may already be expiring on schedule, so an estate that cannot set a hold quickly is in trouble in a way that has nothing to do with recovery.

This is where a disaster recovery site stops being purely an engineering decision. Placing it in another country is usually argued on excellent technical grounds — a different flood plain, a different power grid, capacity that exists there and not here, a lower unit cost — and it establishes a continuous flow of production data across a border. The failure mode is banal: a recovery site does not feel like a data transfer, so the people choosing it never ask whether the data may go there, and the answer arrives later, from somebody else, about copies that already exist.

Key custody has a sovereignty dimension for the same reason it has a security one. If the ciphertext sits in one jurisdiction and the key that opens it in another, the parties who can actually read the copy narrow to those who can reach the key. That is a real control and a real recovery risk at once, because the copy is unusable in any disaster that takes the key’s home with it, and the trade-off belongs in the recovery dependency graph rather than a compliance spreadsheet.

The enforcement point for all of this is the provisioning layer. A rule denying a plan that would create storage outside the permitted regions runs before the bucket exists; a wiki page saying “EU only” is a legal hold expressed as prose, and it fails the way prose always fails against automation. The asymmetry matters more here than anywhere else in the lesson: a copy that lands in the wrong jurisdiction is not repaired by deleting it, because the event to be reported is that it existed. Prevention is the only available control.

The register: every number carries its driver

The discipline that holds all of this together is unglamorous. Keep one row per dataset or record class, and record beside the retention value the driver that set it, the named authority it derives from, the owner who can change it, the enforcement point that applies it, the permitted regions, and the date it is next reviewed. The driver field takes exactly four values — recovery, regulatory, deletion ceiling, or unknown — and unknown is a finding to be worked, never a blank to be tidied away.

The enforcement point is the field people leave out and the one that decides whether the register is real. A retention existing only as a row is not a retention; the row has to name the bucket, the lock mode and the lifecycle rule identifier that carry it, so the register can be checked against the estate rather than believed.

REGISTER=/etc/backup/retention-register.tsv

# dataset  retention_days  driver  authority  owner  enforcement  regions  review
awk -F'\t' 'NR > 1 && ($3 == "" || $3 == "unknown" || $6 == "") {
      printf "unattributed retention: %s (%s days, driver=%s, enforcement=%s)\n", \
             $1, $2, $3, $6
      bad++
    }
    END { if (bad > 0) exit 1 }' "$REGISTER"

The reason to do this is the meeting that arrives roughly one quarter after the cost work in the previous lesson. Someone proposes cutting a seven-year retention to one year, and the saving is real and large. With the driver recorded, that proposal is answered row by row in a few minutes: the rows whose driver is recovery can be argued on measured detection latency, the rows whose driver is regulatory cannot be shortened by a budget conversation at all, and the rows whose driver is a deletion ceiling should probably be shortened further. With the driver absent, the person defending the long number has nothing to defend it with, and the cheapest number wins by default — which is how a regulatory retention gets quietly shortened to save money, and stays shortened until somebody asks for the records.

Production discipline

1. Record the driver beside every retention number, using recovery, regulatory or deletion ceiling, together with the named authority, the owner, the enforcement point and the review date. A number with no driver cannot be defended in a cost review and will lose one.
2. Decide the lock mode and the bucket layout before the first object is written. Locking is fixed at bucket creation, and the retain-until date is stamped onto each version as it arrives, so both decisions age into facts that no later configuration change reaches.
3. Give erasure somewhere to happen. Segregate personal data into a store with its own short unlocked retention, or scope keys narrowly enough that destroying one erases exactly the material you meant, and rehearse whichever you choose before the first request arrives.
4. Enforce holds in the storage and region constraints in the provisioning layer, then review who holds the bypass right as carefully as you review the retention itself. A hold that lives in a ticket is not enforced, and a region rule that lives in a wiki page is not enforced either.
5. Answer “has it been removed?” from a versioned listing, never a plain one. In the capture, the default listing returned nothing at exit code 0 while both the delete marker and the original version were still present.

Cross-course references

• Secrets, PKI & Certificate Management for Infrastructure Engineers — Part XV (KMS, HSM and Key Protection) builds the key custody model that decides whether the cryptographic erasure option in this lesson is available at all: per-subject erasure needs per-subject key scope and a destruction path with no surviving escrow copy, both of which are designed there, not here.
• Terraform for Production Sysadmins — Part XXIII (Policy as Code) is where the region constraints and lock-mode requirements described above become enforceable, by denying a plan that would create storage outside the permitted jurisdictions; a copy in the wrong country cannot be un-created afterwards, so the control has to run before apply.
• Terraform for Production Sysadmins — Part XXVII (Enterprise Scale: Multi-Team, Multi-Account) supplies the account and boundary structure that a sovereignty rule is written against, which is what lets “permitted regions” in the retention register name something the platform can actually check.

Quiz