EUR-Lex GDPR Article 5 Storage Limitation: Official

In one sentence. GDPR Article 5(1)(e) storage limitation — the official text published on EUR-Lex Regulation (EU) 2016/679 — 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, with exceptions for archiving in the public interest, scientific or historical research, and statistics under Article 89(1). It is one of the six core principles of the GDPR.

This is one of the most-enforced principles in DPA decisions, with Deutsche Wohnen €14.5M (Berlin 2019) the leading sanction. Article 83(5)(a) places the violation at the top tier — up to €20M or 4% of global turnover.

Key takeaways

• “No longer than necessary” — purpose-bound.
• Anonymisation lifts the restriction (data falls outside GDPR).
• Article 89(1) exception for research/archiving/statistics.
• Retention schedule mandatory in ROPA (Article 30(1)(f)).
• Privacy notice must state retention rules (Article 13(2)(a)).
• Sanctions: Article 83(5)(a) — up to €20M / 4% global turnover.

1. Article 5(1)(e) official text — EUR-Lex

Personal data shall be: (e) 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 required by this Regulation in order to safeguard the rights and freedoms of the data subject (‘storage limitation’);

Source: EUR-Lex Regulation (EU) 2016/679, Article 5. Available in all 24 EU languages.

2. Recitals supporting Article 5(1)(e)

• Recital 39: “The personal data should be adequate, relevant and limited to what is necessary for the purposes for which they are processed… time limits should be established by the controller for erasure or for a periodic review”.
• Recital 65: right to erasure complements storage limitation.
• Recital 156: research/archiving exception conditions.

3. “No longer than necessary” — practical interpretation

EDPB and DPAs interpret strictly:

• The purpose determines the duration
• “Just in case” retention is not permitted
• Active use vs archive distinction matters
• Document the justification per category

Necessity ≠ usefulness ≠ legal maximum.

4. Retention rule template

Data category	Active retention	Archive	Total	Source
Candidate CV (rejected)	2 years	—	2 years	CNIL guidance
Employee record	Employment term	5 years post	Term + 5y	Labour code
Customer transaction	3 years	7 years	10 years	Commercial code
Marketing opt-in	Active subscription	—	Until withdrawal	Article 21
Web logs	6 months	—	6 months	CNIL
CCTV footage	30 days	—	30 days	CNIL
Health record	Care + active monitoring	Long archive	Variable	National law

5. Anonymisation as exit strategy

Recital 26: GDPR does not apply to anonymous data. True anonymisation lifts storage limitation entirely. Test:

• Singling-out resistance
• Linkability resistance
• Inference resistance

EDPB Opinion 05/2014 (still authoritative) details the bar. Most “anonymisation” projects in practice produce pseudonymisation.

6. Article 89(1) exception

Longer retention permitted solely for:

• Archiving in the public interest
• Scientific or historical research
• Statistical purposes

Conditions: technical and organisational safeguards — pseudonymisation, access controls, no individual decisions. Member State law may add further safeguards.

7. Backups — special case

EDPB position:

• Backup retention can exceed operational retention (typically 30-90 days)
• Restoration policy must re-delete data already erased operationally
• Backup is a separate processing — document it as such in the ROPA

8. Sanctions — leading cases

• Deutsche Wohnen (Berlin LfDI, October 2019): €14.5M — legacy tenant archive system with no deletion functionality
• Discord (CNIL, November 2022): €800,000 — log retention disproportionate
• Total Direct Energie (CNIL, June 2022): €1M — old customer records
• Active Assurances (CNIL, July 2021): €180,000
• Vodafone Italy (Garante, November 2020): part of €12.25M
• Multiple HR cases across EU — over-retention of candidate data

8a. How DPAs test storage limitation in an audit

Storage limitation is easy to enforce because it produces hard evidence: a database query returns records older than the declared retention period, and the controller has to explain them. Supervisory authorities run three checks in sequence. First, they compare the retention periods stated in your privacy notice and ROPA against the periods actually implemented in the systems — divergence between the paper policy and the live database is the most common finding. Second, they ask for the deletion mechanism: is expiry automated, or does it depend on someone remembering to run a purge? Manual-only deletion almost always leaves stale data, and the Deutsche Wohnen archive is the textbook example of a system that made deletion technically impossible. Third, they test the justification behind each period — a number pulled from habit (“we keep everything for ten years”) without a legal or business rationale fails the necessity test even if the duration seems modest.

8b. Legal maximum is not the same as necessity

A frequent error: treating a statutory retention period (tax records, AML files) as a licence to keep the entire record set for that duration. The obligation to retain an invoice for accounting purposes does not authorise keeping the customer’s full behavioural profile, marketing preferences, or support-ticket history for the same ten years. Split the record: retain the legally mandated fields, and delete or anonymise the rest at the end of the shorter operational purpose. This “field-level retention” is what separates a compliant schedule from a lazy blanket rule, and it is what an auditor expects to see reflected in the ROPA. For a full workflow, see the data retention policy guide.

9. Implementation checklist

1. ROPA lists retention per category (Article 30(1)(f))
2. Each rule has documented legal/business justification
3. Privacy notice declares retention (Article 13(2)(a))
4. Automated deletion / anonymisation triggers
5. Backup retention separately documented
6. Periodic stale-data audit
7. Anonymisation methodology documented if used as exit

10. Interaction with right to erasure (Article 17)

Article 17 right to erasure gives data subjects an active right to deletion. Storage limitation imposes a default duty independent of any request. Both must be operationalised:

• Default deletion at end of retention period
• On-demand deletion for valid Article 17 requests

11. Tooling

Legiscope ties retention rules to ROPA activities, automates expiry alerts and deletion workflows, manages anonymisation projects, audits stale data across connected systems. See also storage limitation deep-dive and right to erasure.

FAQ

Where is the official EUR-Lex text of GDPR Article 5 storage limitation?

EUR-Lex Regulation (EU) 2016/679, Article 5(1)(e). Available in 24 EU languages.

What does storage limitation require?

Personal data must be kept in identifiable form no longer than necessary for the purposes. Longer retention is permitted for archiving, research and statistics under Article 89(1) with appropriate safeguards.

How long can I keep personal data under GDPR?

It depends on purpose: billing 10 years, marketing until withdrawal, security logs ~6 months, AML 5 years, employment term + 5 years. Document each retention rule with its legal/business justification.

Does anonymisation count as deletion?

Yes if anonymisation is irreversible per EDPB Opinion 05/2014 (resistance to singling-out, linkability, inference). Data then falls outside GDPR scope (Recital 26).

What’s the biggest storage limitation sanction?

Deutsche Wohnen (Berlin DPA 2019): €14.5M for a legacy archive system that had no deletion functionality for tenant data.