Data Retention Policy: Periods, Legal Bases, and Defensible Deletion
A data retention policy tells the organisation, in writing and in advance, what information it keeps, for how long, and what happens when the clock runs out. It is the operational expression of UK GDPR's storage-limitation principle and the evidence the ICO, HMRC and litigants will ask for when the question of why data still exists, or why it was deleted, inevitably arrives.
What this policy is
UK GDPR Article 5(1)(e) requires that personal data be “kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed”. The same wording appears in EU GDPR. That is a one-sentence rule that, without a written schedule, generates endless day-to-day friction: does the marketing team delete newsletter subscribers who haven't opened an email in two years; how long does customer support keep call recordings; is the old CRM backup still live or already expired; what happens to departed employees' email inboxes; do we keep visitor sign-in logs for a week, a year, or forever?
The retention policy resolves those questions centrally. It lists each category of data the organisation processes, the retention period for each, the legal or business justification for that period, and the method of deletion at the end of it. Where the justification is statutory (HMRC tax records, Companies Act accounting records, RIDDOR accident reports) the period is dictated by law. Where it is a limitation period for contract or tort claims, the period is derived from the Limitation Act 1980. Where it is operational need, the period is set by documented business reasoning. Every period has a reason; that reasoning is the evidence of compliance with Article 5(1)(e).
The policy also resolves the related question of the right to erasure (UK GDPR Article 17). Article 17 overrides the retention schedule in favour of the data subject where grounds for erasure apply, subject to the statutory-retention defence in Article 17(3)(b). Without a schedule, the controller cannot reliably say which data can be erased and which must be kept; with one, the answer is ready-prepared.
Who needs one
Every organisation that processes personal data or keeps business records needs a retention policy. In practice that is every organisation. The policy is particularly critical for:
- Any UK or EU data controller — UK GDPR Article 5(1)(e), Article 5(2) accountability, Article 13(2)(a) transparency to data subjects about retention, Article 30 records of processing activities (ROPA) which require retention information per processing activity.
- UK limited companies — Companies Act 2006 section 388 requires retention of accounting records for three years (private) or six years (public); these records typically contain personal data about suppliers, customers and employees.
- UK employers — PAYE regulations (seven years), right-to-work (two years after employment), pension records (forty years), accident records under RIDDOR 1995 Regulation 12 (three years), statutory maternity/paternity/sick pay records (three years).
- Regulated financial services firms — FCA SYSC retention requirements, MiFID II five-year transaction records, AML/CTF five-year customer due diligence records under Money Laundering Regulations 2017.
- Health and social-care providers — NHS Records Management Code (adult health records 8 years after last contact, child records until 25th birthday), social care records typically 35 years under the Care Quality Commission framework.
- Education providers — safeguarding records per Keeping Children Safe in Education, pupil records per Education (Pupil Records) Regulations.
- Organisations handling special category or criminal-offence data — elevated Article 9/10 controls make retention discipline more important, not less.
What must be in it
A defensible retention policy covers the following sections. The centrepiece is the retention schedule itself; everything else exists to make the schedule operable.
- Scope — the data categories the policy covers (employee, customer, supplier, marketing prospect, visitor, CCTV, system logs, financial records, and so on) and any exclusions (for example, research data under a separate governance framework).
- Retention principle statement — an explicit statement of UK GDPR Article 5(1)(e) and the controller's commitment to keep personal data for no longer than necessary. The ICO looks specifically for this statement; its absence is a common finding in enforcement notices.
- Retention schedule — the operational table, by data category, of retention period, legal or business basis, location and system, and deletion method. Typical entries for a UK employer: HR personnel files six years after termination (Limitation Act 1980 s5); payroll and tax seven years (PAYE); right-to-work two years after employment ends (Immigration Act 2006); customer contract records six years after contract ends (Limitation Act); marketing consent indefinitely (evidencing consent if challenged); CCTV 30 days (ICO CCTV code, unless extended for an investigation); visitor logs two years; unsuccessful job applications six months (with consent to retain for talent pool otherwise deleted); accident records three years (RIDDOR); accounting records six years (Companies Act); DPIA records and ROPA while processing continues plus three years.
- Legal bases column — for every period in the schedule, a citation to the statutory instrument or limitation period that drives it, or a written business justification where there is no statutory rule. The ICO and auditors will sample-check several entries; an unsupported period is the same as no schedule.
- Defensible deletion process — the method of deletion appropriate to the sensitivity and medium: cryptographic erasure for encrypted storage, secure overwrite for structured data, physical destruction of media with an accompanying certificate. For cloud services, reliance on the vendor's deletion guarantees is permissible only if supported by the processor's DPA and periodically verified.
- Archive versus live data — the distinction between production data that is actively used, archive data that is retained but not routinely accessed, and deleted data. Each category has different access controls and, often, different retention endpoints (the archive period may extend the live period). Back-up copies are a third case — see the related pitfall below.
- Legal hold procedure — who can issue a hold (usually the general counsel or head of legal), the triggers (letter of claim, regulatory notice, subpoena, internal disciplinary investigation), how affected systems are instructed to suspend scheduled deletion, how a hold is documented, and how it is formally lifted. A legal hold overrides the retention schedule; its absence exposes the organisation to spoliation findings.
- Linkage to the Record of Processing Activities (ROPA) — every processing activity in the ROPA should reference the retention schedule entry that applies. The two documents must be coherent; UK GDPR Article 30(1)(f) explicitly requires the ROPA to state envisaged retention periods.
- Review cadence and ownership — the named owner (typically the DPO or head of data governance), the annual review, and the specific triggers for ad-hoc review (new processing activity, new jurisdiction, material change to retention law). Evidence of review is what distinguishes a living policy from a document signed once and filed.
Common pitfalls
1. “We keep everything forever”
A de facto indefinite retention position is the most common failure of the storage-limitation principle and the one the ICO most often cites. The defence of “we might need it one day” does not satisfy Article 5(1)(e); a documented business need with a defined period does.
2. A schedule with no automation
A retention schedule that describes the correct periods but is not operationalised in any system is evidentially worthless. The data persists regardless. The policy must either be automated in the systems holding the data (time-to-live, automated purges) or operated as a recurring manual process with an audit trail. Without one or the other, the period is theoretical.
3. Backup retention misaligned with live retention
Live data is deleted on schedule but backups continue to hold copies for their own, longer periods. A data subject exercising the right to erasure under Article 17 cannot reasonably expect immediate deletion from backups, but the controller must document how backup data is excluded, degraded or eventually expired. The ICO accepts pragmatic treatment of backups provided it is documented; silence is not a defence.
4. No legal-hold mechanism
Routine deletion continues while litigation or an investigation is under way, leading to spoliation claims and, in serious cases, adverse inferences against the controller. The fix is a written hold procedure and a technical means to pause deletion for specific records.
5. Inconsistent periods across systems
The CRM deletes at two years, the marketing platform at three, the ERP at ten, and the email archive at forever. A single person, a single processing activity, and nobody has any confidence in which copy is authoritative. Every data category should have one retention period and every system holding that category should honour it.
6. Schedule not revised when purpose changes
A retention period is justified by a purpose. When the purpose changes (new marketing channel, new product line, new jurisdictional scope), the retention period must be re-examined. Organisations frequently add processing activities without revisiting retention, producing quiet misalignment that surfaces only in audit.
7. Ignoring processor copies
Deleting from the controller's systems is only half the picture. The Data Processing Agreement with each processor must require return or deletion of personal data on instruction and at the end of the processing relationship (UK GDPR Article 28(3)(g)). The retention policy should link to the DPA obligations.
8. Documentation of deletion is missing
Deletion that is not recorded cannot be evidenced. If a subject subsequently asks for their data under Article 15, the controller must be able to say that the data was held, was deleted on schedule, and explain when and how. Silent erasure produces worse outcomes than careful retention.
Framework mapping
| Framework | Reference | What it requires |
|---|---|---|
| UK GDPR | Article 5(1)(e) | Storage limitation — personal data kept no longer than necessary for the stated purpose. |
| UK GDPR | Article 17 | Right to erasure — data subjects may require deletion on defined grounds. |
| UK GDPR | Article 30(1)(f) | ROPA must state envisaged retention periods for each processing activity. |
| EU GDPR | Articles 5(1)(e), 17, 30(1)(f) | Identical principles; same obligations. |
| Limitation Act 1980 | Sections 2, 5, 8 | Limitation periods for tort (6 years), simple contract (6 years) and deed (12 years) — drives HR and contract retention. |
| Companies Act 2006 | Section 388 | Accounting records retained 3 years (private) or 6 years (public). |
| Income Tax (PAYE) Regulations 2003 | Regulation 97 | Employers to retain PAYE records for 3 complete tax years after the end of the tax year (effectively 6+ years in practice). |
| Money Laundering Regulations 2017 | Regulation 40 | Customer due diligence records retained 5 years after business relationship ends. |
| RIDDOR 1995 | Regulation 12 | Accident records retained 3 years; serious injury and dangerous-occurrence records may require longer. |
| ISO/IEC 27001:2022 | Annex A.5.33 | Information retained in accordance with legal, statutory, regulatory and contractual requirements. |
| NHS Records Management Code | Retention schedule | Adult health records 8 years after last contact; child records to age 25. |
How it fits with other policies
- Privacy Policy (UK GDPR) — the retention periods in the schedule must be reflected in the privacy notice's “how long we keep your data” section required by Article 13(2)(a).
- DSAR Procedure — a subject access request is constrained to data currently held; the retention policy defines what that is. An organisation cannot be forced to provide data it has lawfully deleted, but must be able to evidence the deletion.
- Information Classification Policy — classifications (public, internal, restricted, confidential) often inform retention: confidential data frequently has shorter routine retention with strong deletion evidence.
- Backup & Recovery Policy — defines how backups handle deletion, including the expiry of backup copies of data that has been live-deleted, and how the right to erasure is operated against backup media.
- Incident Response Plan — triggers a legal hold that suspends the retention schedule for affected records while the incident is managed and any resulting litigation or regulatory action runs its course.
- Third-Party Risk & Contracting Policy — governs the Data Processing Agreements that operate the retention schedule across processors; Article 28(3)(g) return-or-delete clauses are the mechanism.
Frequently asked questions
Does UK GDPR set specific retention periods?
No. UK GDPR Article 5(1)(e) sets a principle — personal data shall not be kept longer than necessary — but it leaves the specific periods to the controller to determine and justify. The controller must decide based on the purpose of processing, applicable statutory retention rules, and the limitation period for claims arising from the data. This is why a documented retention schedule matters: it is the evidence that the controller has applied the principle thoughtfully rather than arbitrarily, which is what the ICO asks for.
How long should we keep HR records in the UK?
The default answer is six years after the employment relationship ends. This derives from the Limitation Act 1980 section 5 — six years is the statutory limitation for simple-contract claims — and covers most wage, unfair dismissal, breach-of-contract and discrimination claims. Specific records have shorter or longer periods: payroll tax records require seven years (HMRC PAYE regulations), right-to-work documents two years after employment ends (Home Office guidance), pension records forty years (Pensions Act). Sensitive personal data (ethnicity monitoring, medical records) should be kept only as long as the specific purpose requires, typically much shorter.
Can we keep anonymised data indefinitely?
Yes, provided the anonymisation is genuinely irreversible. UK GDPR Recital 26 is explicit that the regulation does not apply to anonymous information. The test is whether an identifiable individual can be recognised from the data alone, or when combined with other information reasonably available. Pseudonymised data (key held separately) is still personal data under Article 4(5) and subject to retention limits. Genuine anonymisation typically requires removal of direct identifiers plus suppression or generalisation of quasi-identifiers to meet k-anonymity thresholds. If in doubt, treat the data as pseudonymous and apply the retention policy.
What is defensible deletion?
Defensible deletion means deletion that the controller can document, evidence and defend if challenged. It has three parts: a written policy explaining why the data was deleted (the retention schedule), an audit trail showing the deletion happened (who, when, what), and a method appropriate to the sensitivity of the data (cryptographic erasure of encrypted storage, physical destruction of media, secure overwriting of working files). The opposite — silently purging data without records — creates worse evidential problems than keeping it. If the controller cannot show why and how deletion happened, any future subject, regulator or litigant can characterise it as destruction of evidence.
What is a legal hold and when does it override retention?
A legal hold is an instruction to suspend routine deletion of specific data because of anticipated or active litigation, regulatory investigation, or internal disciplinary proceedings. It overrides the retention schedule for the duration of the hold. Triggers include: receipt of a letter of claim, a Part 31 disclosure obligation in UK civil procedure, a regulatory information notice (ICO, FCA, HMRC), a US litigation hold under FRCP 37(e), or a subpoena. The policy should describe who can issue a legal hold (usually the general counsel), how it is communicated, how affected systems are instructed to suspend deletion, and how the hold is lifted. Failure to operate a legal hold properly exposes the organisation to spoliation findings and adverse inferences.
Ready to implement this policy?
PolicySuite's Global Records, eDiscovery & Legal Hold pack includes a full data retention policy with a jurisdiction-specific retention schedule, together with 11 related policies covering legal hold, eDiscovery, archive management and records destruction.
£300 one-off · 12 policies