After PRISM, Your Retention Policy Is a Liability

For most of my working life, the default answer to “should we keep this data” has been yes. Storage is cheap, deletion is irreversible, and nobody ever got fired for having a record.

I think this summer ended that, and I don’t think most companies have noticed yet.

What Actually Changed

The technical facts of the disclosures are not really my subject and I’m not qualified to litigate them. What matters commercially is narrower and harder to argue with.

Every dataset you hold is now understood, by your customers and increasingly by regulators, as something that can be compelled, breached, or subpoenaed. Not hypothetically. As a matter of demonstrated practice.

That reframes a database. It used to be an asset with a protection cost attached. It’s now an asset with a liability attached that scales with how long you keep it and how much of it there is.

“Data you’re holding for no reason is a risk you’re carrying for no return. Most companies have never put a number on either side of that.” — Sameer Gupta

The Uncomfortable Inventory

Here’s an exercise I’d recommend, and I’d warn you that it goes badly the first time.

Ask your teams to list every place customer data is stored. Not the systems of record, which everyone knows about. Everything.

The list that comes back typically includes:

Backups going back years, on a rotation nobody has reviewed since it was configured.
Analytics exports, sitting in a warehouse because an analyst needed them for a project that ended in 2011.
Log files containing full request payloads, retained indefinitely because the default retention was never changed.
Development and test environments populated with a copy of production, because that was the fastest way to test something realistically.
Third-party services you send data to, some of which were signed up for on a corporate card without a review.
Spreadsheets on laptops, which is the one everybody knows about and nobody wants to write down.

Most companies discover they are holding several times more personal data, in several times more places, than anyone believed. And every one of those copies carries the same exposure as the original.

The Argument for Minimisation

I want to make the business case rather than the ethical one, because the business case is sufficient.

Data you don’t hold cannot be breached. This is trivially true and routinely ignored. The cheapest security control available is not having the thing.

Data you don’t hold cannot be compelled. A request for records you deleted two years ago under a published policy is answered in one sentence.

Data you don’t hold costs nothing to secure, encrypt, audit, replicate, or explain. Every retained dataset carries an ongoing operational tax that never appears as a line item because it’s spread across a dozen budgets.

Customers are starting to ask. Slowly, and mostly in enterprise contracts rather than consumer relationships. But the direction is one way, and being able to answer “we don’t keep that” is becoming a competitive position rather than an admission of weakness.

What a Real Policy Looks Like

The failure mode is a retention policy that exists as a document and not as a mechanism. Here’s what I’d insist on:

Every dataset has a named owner and an expiry. Not “retain as needed.” A duration, decided by someone accountable, reviewed annually.
Deletion is automated. A policy that depends on someone remembering to run a script is not a policy. It’s an intention.
The default for new data is short. Ninety days unless somebody argues otherwise. Make retention the thing that requires justification, rather than deletion.
Backups are in scope. This is where most policies quietly fail. If your deletion process doesn’t reach the backups, you haven’t deleted anything, and saying you have is worse than not claiming it.
Test environments don’t get production data. Generate synthetic data or subset and mask properly. This is more work and it removes an entire category of exposure.
Third parties are inventoried. You are responsible for data you sent somewhere else. Your customers certainly think so.

The Objection, and My Answer

The objection is always the same: what if we need it later?

Sometimes you will. That’s a real cost and I won’t pretend otherwise. But it’s a known, bounded, occasional cost, and you can weigh it. The alternative is an unbounded liability that grows quietly and only becomes visible on the worst day of your professional life.

“Keeping everything is not a decision. It’s the absence of one, and it happens to have a large open-ended bill attached.” — Sameer Gupta

There’s a second answer too. Most of the “we might need it” data is needed in aggregate, not at the individual record level. You can very often keep the statistics and delete the rows. Retention policies that distinguish between the two are dramatically more defensible and barely less useful.

Final Thoughts

I’ve written before that a big data strategy is often just a storage bill, and this is the other side of that argument. Two years ago my objection to indiscriminate retention was that it wasted money and produced nothing.

That objection still holds. It’s now joined by a considerably sharper one.

The companies that come out of the next few years well will be the ones that can say precisely what they hold, why, for how long, and who else has a copy. Very few can say that today. It’s a boring project, it will take a year, and I’d start it now while it’s still voluntary.