How Long to Keep Personal Data Under EU GDPR: 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 cannot be answered with that borrowed number because EU GDPR never created it ^1,2,3.

Quick Answer. How long to keep personal data depends on the purpose and applicable law for each record. EU GDPR sets no universal period. Define the 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,3.

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,3. That principle deliberately avoids a universal number because payroll, unsuccessful applications, customer orders, video 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.

Start with a narrow record category, identify its purpose or legal driver, define the start event and choose a period or review trigger. Map every copy across live systems and backups; if a bounded hold applies, scope and review it, otherwise delete or anonymise when due. Record proportionate execution evidence and test the schedule against current systems ^1,3,4.

The schedule is not a list of numbers copied from another organisation. It is the operating link between the storage-limitation principle and the places where records actually live.

Member State law supplies some real periods

Where Union, Member State or sector-specific law requires retention, the organisation records that obligation and applies it to the covered material. The European Commission notes that national labour, tax or anti-fraud law may set fixed periods ². That is a genuine driver for records within its scope, not proof that every customer email belongs in the same archive.

The EU GDPR storage-limitation rule is materially the same as its UK counterpart, so the decision logic does not justify two versions. What changes is the supporting jurisdiction: an EU-wide guide must complete tax, company and payroll periods Member State by Member State instead of importing one country's domestic numbers.

Each Member State needs a separate check. Use current official legislation or an authority page, capturing the rule's scope, trigger, exceptions and date checked because a headline number without its conditions cannot tell a system owner which records or dates it governs. Do not average the results. Choosing the longest period “to be safe”, or applying the headquarters country's rule to records governed elsewhere, can keep personal data without a purpose while still failing the law that actually applies.

The source, jurisdiction and date checked belong in the schedule. A number without provenance becomes folklore; when a rule changes, nobody knows which categories require review. Preserve conditions and exceptions rather than flattening qualified law into a rigid headline.

Where several countries produce different periods for genuinely equivalent records, keep separate schedule rows or an explicit jurisdiction matrix. The system rule should resolve the correct row from the establishment, legal obligation and record context, and it should send uncertain cases to a named reviewer. A silent “longest period wins” setting is not a substitute for that decision because it hides which obligation is being followed.

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 record of processing activities and actual storage locations. Split combined labels until one owner can recognise the category and one rule can dispose of it consistently ^1,3,4.

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 inactivity review, while a statutory record follows the trigger in the applicable law. 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, event or 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 across two Member States. One order creates a customer profile, delivery instruction, invoice, payment record, support messages, fraud signal and optional marketing preference. Keeping them all for one long period would be simple, but simplicity is not the legal test.

The invoice and accounting evidence may follow a Member State 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 objected. Raw campaign behaviour need not inherit that 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 organisation 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.

The two establishments may face different domestic record-keeping rules. The schedule should therefore carry jurisdiction as a field instead of applying whichever country's period is longer to every copy. This separation also helps staff explain why one record remains after another has gone.

Test the split with one real order from each establishment. Trace which invoice rule applies, which system field starts the period, whether a shared customer profile is actually covered, and which deletion job will act when the period ends. If the same platform stores both records, jurisdiction must survive as usable metadata rather than living only in a policy document.

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 ^3,4.

Backups need a separate control. Immediate selective deletion from every backup may be technically impracticable, but that does not justify indefinite preservation. 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 ^1,3,4.

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 organisation 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 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, legal or operational authority, owner and next review date. “Do not delete until further notice” replaces one retention failure with another.

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 controller ^1,4.

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 or tax period rather than the date on an individual document. Employment categories may begin from termination, final payment, conclusion of a grievance or expiry of a national 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 organisation 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 legal 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. An access request does not create a reason to keep all responsive data forever. Preserve the material needed to answer the live request and record that temporary hold; once the response and any related complaint or dispute are resolved, the normal schedule resumes.

An erasure request does not mean every record disappears immediately. Assess the request against the lawful basis, continuing legal duties, claims and Article 17 exceptions. An invoice required under applicable national law may remain even when optional profile data is deleted. The answer should identify the categories retained, reason and 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 organisation 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 follow 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 organisation 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 jurisdiction. That small schedule creates deletion work immediately and exposes where the organisation cannot yet calculate an end date.

Last updated: 26 August 2026.