Data Retention and Deletion — When and How to Remove Data

The Principle Isn’t “Delete Fast” - It’s “Justify Keeping”

Storage limitation is widely misread as a command to delete data the moment it’s been used. It isn’t. The principle is narrower and more demanding: personal data may be kept only as long as there is a purpose that still needs it and a lawful basis that still supports it. Data can be retained for years where a genuine reason exists - tax law, employment records, an active contract, a live legal claim. What the regulation forbids is the default the other way: keeping data because deleting it is effort, because it might be useful someday, or because no one ever decided it should go. The burden is to justify retention, not to justify deletion.

Retention Periods Come From the Purpose, Not a Template

There is no single number. A retention schedule is built bottom-up, from the purpose of each category of data: how long an active customer relationship lasts, how long after it ends a record must survive for tax or warranty or dispute reasons, how long employment files are kept after someone leaves, how long marketing consent stays valid before it goes stale. Different data, collected for different reasons, expires on different clocks - and the work is to define those clocks per category, write them down, and apply them automatically rather than from memory. A policy that says “we keep data as long as necessary” without ever defining necessary is not a policy. It’s a paragraph.

Deletion Has to Reach the Copies You Forgot

Defining a retention period is the easy half. Enforcing it is where most programmes break, because data doesn’t live in one place. By the time a record is due for deletion, copies have spread to backups, analytics warehouses, data exports, the email platform, the CRM, and a handful of third-party processors. Deleting the original and leaving the copies isn’t deletion - it’s tidying. Real erasure means reaching every system the data reached, and the regulator’s own standard is that deleted data is “put beyond use,” not merely archived or moved offline. Backups are the perennial blind spot: data quietly survives there long after it’s gone from production, and the schedule has to account for the backup lifecycle rather than pretend it doesn’t exist.

Delete, Anonymise, or Justify - Pick One Per Dataset

When a retention period ends, data has three legitimate destinations and exactly one illegitimate one. It can be deleted - put beyond use across every system. It can be anonymised - stripped of anything that could identify a person, at which point it falls outside the regulation entirely and can be kept freely for analytics or statistics, provided the anonymisation is genuine and irreversible rather than a thin pseudonymisation a join could undo. Or its continued retention can be justified by a specific, documented reason that still applies. The illegitimate fourth option is the common one: keeping it with no decision at all. Every dataset past its period should be able to point to which of the three roads it took, and why.

The Regulators Are Now Looking Specifically Here

Retention used to be the quiet principle nobody enforced - the headline fines were for breaches and consent. That has changed. In their 2025 coordinated enforcement action, Europe’s data protection authorities turned their collective attention to erasure and retention specifically, with thirty-two regulators auditing 764 organisations across the continent on how they actually delete data. The recurring weaknesses they found were structural and familiar: no systematic classification of what data exists, and no automated mechanism to act when a retention period ends. The signal is simple - “we keep things tidy” is no longer a defensible posture. Retention is being inspected as a discipline in its own right, on the assumption that an organisation should be able to show, not assert, that it deletes.

Hoarding vs. Governed Retention

Pattern-matching from real retention reviews - the gap between hoarding by default and retention by design tends to follow the same shape:

Build the Schedule on the Map, Automate the Trigger

A retention programme that works rests on two things an organisation should already have or build. The first is the data map: you cannot set a retention clock on data you can’t locate, so the inventory comes first. The second is automation: a period that depends on someone remembering to run a deletion job is a period that will be missed. The schedule defines, per category, how long and on what basis; the system enforces it without a human in the loop; and a deletion log captures the proof. Anonymisation is the pressure valve for data with genuine analytical value past its identifiable life. Everything else goes - on schedule, everywhere at once - and the organisation can show it.

Final Thought

Keeping data feels prudent and is usually the opposite. Every record held past its purpose is something that can be stolen, must be disclosed on request, and may be found by a regulator who now looks specifically for it. Deletion is unglamorous, effortful, and the clearest signal a privacy programme has matured past policy into operation - because it’s the one obligation an organisation can’t fake. The data is either gone or it isn’t.

The test: pick any category of personal data and answer three things without a project - how long is it kept and on what basis, what fires when that period ends, and could the deletion be proven across every system six months from now. If the honest answer is “most things stay and almost nothing is deleted,” the next audit already has its finding.