The principle, stated plainly
Personal dataPersonal dataAny information relating to an identified or identifiable person: names, IDs, location, online identifiers, and combinations that single someone out. must not be kept in an identifiable form for longer than you need it for the purpose you collected it. This is the storage-limitation principle (GDPR Article 5(1)(e) is the canonical formulation, and equivalents appear in most modern regimes). It sounds administrative. It is actually the principle that most directly reduces your risk, because data you have deleted cannot be breached, cannot be mis-sold, and cannot be demanded in a subject access request.
Schedules beat ad-hoc deletion
There are two ways to run retention. One is a documented schedule: for each category of data, a defined period tied to the purpose and to any legal minimum (tax, employment, limitation periods for claims), with deletion or anonymisation happening automatically at the end. The other is ad-hoc deletion — clearing things out when someone notices, when storage gets expensive, or never.
Ad-hoc deletion fails for a structural reason: it is inconsistent, and inconsistency is indefensible. If you delete some customers’ data at three years and others’ at nine because no rule governs it, you cannot justify either period, and the long tail is pure exposure. A schedule turns retention from a judgement call made under pressure into a rule executed by default. It also gives you the one thing regulators and courts want to see: a reasoned basis for the period, decided in advance.
Why “keep it forever” is a liability
Hoarding data feels prudent — you might need it, storage is cheap, deleting feels irreversible. Every one of those instincts is wrong from a risk standpoint:
- It enlarges every breach. The blast radius of an incident is the data you still hold. Old records you no longer use are pure downside.
- It expands your obligations. Data you keep remains subject to access, rectification and erasure rights, and to security duties, for as long as you hold it. Keeping it forever means owing those duties forever.
- It rarely delivers the value imagined. The “we might need it” data usually turns out to be stale, unstructured and legally radioactive when someone finally asks for it.
The correct default is deletion at the end of a defined period, with retention being the exception you can justify — not the reverse.
The backup gap
Here is where most retention policies quietly fail. The policy says data is deleted after N years. The live system honours that. The backups do not: they hold snapshots that include data the policy says is gone, sometimes for years, across media that are hard to edit selectively. A deletion request satisfied in production can still leave the data sitting in a dozen backup generations.
Regulators generally accept that you cannot surgically excise one record from an immutable backup on demand. What they expect is a coherent position:
- backups are on a defined rotation, so deleted data ages out within a known window;
- restored data is re-filtered against deletion instructions before it re-enters live use (data you erased does not silently reappear after a restore);
- the policy states this explicitly, so the gap is managed, not hidden.
The failure is not having backups that lag. The failure is a policy that promises clean deletion while the backup regime makes that impossible and nobody has written down how the two are reconciled. Close that gap on paper and in the restore process, and retention stops being the principle everyone endorses and no one implements.