GDPR Data Retention Periods: Article 5(1)(e) Guide

The storage limitation principle in Article 5(1)(e) GDPR 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 data are processed. Two consequences follow from this: every processing activity needs a defined retention period, and the controller has to actually delete or anonymise the data when that period expires.

This guide covers the principle, the three-layer constraint structure (operational need, legal obligation, data subject rights), retention periods by common data category for EU SMEs, the three options for ending retention (deletion, pseudonymisation, anonymisation), and the recurring failure modes that supervisory authorities encounter during inspections.

The storage limitation principle

Article 5(1)(e) GDPR reads:

Personal data shall 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; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organisational measures.

Two operational principles follow:

1. No identifiable data without a current purpose. Data with no current processing purpose must be deleted or anonymised, even if it might be useful later.
2. Long-term storage is permitted only for archiving, research and statistics, and only with the safeguards in Article 89(1).

Article 5(2) GDPR adds the accountability principle: the controller is responsible for, and must be able to demonstrate, compliance with the storage limitation. In practice, this means documented retention periods per activity, a deletion schedule that is actually executed, and evidence that the schedule runs.

The three constraints stacked on top of each other

Real-world retention periods are not a single number. Three constraints stack:

The final retention period for an activity is the maximum of layer 1 and layer 2, until layer 3 forces deletion when both 1 and 2 expire.

Worked example for a customer invoice:

• Operational need: keep until customer might raise a warranty claim (e.g. two years for consumer goods under EU Directive 1999/44/EC as transposed; many member states extend to longer warranty periods)
• Legal obligation: national tax and accounting law typically requires invoices to be retained from 5 to 10 years (member-state dependent)
• Data subject rights: after the longer of the two periods expires, the data must be deleted unless a new purpose has arisen (e.g. ongoing customer relationship)

The retention period for invoices is therefore "the longest applicable national tax/accounting period", commonly 7 years in Spain, Belgium, France, Germany and the Netherlands, with variation.

Retention periods by data category

These are typical ranges for SMEs operating under EU law. National variations apply; verify the specific period for the relevant member state.

Customer and order data

Employee data

Marketing data

Website and analytics data

Application data

How to end retention: delete, pseudonymise, anonymise

GDPR offers three ways to take data out of scope at the end of its retention period.

Delete

The cleanest option. The data is physically removed from production systems, from backups according to backup expiry schedule, and from any other location it lives in. The supervisory authority looks for evidence that deletion actually happens, not just that it is scheduled.

A complication: deletion from backups is not instant. EDPB guidance allows controllers to wait for the backup rotation cycle to complete, provided the data is not restored to production from those backups in the meantime. Document the rotation cycle.

Pseudonymise

Replace direct identifiers with pseudonyms while retaining the data's analytical value. The pseudonymisation must be robust: the key that maps the pseudonym back to the identifier must be stored separately with strict access control, and the residual re-identification risk must be low enough that the data cannot be linked back to a specific individual by ordinary means.

Pseudonymisation does not take the data out of GDPR scope. The data is still personal data; it benefits from reduced obligations and is suitable for some long-term retention scenarios, but the storage limitation still applies eventually.

Anonymise

Make re-identification not reasonably possible by anyone, considering all means likely to be used. Recital 26 is the test. Once data is anonymous, it is outside GDPR and can be retained indefinitely.

Anonymisation is harder than it looks. A "name and email removed" dataset is often still pseudonymous if combinations of remaining fields (postcode + birth date + gender, or behavioural patterns) can re-identify individuals. The EDPB's Opinion 05/2014 on Anonymisation Techniques sets out the test. For most SMEs, true anonymisation of user-level data is not technically feasible; delete the data instead.

How to set up the deletion mechanism

A retention policy that exists on paper but is not actually executed is the most common storage-limitation finding in inspections.

Schedule deletion at the data layer

For structured data in a database, a scheduled job that walks each table and applies the retention rule for that table is the right level. Examples:

• customers table: rows with last_activity < NOW() - INTERVAL '3 years' and account_status = 'inactive' get deleted weekly
• orders table: rows where invoice_date < NOW() - INTERVAL '7 years' get deleted monthly
• web_sessions table: rows where created_at < NOW() - INTERVAL '90 days' get deleted daily

For unstructured data (uploaded files, document storage), a lifecycle policy at the storage layer that expires objects after the retention period is the right level.

Audit the deletion mechanism

Log each deletion run with summary metrics: how many records expired, how many were deleted, any failures. The log is the evidence for accountability. A clean log every month for two years is much more persuasive in inspection than a policy document with no execution trail.

Connect retention to the record of processing

Each row in the Article 30 record of processing names a retention period. The retention period in the register must match the retention period executed in the data layer. Drift between the register and the actual schedule is itself a finding.

Update the privacy notice

Article 13(2)(a) requires the privacy notice to state the retention period or criteria. Match the notice to the register, and the register to the data layer. All three should tell the same story.

For broader compliance context, the GDPR compliance checklist covers the other controls that surround the retention regime.

Common mistakes

"As long as necessary" without a number. Article 13(2)(a) requires either the period or the criteria. "As long as necessary" by itself is neither.

Single retention period applied to everything. A retention regime that says "we keep all customer data for five years" misses the fact that different categories of customer data have different applicable periods. Disaggregate.

Tax retention extended to all data. National tax law requires invoices and accounting records to be retained for a specific period. It does not authorise retaining the customer's IP address, browsing history or marketing preferences for the same period. Each category has its own analysis.

Backups retained beyond the active data. A backup is a copy of personal data. If the active data is deleted but the backup is retained for ten years, the personal data has not been deleted. Backup rotation must align with the retention schedule.

Inactive accounts kept indefinitely. An account that has been inactive for years has no current processing purpose. Either re-engage the user to confirm continued purpose, or delete.

Aggregated reporting based on raw personal data kept indefinitely. If aggregated reports do not actually need row-level personal data, anonymise after aggregating, then keep only the aggregate.

Soft delete that retains identifiers. "Soft delete" via a flag on the row preserves the personal data. For storage limitation, the underlying personal data must be removed, not just hidden.

Final checklist

• Each processing activity in your register has a defined retention period
• Retention periods reflect the maximum of operational need and legal obligation
• The privacy notice states the period or the criteria for each activity
• Deletion is implemented as a scheduled job, not a manual task
• The deletion job logs its runs with summary metrics
• Backups have a rotation policy that aligns with the retention schedule
• Inactive accounts have an inactivity period and a deletion trigger
• Pseudonymisation, where used, has separate key storage with restricted access
• Anonymisation, where claimed, would pass the Recital 26 test against motivated re-identification
• Quarterly review of the register, the privacy notice and the deletion mechanism in sync

---

This is technical analysis, not legal advice. For complex retention questions involving litigation hold, regulated sectors, or cross-border legal-obligation conflicts, consult a lawyer who specialises in data protection.