Data retention policy.
UK GDPR does not tell you how long to keep personal data. It tells you to decide, to be able to justify the decision, and to delete when the period ends. This is a plain summary of what a data retention policy must define, how to build a retention schedule, and the question that decides whether the policy is real.
What a data retention policy is
A data retention policy defines how long your organisation keeps each type of data, why, and what happens at the end of that period. It is the document that turns an abstract principle into a set of dates somebody can act on.
It is not the same as a privacy notice. The privacy notice tells data subjects what you do; the retention policy tells your own people what to do, and is the thing a regulator asks to see when the notice is challenged.
Most usefully, a data retention policy defines the boundary between data you are required to keep and data you are merely reluctant to delete. Those feel identical from the inside and are treated very differently in law.
Good data retention policies do three things: they define how long each of your types of personal data is kept, they name the regulatory requirements behind each timeframe, and they say what happens when data is no longer needed. Everything else is commentary.
What GDPR says about data retention and storage limitation
The relevant rule is the storage limitation principle in Article 5(1)(e) of the UK General Data Protection Regulation: personal data must be kept in a form permitting identification of data subjects for no longer than is necessary for the purpose for which it is processed.
Three consequences follow, and each surprises somebody.
- There are almost no statutory retention periods for personal data. GDPR sets none. The periods organisations quote come from other law entirely, or from sector practice.
- The obligation is to justify, not to comply with a number. If a data subject or the ICO asks why you held something for six years, "our policy says six years" is not an answer. Why does it say six?
- Keeping data indefinitely because it might be useful is not a purpose. Neither is "in case of a dispute", unless you can point to the limitation period that makes it necessary for the purpose.
Anonymisation is the escape route the principle explicitly leaves open: data that no longer permits identification falls outside it entirely.
Common retention periods, and the seven-year rule
The seven-year figure so many policies use is not a data protection rule at all. It comes from company law and tax: six years from the end of the accounting period for company records, which most organisations round to seven for safety. It applies to accounting records, and it has been copied onto everything else by habit.
Periods commonly used in the UK, each traceable to a source rather than to convention:
- Payroll and tax records: 6 years from the end of the tax year (HMRC).
- Company accounting records: 6 years for a public company, 3 for a private one (Companies Act 2006), commonly kept to 7.
- Unsuccessful job applications: 6 months, being the limitation period for most discrimination claims.
- Personnel files after leaving: commonly 6 years, being the limitation period for breach of contract.
- Accident records: 3 years from the incident, or from a child's 18th birthday.
- Safeguarding and child protection records: long, and set by sector guidance rather than by GDPR. Some must be kept until the subject's 75th birthday, and records within scope of the Independent Inquiry into Child Sexual Abuse must not be destroyed at all.
That last category is why a single organisation-wide period is always wrong. A retention schedule has rows, not a number.
How to build a retention schedule
The schedule is the policy's working half, and it is a table. One row per type of data, with five columns.
- Type of data. Specific enough to act on. "HR records" is not a row; "recruitment records for unsuccessful applicants" is.
- Where it is stored. Every system, including the ones nobody lists.
- Retention period. A duration and a trigger. "6 years" is incomplete; "6 years from the end of employment" is a rule a person or a script can apply.
- Justification. The statute, limitation period or business need. This column is the one that answers the regulator.
- Disposal method. Secure deletion, anonymisation, or transfer to an archive.
Build it from a data audit rather than from a template, because the rows you are missing are exactly the ones a template cannot know about. Review it annually, and record that the review happened.
Deletion, and proving it happened
Data must be securely deleted at the end of its period, and deletion has to be real. The ICO's position is that data put beyond use may be treated as deleted where it is genuinely inaccessible, not used, and protected, but that is a narrower shelter than it sounds and it is not a substitute for deletion where deletion is possible.
Backups are where retention policies usually break. If live data is deleted and the backup keeps it for another year, the retention period is the backup's, not the policy's. The workable answer is a documented backup cycle short enough that deleted data ages out, and a rule that restored data is re-deleted.
You should be able to show that deletion occurred, not merely that it was scheduled. A disposal schedule, or a system that records the deletion event, is what turns a policy into evidence.
A few best practices separate a data retention policy that works from one that is filed and forgotten. Automate deletion where the system allows it, because manual disposal at the end of the retention period is the step that never happens. Give the data protection officer, or whoever holds the role, sight of the retention schedule rather than only the policy. Review after any incident: data breaches are usually discovered to involve information that should already have been destroyed. And keep the wording simple enough that a manager can apply it without ringing someone, since compliance with data protection law here is mostly a matter of ordinary people remembering an ordinary rule.
The policy is only as real as its reach
Every organisation of any size has a retention schedule. Far fewer could apply it to all the personal data they actually hold, and the gap is not in the systems the schedule names. It is in the ones it does not.
The schedule covers the HR system, the finance system, the case management system, the shared drive. It rarely covers the group chat where staff discuss residents, pupils or service users by name, on personal phones, with no retention period at all because nobody owns the channel.
That is a storage limitation problem in the strict sense. Personal data is being kept, indefinitely, with no defined purpose and no possibility of deletion, and it would be within scope of both a subject access request and a regulator's enquiry. The organisation cannot delete it because it cannot reach it, and it cannot produce it for the same reason.
It is worth asking, when the schedule is next reviewed, a question the schedule itself cannot raise: is there personal data being created about our service users somewhere no row of this table can reach? For most organisations the answer is yes, and the fix is a channel the organisation owns rather than a longer policy.
Where to read the official guidance
The ICO's guidance on storage limitation is the authority, and its right to erasure guidance covers deletion on request. Sector retention schedules exist for health (the NHS Records Management Code of Practice) and for schools (the IRMS toolkit), and both are more useful starting points than a generic template.
This page is a summary, not legal advice. Where a retention decision turns on a limitation period, take proper advice.
ComplyChat gives the conversations above a channel your organisation owns, on the record from the first message. Once your Microsoft 365 tenant is connected, the lasting record files there and inherits the retention rules you already run for email. We wrote this guide because the gap in section 06 is the one our customers came to us with.
How it works · Why us · Pricing · FAQ