How Long to Keep Personal Data in the UK: A Practical Guide

The shared drive has folders named “old customers”, “former staff” and “archive, do not delete”. Nobody knows why the files remain, but every proposed cleanup meets the same answer: the business may need them for six years. The question of how long to keep personal data in the UK cannot be answered with that one borrowed number because UK GDPR never created it ^1,2.

Quick Answer. How long to keep personal data in the UK depends on the purpose and law governing each record. UK GDPR sets no universal period. Define the record category, identify the legal or operational driver, choose a period or review trigger, apply it across live systems and backups, and document deletion and justified exceptions ^1,2.

Start with the record, not a favourite number

Storage limitation requires personal data to be kept in identifiable form for no longer than necessary for the purposes for which it is processed ^1,2. That principle deliberately avoids a universal number because payroll, unsuccessful applications, customer orders, CCTV footage and security logs serve different purposes and face different legal constraints.

The first step is therefore classification. “Customer data” is too broad. An invoice, delivery instruction, complaint recording, marketing preference and abandoned basket may all concern the same person while having different purposes, start dates and retention drivers. A schedule that groups them under one long period cannot control deletion accurately.

The schedule is not a list of numbers copied from another company. It is the operating link between UK GDPR's principle and the places where records actually live.

Domestic law supplies some real periods

Where another law requires retention, the business records that obligation and applies it to the covered material. GOV.UK states that limited companies generally keep company and accounting records for six years from the end of the last company financial year they relate to, while also identifying circumstances in which longer retention may be required ³. That is a genuine driver for those records, not proof that every customer email belongs in the same archive.

Self-employed business records follow a different tax frame. GOV.UK says they are generally kept for at least five years after the 31 January submission deadline of the relevant tax year ⁴. Employers are told to keep PAYE records for three years from the end of the tax year they relate to ⁶. Individuals also have pay-and-tax record duties that depend on how the return was submitted ⁵.

The source and the date it was checked belong in the schedule. A number without provenance becomes folklore; when the rule changes, nobody knows which categories require review. The record should also preserve conditions and exceptions instead of flattening qualified guidance into a rigid headline.

Build the schedule as an operating tool

A useful schedule can be maintained in a table, but each row must tell a system owner what to do. Start with the processing inventory and the storage locations. Split combined labels until one owner can recognise the category and one rule can dispose of it consistently.

For each row, write the purpose in plain language. Add the lawful basis and any statutory or contractual driver, but do not treat a lawful basis as a retention period. “Contract” may explain why an address was used to deliver an order; it does not say how many years every copy should remain. Necessity must be assessed over time, not only on the day of collection.

Then choose either a fixed period or a review trigger. Fixed periods suit stable categories with a clear start event. Review triggers suit ongoing relationships or cases whose end cannot be predicted. A customer account might receive an annual inactivity review, while a closed accounting year follows its published period. Every trigger needs a system field or process capable of identifying it.

Avoid vague entries such as “keep while useful”. Usefulness expands with storage capacity and rarely creates a deletion event. The schedule needs a date, an event or a review rule that produces a decision.

A worked schedule separates one customer into several records

Consider a small wholesaler that sells online and by account. One order creates a customer profile, delivery instruction, invoice, payment record, support messages, fraud signal and optional marketing preference. Keeping them all for six years would be simple, but simplicity is not the legal test.

The invoice and accounting evidence may follow the domestic accounting driver. A delivery instruction may no longer be needed once fulfilment and a reasonable operational period have passed. A complaint file may remain while the complaint or a related claim is active, then move to its documented end period. A marketing suppression record may need to remain in minimal form so the business remembers not to contact someone who opted out. Raw campaign behaviour need not inherit that same duration.

Fraud-prevention data receives its own necessity and risk analysis. If a signal no longer predicts or evidences anything useful, retaining it “in case” is weak. If the business can defend a defined period, it records the rationale and safeguards. The customer is one person; the schedule still contains several categories because the purposes differ.

This separation also improves access and deletion work. Staff can identify what is due for disposal without deleting accounting evidence accidentally, and they can explain why one record remains after another has gone.

Deletion must reach the real copies

Deleting a row from the main application may leave exports, synced folders, mail attachments, paper files and vendor copies. The schedule must map each category to its actual locations and give owners a method that removes or anonymises the data from ordinary use. A policy that never reaches a system is only a statement of intent.

Backups need a separate control. Immediate selective deletion from every backup may be technically impracticable, but that does not justify indefinite preservation. The organisation should define the overwrite or expiry cycle, restrict access, avoid using backup copies for ordinary business, and ensure restoration procedures reapply deletion decisions before restored data returns to live processing ².

Anonymisation is an end action only when identification is no longer reasonably possible. Removing a name while retaining a unique account number and a lookup table may leave personal data intact. Where the business keeps aggregate trends, it should test whether the result genuinely falls outside identifiable records rather than relabelling pseudonymised data.

Deletion evidence can be proportionate. Keep execution logs, counts, exception records and owner approval rather than a second full copy of the material that was meant to disappear. The evidence should show which rule ran, when, where, with what result and which records were held back lawfully.

Holds are exceptions with expiry dates

Routine disposal can pause for litigation, an investigation, a complaint, a statutory request or another documented need. A hold should identify the records, reason, authority, owner and next review date. “Do not delete until further notice” replaces one retention failure with another.

The held records remain subject to security, access control and purpose limitation. A dispute about one invoice does not justify freezing an entire customer's history. Scope the hold to material reasonably relevant to the issue, and release it when the reason ends so the normal schedule resumes.

Processors need the same operational signal. Contracts and procedures should let the controller issue deletion and hold instructions, obtain confirmation where appropriate and understand the provider's backup cycle. Moving data to a cloud platform does not transfer the retention decision away from the organisation.

Make the retention trigger calculable

A retention period is useless when the system cannot identify its first day. “Six years after closure” sounds precise until one team treats closure as the invoice date, another uses final payment and the platform has no closure field at all. The schedule should define the event in language that can be implemented and tested, then map that event to a reliable date or status in each system.

Calendar periods work only where the start event is stable. Accounting requirements may refer to a financial-year end or tax-year end rather than the date on an individual document ^3,4,6. Employment categories may begin from termination, final payment, conclusion of a grievance or expiry of a contractual claim period. Customer records may use order fulfilment, account closure or last substantive interaction. The schedule needs the right event for the purpose, not the date easiest to export.

Where the source system lacks the event, the business has four honest choices. It can add the field, derive it from reliable records, apply a cautious review queue, or accept that automated disposal is not yet safe. Inventing a proxy without testing it can delete live material or preserve dormant accounts indefinitely. The gap belongs in the remediation plan with an owner and date.

Bulk imports and historical archives deserve their own treatment. Records brought from a legacy system may have creation dates but no purpose-ending event. A staged review can divide them by category and evidence: material with a clear domestic driver, material tied to active people or contracts, material under a hold, and material whose purpose can no longer be established. “Legacy” is a location, not a retention reason.

The calculation should also survive a system change. If a platform is replaced, export the category, trigger and disposal date as metadata or apply the schedule before migration. Copying every old record into the new system and resetting its creation date silently restarts retention. A migration checklist should test that a record due next month remains due next month after the move.

Rights requests do not erase the schedule

Retention decisions and individual rights interact, but neither automatically overrides the other. A subject access request does not create a reason to keep all responsive data forever. The organisation preserves the material needed to answer the live request and records that temporary hold; once the response, complaint window and any related dispute are resolved, the normal schedule resumes.

An erasure request does not mean every record disappears immediately. The organisation assesses the request against the lawful basis, continuing legal duties, claims and applicable restrictions. An invoice required for accounting may remain even when optional profile data is deleted. The answer should identify the categories retained, the reason and the expected end point rather than sending one undifferentiated yes or no ^1,2.

An objection can change the purpose calculation. If direct marketing stops, the business may delete campaign data while keeping a minimal suppression entry so it remembers the objection. The suppression record serves a different and narrower purpose than the marketing profile; it therefore needs its own category, access controls and period.

A breach or investigation may also pause deletion for a bounded reason. Relevant logs and evidence can be preserved while the incident is assessed, but an incident involving one account does not justify suspending disposal across the whole database. The hold record should make the scope visible, because staff cannot release an exception they cannot find.

These interactions are why automated deletion needs an exception queue rather than a permanent off switch. The system identifies records due, owners review documented holds, approved records are deleted, and exceptions return with a new review date. That flow protects live legal needs without converting every unusual case into indefinite retention.

Review the schedule by testing systems

An annual review is a common starting cadence, but risk and change should set the frequency. A new HR platform, acquisition, legal change, investigation or purpose change can make a row stale before the calendar review. High-volume or sensitive categories deserve closer sampling than a stable statutory archive.

A real review tests both the rule and its execution. Select several rows, confirm the source still supports the period, inspect the live systems, sample overdue records, review holds and check that backup expiry operates as documented. Record owners and due dates for discrepancies. Merely changing “reviewed 2025” to “reviewed 2026” proves nothing.

A compact review pack gives management something more useful than a policy attestation. It can show records due versus deleted, overdue categories by system, active holds, failed deletion jobs, categories without reliable triggers and legal sources due for rechecking. Trend information matters: a backlog that falls after every review suggests the process works, while the same exceptions returning quarter after quarter reveal a control that exists only on paper. The pack should also record a small sample from beginning to end, following one category from its source rule through the system trigger, approval, deletion result and backup expiry. That sample makes hidden manual work visible and tells the business whether the schedule would still operate if the person who built it left tomorrow.

The first practical step is to choose five categories with obvious volume: invoices, payroll, former staff files, unsuccessful applications and inactive customer accounts. Map the copies, identify the driver and produce one operable row for each. That small schedule creates deletion work immediately and exposes where the business cannot yet calculate an end date.

Last updated: 26 August 2026.