Drill 51 — The Bucket Named archive-temp-final2

Theme: Compliance, Privacy & Model Governance · Format: 20-min drill · Difficulty: core

The story

A litigation discovery request arrives; legal asks engineering to produce all applicant data from a specified period. The search does its job too well: alongside the main database, it surfaces a cloud storage bucket named archive-temp-final2, created during a migration nobody remembers, holding applicant records twelve years old — five years past the documented seven-year retention policy. Worse: cross-referencing shows deletion requests that were dutifully honored in the main database but never propagated to this bucket, or to backups, or to the derived datasets built downstream.

⏸ Stop here and ask the room: legal asks: what else don't we know about? Can anyone answer?

Run it — facilitator script

Timing: ~2 min story · ~10 min questions · ~3 min reveal · ~5 min transfer.

Read the story, pause at the blockquote, and put legal's question to the room literally — "could we answer it, today, for our own storage?" Then work the questions.

How does data outlive its retention policy by five years without anyone noticing?

Listen for: the policy lives in a document while enforcement needs platform hooks; copies made mid-migration have no owner and no lifecycle rule; nothing in the platform scans for stores holding data past their class; and the naming tell — temp in a bucket name is a promise nobody kept, because "temporary" is a human intention, not a machine-enforced property.

Weak signal: "the migration team should have cleaned up" — person-blame for a platform gap. The team that made the copy dissolved years ago; the control has to work anyway.

Where do deletion requests actually have to reach — enumerate every copy?

Listen for: a real enumeration — replicas, backups, snapshots, feature stores, derived and downstream datasets, caches, logs, analytics extracts, vendor exports. The word that matters is lineage: deletion is a graph traversal, not a row delete. Bonus points for anyone who says the traversal must be verified by re-searching for survivors, not assumed.

Weak signal: "we delete from the database." The main database is one node in the graph — and anyone who stops there has just described the exact failure in the story.

What's the business value of a twelve-year-old applicant record, and what's its liability value?

Listen for: business value near zero — stale, unusable for modeling, past every legitimate purpose; liability value substantial — breach surface, discovery exposure, and evidence that the institution told people their data was deleted when it wasn't. The framing to reward: past its retention class, data flips from asset to pure liability.

Weak signal: "storage is cheap" or "it might be useful for training someday" — the hoarder instinct this drill exists to kill. Storage cost was never the argument; legal exposure is.

The reveal

Every expired record is pure downside: a liability that can be discovered, breached, or subpoenaed, with no business value to offset it. The retention policy existed on paper; enforcement existed nowhere. And the deletion requests that were "honored" are now evidence of the opposite — the institution told people their data was gone while copies sat in a bucket with temp in its name.

Why this happens — the mechanics

Retention policies are declarative; storage is imperative. A policy says "seven years" in a PDF; a bucket keeps objects until something deletes them. Between those two sits the gap this drill lives in: unless the policy is compiled into platform mechanisms — lifecycle rules, TTLs (Time To Live — automatic expiry), scheduled purges — it governs nothing. And the failure is perfectly silent by construction: retained data doesn't error, doesn't page, doesn't cost enough to show up in a bill review. The first signal that the policy was never enforced is someone else's lawyer finding the evidence.

Copies are where governance metadata goes to die. A migration copies data for a legitimate, temporary reason — but the copy inherits none of the operational context: no owner, no retention class, no lifecycle rule, no entry in anyone's inventory. The project ends, the ticket closes, and the bucket persists precisely because deleting it would require someone to know about it and be responsible for it, and the copy was born with neither. Every derived dataset downstream repeats the pattern — which is why deletion must follow data lineage, and why "honored in the main database" is the most dangerous kind of true statement.

Then discovery inverts the burden of knowledge. Day to day, nobody has to enumerate every store holding applicant data, so nobody can. A litigation discovery request — or a breach, or a regulator's audit — demands exactly that enumeration, under deadline, with legal consequences for getting it wrong. The institution ends up doing adversarial archaeology on its own infrastructure, and every store it forgot is a store opposing counsel gets to characterize. The inventory you never built gets built anyway — by the party least sympathetic to you.

Diagrams

Problem — how the failure unfolds:

timeline
    title Twelve years to discovery
    section Migration
        Year 0 : Migration copies applicant data : Bucket archive-temp-final2 born
    section Silent years
        Year 1 : Project ends (silent) : Bucket forgotten (silent)
        Year 7 : Retention policy expires : No lifecycle rule fires (silent)
        Years 7-12 : Deletions hit main DB only : Copies persist downstream (silent)
    section Discovery
        Year 12 : Litigation discovery request : Expired data surfaces : Deletions proven unpropagated

Solution — where the guardrails go:

flowchart TD
    A["Applicant data lands anywhere"] --> I["Data inventory: every<br/>store registered with<br/>purpose and retention<br/>class"]
    I --> L["Platform lifecycle rules<br/>and TTLs delete at 7 years<br/>— no human in the loop"]
    I --> P["Deletion requests<br/>propagate through lineage<br/>to backups and derived<br/>data"]
    L -.-> S["Retention scanner flags<br/>any store past its class"]
    P -.-> V["Verification job samples<br/>for surviving copies"]
    S -.-> AL["Alarm fires on the first<br/>expired record"]
    V -.-> AL
    AL --> R["Discovery request answered<br/>from a clean, known<br/>inventory"]

What good looks like

Registration at provisioning time: no bucket, dataset, or table is created without purpose and retention-class tags — enforced by infrastructure-as-code policy that fails the deploy, not by a wiki convention.
Lifecycle rules as the enforcement mechanism: for example, an object-storage lifecycle rule scoped to the retention-class=applicant-7y tag that expires objects at 2,555 days — including old versions and delete markers — with no human in the loop.
Backups inside the policy, not outside it: backup and snapshot expiry aligned to the retention class of what they contain; a seven-year policy with eleven-year backups is a four-year violation on a timer.
Deletion as lineage traversal: a deletion request fans out through the lineage graph — replicas, feature stores, derived datasets, caches, vendor exports — and every hop acknowledges completion back to the request record.
A verification sampler: a scheduled job re-searches a sample of deleted identifiers across all registered stores; any survivor pages the data-governance owner. Deletion is verified, never assumed.
An unknown-store scanner: periodically diff the cloud provider's resource inventory against the data catalog; any store holding regulated data without a catalog entry is automatically a finding — found by you, on your terms.
A migration checklist rule for copies: every temporary copy gets an owner, a TTL, and a decommission ticket on the day it is created — temp becomes a machine-enforced property instead of a hopeful name.

The lesson

Retention is enforced platform-side or not at all: lifecycle rules and TTLs (Time To Live — automatic expiry) that delete on schedule without a human in the loop. Deletion must propagate through data lineage — to replicas, backups, feature stores, and derived datasets — and be verified, not assumed. Both depend on the same precondition: a data inventory, because you cannot retain, delete, or defend what you don't know you have.

Named concepts: data inventory, retention enforcement, deletion propagation, data lineage.

Real-world echoes

Meta, May 2023: a record €1.2 billion fine under the GDPR (General Data Protection Regulation — the EU's privacy law) over transfers of EU user data to the United States without adequate safeguards. Different clause of the law than retention, but the same underlying question this drill asks, at record scale: does the institution actually know where its data is, and under what terms it is held?

Transfer

If a discovery request arrived tomorrow, could we enumerate every store holding applicant data — including buckets, backups, and derived datasets? Run the search now, on our own terms, before someone else's lawyer defines the terms.

Make it a ticket: Run a full-storage scan for applicant data this quarter — buckets, backups, feature stores, derived datasets — diff the results against the data inventory, and attach either a lifecycle rule or a decommission date to every unregistered store the scan surfaces.

Drill 53 — Purpose Creep — the same missing metadata, read as purpose instead of retention; the two tags die in the same migrations.
Drill 49 — The Zombie Model — the model inventory and the data inventory are one reflex pointed at two asset classes.
Drill 48 — The Logs That Remembered Everything (Theme 7, Security & Trust) — logs are the copy everyone forgets to enumerate.