Retention is an engineering problem wearing a policy costume
Keep for seven years, delete after ninety days — both halves of a retention policy are provable engineering claims, and most systems can prove neither.
Every retention policy makes exactly two promises. We will keep certain records long enough. We will not keep certain records too long. The document lives in a compliance folder, but both promises are claims about system behavior — and claims about system behavior are either engineered and testable, or they are decoration.
Most are decoration. Not because anyone is lying, but because the policy was written as prose and never translated into properties the system enforces. The translation is where the actual work lives, and it is harder than the PDF makes it look.
“Keep for seven years” is a claim about absence
To honor the first promise, it is not enough for records to exist today. You have to be able to show that nothing left early. That is a claim about absence of deletion, and absence is precisely what ordinary storage cannot demonstrate.
A table with no gaps in its ID sequence proves little — sequences get reused, migrations renumber, and a deleted row takes its ID with it quietly. A backup proves what existed at backup time, not what happened between backups. Meanwhile the mundane threats do their work: the cleanup job with an over-broad WHERE clause, the storage migration that dropped a shard, the compaction that was configured before the policy existed. None of these are attacks. All of them are deletions your policy says must not happen, occurring in ways nothing counts.
If nothing in the architecture makes deletion visible — a chained structure that breaks, a count that stops reconciling, a receipt that fails to appear — then “we kept everything” is a statement of hope, made on behalf of every job that has ever run against that database.
“Delete after ninety days” is a claim about copies
The second promise fails in the opposite direction. Deleting the row is trivial. The row was never the problem.
The problem is everywhere the data went while it was alive: the replica, the analytics warehouse, the search index, the debug log that captured a full request body, the backup rotation that outlives the window, the export a data scientist made in good faith. A deletion that removes the primary copy and leaves five shadows is not compliance — it is tidying.
Honoring this promise requires knowing where copies live, which requires the copies to have been recorded when they were made. Retrofitting that knowledge onto a system that never tracked propagation is archaeology, and archaeology under deadline is how privacy incidents get discovered by regulators instead of by you.
The question auditors learned to ask
Audit practice has been converging on a simple upgrade: from show me your policy to show me this record’s history against your policy. Pick a record class. When did its clock start, what rule applied, when was it disposed of, and what attests that disposal reached the copies?
A system designed for that question treats retention as a property of the record, not a behavior of a cron job. Each record class carries its clock. Disposal produces evidence — a dated, signed act, not a silent absence. Continuity is checkable in between, so that early deletion is a detectable event rather than an invisible one. None of this is exotic; all of it has to be decided before the data arrives, which is exactly why it so rarely exists.
The ten-second test
Choose one record your policy says was deleted last quarter, and one your policy says must survive until 2033. For the first: can you show when it was deleted, under which rule, and that the copies went too? For the second: can you show it has not been touched since it was written?
If either answer requires a meeting, the policy and the system have not met yet. The policy states intentions. Only the system can keep promises.
Axowl seals records at write time and makes both halves provable — continuity you can verify, disposal that leaves a receipt. See how it works.