Data you keep is data you can lose

Why is holding on to information a liability rather than an asset?

"Data is an asset" is one of those phrases that has stopped being examined. And the operational instinct that follows from it is: keep everything. Storage is cheap, and you never know what will be useful.

But notice something odd about that instinct. Nobody says "keep every physical document forever" — an office that never threw anything away would be understood as failing, not as prudent. Why does the same behaviour read as diligence when the documents are rows in a table? It is worth asking what a stored record actually does to you between the day it is written and the day it is finally useful.

Take one record: a customer's home address, captured in 2018, for a delivery that completed that week. What is it doing now?

It sits in the production database. It sits in every nightly backup taken since, in the analytics copy, in the two extracts an analyst pulled, and in whatever downstream system consumed the feed. It appears in access logs. It is inside the blast radius of every credential that can reach any of those places.

So ask the question that reframes everything: what is the probability that this record is exposed in a given year? It is not zero, and — here is the part that matters — it does not depend on whether the record is useful. Exposure risk is a function of being held, not of being needed. Which means every record you retain past its usefulness is contributing risk while contributing nothing else.

Then the second cost, less dramatic but more certain. When you are sued, or investigated, or served a subject access request, the obligation attaches to what you hold. A decade of undeleted mailboxes is a decade of material someone has to search, review and produce — and that is a real bill, paid in lawyers' hours, for records nobody wanted. Deleting under a legitimate schedule is cheap; deleting after a legal hold has attached is spoliation, which is a different and far worse problem. Notice the timing that implies: you can only dispose before you need to, never after.

There is a third cost that gets missed entirely. Old data does not merely sit there; it competes for attention. Stale records with obsolete schemas make queries slower, joins wronger, and analyses subtly misleading. A table where sixty percent of the rows describe a world that no longer exists will quietly produce averages nobody should act on.

And regulation has already encoded this reasoning. The GDPR's storage limitation principle — Article 5(1)(e) — requires personal data to be kept in identifiable form no longer than is necessary for the purpose it was collected for. That is not an arbitrary bureaucratic rule; it is the same argument, made law: holding beyond purpose creates exposure with no offsetting benefit to the person exposed.

So does it follow that you should delete aggressively? Not quite, and this is where the honest tension sits. Some data genuinely appreciates — long histories are what make forecasting, cohort analysis and fraud detection work, and a model trained on two years is often meaningfully worse than one trained on ten. The claim is not that old data is worthless. It is that its value must be argued for, one dataset at a time, whereas its risk accrues automatically. The asymmetry is the whole point: keeping is the default, and defaults do not get examined.

Which is what a retention schedule actually is. Not a deletion policy — a forcing function that makes someone state, per category of record, how long it is needed and why. Categories where nobody can answer are exactly the categories that should not be kept.

Three refinements.

First, the misconception that this is about storage cost. It is not, and framing it that way is why the argument keeps losing: storage genuinely is cheap. The costs that matter are exposure, discovery, and analytical noise, and none of them appear on the storage invoice.

Second, deletion is not the only disposition. Anonymisation, aggregation, and pseudonymisation can preserve the analytical value while shrinking the liability — and the honest caveat is that anonymisation is harder than it sounds, since re-identification from combined quasi-identifiers is a well-documented failure. "We removed the name" is not anonymisation.

Third, a retention rule that nothing executes is not a retention rule. The schedule must be attached to something that actually deletes — and, crucially, that reaches the backups, the extracts, the downstream copies and the analytics warehouse, not just the production row. Most organisations that believe they delete are deleting one copy out of six.

• Legal hold: why it suspends a retention schedule, and why disposal after it attaches is a serious offence.
• Anonymisation versus pseudonymisation, and how reliably either survives a determined re-identification attempt.
• How to make deletion reach backups and downstream copies rather than only the source of record.

Every term the collection defines is gathered in the glossary.