How long can you keep personal data? Building a retention schedule you can enforce

GDPR's storage limitation principle sets no fixed periods. Here's how to set ones you can justify, and how to check they held on endpoints as well as in the systems that have a delete button.

Article 5(1)(e) says personal data must be kept in a form permitting identification of data subjects for no longer than is necessary for the purposes it is processed for. It names no periods. That is deliberate, and it is why most retention schedules are written once, filed, and never applied.

A schedule nobody enforces is worse than no schedule, because it documents the distance between your stated practice and your actual one. An auditor who finds a five-year policy and eight years of data has a finding you cannot argue with.

How to set a period you can justify

Work from the purpose, then the legal floor, then the risk window, in that order.

1. 1Name the purpose precisely. 'Customer records' is not a purpose. 'Handling warranty claims' is, and it has an end date attached to it.
2. 2Check whether a statute sets a minimum. Tax, accounting and employment records commonly carry statutory minimum periods, and those set a floor you cannot go below.
3. 3Check the limitation period for claims you might need to defend. That is usually the longest legitimate driver for keeping something after its operational purpose ends.
4. 4Set the period at the longest of those, not at the longest anyone in the room can imagine a use for.
5. 5Write down the reasoning next to the number. That is the part that survives scrutiny.

'Six years, matching the limitation period for contract claims' is a position you can hold in front of a regulator. 'Six years' on its own is a number somebody picked.

What a workable schedule looks like

Illustrative only - periods depend on your jurisdiction, sector and purposes, and the reasoning column is where the real work is:

Why schedules fail in practice

Structured systems make retention comparatively easy. A CRM has a deletion job, a ticketing system has an archive policy, a payroll system has a statutory period baked in. The failures are almost always elsewhere:

• Exports. A report pulled into a spreadsheet for a board pack does not inherit the source system's retention period.
• Mailboxes. Attachments containing personal data outlive the systems the data came from, often by years.
• Local copies. Files taken onto a laptop for offline work and never removed.
• Backups and archives, where the retention position is usually undocumented rather than wrong.
• Departed staff profiles, which freeze a snapshot of whatever that person was working on.

Proving the schedule held

Enforcement is a discovery problem before it is a deletion problem. You cannot delete what you have not found, and you cannot evidence a retention position you have not checked. For structured systems a query proves it. For unstructured data you need to search the estate for personal data older than its period, and be able to repeat the search to show it stayed clean.

1. 1Run a discovery pass across endpoints, shared drives and mailboxes for the data categories in your schedule.
2. 2Compare what you find against the period for each category.
3. 3Delete what has aged out, or record the specific ground for keeping it.
4. 4Record the pass itself: date, scope, what was searched, what was found, what was actioned.
5. 5Repeat on a cycle shorter than your shortest retention period, so nothing ages out unobserved between passes.

What an enforced schedule buys you

Every other obligation gets cheaper. An access request covers less data. A breach exposes less. An Article 30 record is easier to keep accurate. An erasure request has fewer places to reach. Data minimisation under Article 5(1)(c) and storage limitation under 5(1)(e) are the two principles that reduce the cost of everything downstream of them, which is why they are worth doing properly rather than documenting aspirationally.