In one sentence. GDPR Article 5(1)© data minimisation and Article 5(1)(e) storage limitation are the two quantity-control principles: minimisation governs how much data is collected (only what is necessary), storage limitation governs how long it is kept (no longer than necessary). Together they bound personal data both at intake and over time. Official text: Regulation (EU) 2016/679, Article 5 on EUR-Lex and European Commission GDPR principles page.
DPA audit findings show that retention failures are the single most common Article 5 violation — old CVs, abandoned accounts, log files kept forever. Sanctions sit at the top tier (€20M / 4%) under Article 83(5)(a).
Key takeaways
- Minimisation = adequate, relevant, limited to necessary.
- Storage limitation = kept in identifiable form no longer than necessary.
- Exceptions for archiving, research, statistics under Article 89(1).
- Retention schedule is a mandatory ROPA component (Article 30(1)(f)).
- Anonymisation removes data from GDPR scope (Recital 26).
- Sanctions: Article 83(5)(a) — up to €20M or 4% of global turnover.
1. Article 5 official text (excerpts)
Personal data shall be: © adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’); (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.
2. Data minimisation: necessity test
EDPB applies a strict necessity test:
- Data must be objectively necessary, not merely useful
- The least intrusive option must be preferred (Article 25 privacy by default)
- Aggregation and pseudonymisation where granularity not needed
- Optional vs mandatory field distinction in forms
The two principles are complementary controls on the same lifecycle: minimisation caps the width of the dataset at intake, storage limitation caps its depth in time. A data set that is minimal at collection still breaches Article 5 if it is never deleted, and a rigorously purged system still breaches Article 5 if it over-collected in the first place. The practical method is a field-by-field pass documented in the data minimisation guide, followed by a per-purpose retention rule captured in a written data retention policy.
3. Storage limitation: the duration question
Three operative criteria:
- Identifiable form — anonymisation lifts the restriction
- No longer than necessary — purpose-specific
- Archiving/research/statistics exception under Article 89(1)
The principle does not forbid long retention if legally required (tax, anti-money-laundering) or if data is anonymised.
4. Retention schedule template
Per data category and purpose, document:
| Category | Purpose | Retention rule | Justification |
|---|---|---|---|
| HR — candidate CV | Recruitment | 2 years after rejection | CNIL guidance |
| Employee record | Employment | Term + 5 years | Labour code |
| Customer transaction | Billing | 10 years | Commercial code |
| Marketing email opt-in | Marketing | Until withdrawal | Consent + Article 21 |
| Web server logs | Security | 12 months max | CNIL deliberation |
| Video surveillance | Security | 30 days | CNIL guidance |
| Anti-money-laundering | Legal obligation | 5 years post-termination | AMLD |
5. Anonymisation vs pseudonymisation
- Anonymisation (Recital 26): irreversible — data falls outside GDPR scope
- Pseudonymisation (Article 4(5)): reversible with separate key — still personal data
EDPB Opinion 05/2014 sets the bar for anonymisation: must resist singling-out, linkability and inference attacks. Most “anonymised” data is in fact pseudonymised.
6. Article 89(1) research/archiving exception
Longer retention permitted for:
- Scientific or historical research
- Statistical purposes
- Archiving in the public interest
Conditions: technical and organisational safeguards (pseudonymisation, access controls), data minimisation, no individual decisions.
7. Sanctions — retention cases
- Deutsche Wohnen (Berlin 2019): €14.5M — tenant data archive system retained data beyond necessity
- Discord (CNIL 2022): €800,000 — log retention disproportionate
- Total Direct Energie (CNIL 2022): €1M — customer data beyond retention period
- Active Assurances (CNIL 2021): €180,000 — old CRM records
- TIM (Garante 2020): part of €27.8M — over-retention
8. Sanctions — minimisation cases
- H&M (HmbBfDI 2020): €35.3M — over-collection of employee personal information
- Marriott (ICO 2020): £18.4M — passport scans
- Multiple HR cases — medical data collection beyond necessity
- Cookie cases — non-essential trackers (related principle)
9. Implementation checklist
9a. Storage limitation is a default duty, not a request-driven one
The most common misunderstanding is treating deletion as something that only happens when a data subject files a right to erasure request. Article 5(1)(e) imposes a standing obligation: the controller must delete or anonymise data at the end of its retention period whether or not anyone asks. The erasure right (Article 17) is an additional, on-demand layer that lets individuals accelerate deletion or remove data still within its retention window. A compliant programme runs both mechanisms — an automated expiry job that enforces the default schedule, plus a workflow to handle ad-hoc erasure requests within one month. Auditors treat the absence of the automated default as the more serious failing, because it proves the over-retention is systemic rather than an isolated oversight.
9b. The audit reality: stale data is everywhere
DPA inspections rarely find a controller with no retention policy on paper. They find a policy that the live systems ignore — abandoned accounts still queryable years after last login, log files rotated but archived indefinitely, backups that quietly resurrect deleted records on restore. The fix is not another document; it is a periodic stale-data sweep that compares each system’s oldest records against the declared retention rule and flags the divergence. Run it quarterly, keep the output, and you have the accountability evidence (Article 5(2)) that turns a routine audit from an ordeal into a formality.
10. Backups and storage limitation
EDPB confirms: backups are a separate processing with a different purpose (business continuity). They may be retained longer than the operational copy, provided:
- Restoration policy ensures deleted data is re-deleted
- Backup retention itself is proportionate (typically 30-90 days)
- Access controls prevent operational reuse
11. Tooling
FAQ
What is data minimisation under GDPR?
Article 5(1)©: personal data must be adequate, relevant and limited to what is necessary for the purposes. EDPB and CJEU apply a strict necessity test — useful is not enough.
What is storage limitation under GDPR?
Article 5(1)(e): 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).
Where is the official European Commission text?
European Commission — GDPR principles and the official Regulation on EUR-Lex.
How long can I keep customer data?
It depends on purpose: billing 10 years (commercial code), marketing until consent withdrawal, security logs typically 6-12 months, AML 5 years. Document the rule and justification per category.
What’s the biggest sanction for retention failures?
Deutsche Wohnen (Berlin DPA 2019) at €14.5M is the leading storage-limitation case. H&M (€35.3M) is the leading minimisation case.