GDPR Storage Limitation: Retention, Deletion, and Erasure Rights

Under the GDPR, the storage limitation principle means you can keep personal data in a form that identifies someone only for as long as you actually need it for the purpose you collected it. The rule sits in Article 5(1)(e), and breaking it is one of the more expensive mistakes you can make: because storage limitation is a basic processing principle, violations fall into the top fine tier of up to €20 million or 4% of total worldwide annual turnover, whichever is higher.¹ Once the original purpose is done, the legal ground for holding the data is gone with it.

What Article 5(1)(e) Requires

The regulation says personal data must 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.”² Every category of personal data your organization holds needs a defined shelf life tied to a specific purpose. Collect an email address to send a one-time confirmation, and there is no justification to keep that address on file years later.

Recital 39 sharpens the operational expectation: controllers should set time limits for erasure or for periodic review of stored data.³ “We’ll delete it when we get around to it” is not compliance. You decide up front how long you need the data, and you check at set intervals whether that need still exists.

Article 5(2) then places the burden of proof on the controller. Saying you thought you might need the data one day will not satisfy a regulator. You need documented, defensible reasons for every retention period you set.²

Setting Retention Periods

The GDPR deliberately avoids a universal timetable. There is no master schedule of days or months. Each organization has to justify how long it keeps each category of data based on its own legal and operational context.

Several external factors typically drive the decision:

Tax and financial regulations. Most jurisdictions require businesses to keep financial transaction records for a defined period, commonly three to seven years, to facilitate audits and meet accounting obligations.
Employment law. Personnel records, payroll data, and workplace safety logs carry their own mandatory periods under labor and health rules. These can run from a few years after an employee leaves to decades for certain occupational health records.
Limitation periods for legal claims. Organizations reasonably consider how long someone could sue over the data. Contract disputes and personal injury claims typically carry limitation windows of two to six years depending on jurisdiction and claim type.
Sector-specific rules. Financial institutions, healthcare providers, and telecommunications companies face regulatory retention floors of their own that may exceed anything the GDPR alone would require.

These external obligations are not a blank check to keep everything. Each retention period must match a specific category of data and a specific legal basis. If tax law requires you to keep transaction records for seven years, that justifies retaining the transaction data, not every piece of personal information collected during the customer relationship.

Telling People How Long You Keep Their Data

Storage limitation is not only an internal exercise. You also have to tell people how long you plan to hold their data. Article 13 covers data collected directly from the individual: at the point of collection, you must state either the specific retention period or the criteria used to determine it.⁴ Article 14 imposes the same obligation when you get the data from a third party rather than the individual.⁵

A privacy notice that says “we retain your data as long as necessary” and stops there fails this transparency requirement. You either name a specific timeframe (“we delete your account data 12 months after you close your account”) or explain the criteria that determine the period (“we retain transaction records for the duration required by applicable tax law”). Vague language exposes you on two fronts at once: the storage principle itself and the separate transparency duty.

Exceptions for Extended Retention

Article 5(1)(e) carves out three situations where personal data may be stored beyond the normal operational period: archiving in the public interest, scientific or historical research, and statistical purposes.² These exceptions protect long-term studies, historical records, and large datasets with a societal purpose beyond any single business use.

They are not self-executing. Article 89(1) requires organizations relying on them to implement specific safeguards, with a particular emphasis on data minimisation. Those safeguards may include pseudonymisation where the research or archiving purpose can still be achieved without full identification. Where the purpose can be fulfilled by processing that no longer permits identifying individuals at all, the regulation requires you to take that approach instead.⁶

A commercial company cannot label its customer analytics as “statistical purposes” and claim the exception. The processing has to genuinely serve public-interest archiving, legitimate research, or bona fide statistical work, and the safeguards need to actually be in place.

What Deletion Looks Like in Practice

When the retention period ends, you have two compliant options: erase the data entirely, or strip the identifying characteristics thoroughly enough that no one can reconnect the data to an individual.

Erasure

Erasure means permanently removing the data from every system it lives in: live databases, archives, and cloud storage. That is straightforward until you reach backups. Backup media often uses immutable storage that cannot be selectively edited. The ICO’s guidance addresses this: if you cannot immediately erase data from backups, it must be put “beyond use,” meaning it cannot be accessed or processed for any purpose other than sitting in the backup cycle until it is overwritten on schedule.⁷ You must also be transparent with individuals about this interim period.

Anonymisation

Anonymisation transforms data so the individual behind it cannot be identified by any reasonably likely means. Once data is truly anonymous, it falls outside the GDPR entirely and can be kept indefinitely.⁸ The threshold is high. Regulators assess whether re-identification is possible using any means “reasonably likely to be used,” accounting for cost, time, and available technology. Stripping a name while leaving dates of birth, postcodes, and transaction histories intact rarely qualifies.

Pseudonymisation Is Not Enough on Its Own

Pseudonymisation replaces direct identifiers with codes or tokens, but keeps the key that links the code back to the individual stored separately.⁹ Because the re-linking key exists, pseudonymised data remains personal data under the GDPR. It is a valuable security measure and the regulation encourages it, but it does not satisfy storage limitation on its own. When the retention period ends, pseudonymised data still needs to be erased or fully anonymised.

Building Storage Limits Into Your Systems

Article 25 requires data protection to be built into processing systems from the design stage, not added later. The regulation specifically names the “period of storage” as one of the dimensions that must be limited by default.¹⁰ In practice, that means databases and applications should be configured so data is not retained past its purpose without active intervention.

Automated deletion rules, retention flags tied to data categories, and access restrictions that tighten as data ages all fit here. A system that stores personal data with no built-in mechanism for deletion or review is a compliance gap by design. Organizations that draw enforcement attention on storage limitation often share the same root problem: their systems were never built to forget anything.

Documentation: ROPA and Retention Schedule

Article 30 requires every controller to maintain Records of Processing Activities, commonly called a ROPA. Among the required entries: “where possible, the envisaged time limits for erasure of the different categories of data.”¹¹ In practice, “where possible” is almost always possible. If you cannot state a time limit, document the criteria for determining when deletion occurs.

Beyond the ROPA, most organizations build a separate retention schedule that lists every category of personal data, the retention period for each, the legal or business justification, and the deletion method. The retention schedule is what operational staff use day to day. The ROPA is the regulator-facing document a supervisory authority will review during an investigation.

How Storage Limitation Connects to the Right to Erasure

Storage limitation and the right to erasure are two sides of the same rule. Article 17 gives individuals the right to request deletion, and the first ground listed is that “the personal data are no longer necessary in relation to the purposes for which they were collected.”¹² That language mirrors the storage limitation principle almost exactly. If you are complying with storage limitation properly, many erasure requests will already be moot because the data will already be gone.

The right to erasure is not absolute. Organizations can refuse when the data is still needed for legal obligations under EU or member state law, certain public health purposes, archiving and research covered by the Article 89(1) safeguards, establishing or defending legal claims, or freedom of expression purposes such as journalism. Where a controller has made personal data public before receiving an erasure request, Article 17(2) adds a further duty to take reasonable steps to notify other controllers processing the data that the individual has requested erasure of any copies or links.¹²

Enforcement and Fines

Because storage limitation is one of the basic principles for processing under Article 5, violations fall into the higher fine tier: up to €20 million or 4% of total worldwide annual turnover from the preceding financial year, whichever is higher.¹

Fines are not the only tool. Supervisory authorities can issue warnings, order immediate erasure of unlawfully retained data, impose temporary or permanent processing bans, and suspend data flows to third countries. In serious cases, the order to stop processing can be more damaging than the fine itself.

The Italian data protection authority fined Clearview AI €20 million in 2022 for multiple GDPR violations, explicitly citing storage limitation as one of the breached principles alongside purpose limitation and transparency. The authority also ordered the company to erase biometric data it had collected through web scraping.¹³ Other enforcement has targeted real estate companies and food delivery platforms that retained customer data indefinitely after the business relationship ended, with individual fines ranging from hundreds of thousands to tens of millions of euros.

The pattern in these cases matters. Organizations rarely get fined for keeping data a few months too long. The enforcement actions that reach headlines involve systems that were never designed to delete anything, categories of data held with no retention period defined at all, or inactive accounts preserved for years with no business justification. The failures are almost always structural.

Reviewing What You Hold

Storage limitation is not a one-time exercise you finish when you write the retention schedule. The ICO’s guidance is direct: organizations must periodically review the data they hold and erase or anonymise it when they no longer need it. If you have not set a fixed retention period for a category, regular review becomes even more important.¹⁴

There is no mandated review frequency. Resources, organizational size, and the privacy risk to individuals are all relevant factors. What matters is being able to justify your review cycle if asked. An organization handling sensitive health data should review more often than one holding low-risk business contact details. The worst position is having no review process at all, which is exactly the gap that has triggered enforcement action against companies that held customer data for years without anyone checking whether it was still needed.

1
General Data Protection Regulation (GDPR). Art. 83 GDPR – General Conditions for Imposing Administrative Fines
2
General Data Protection Regulation (GDPR). Art. 5 GDPR – Principles Relating to Processing of Personal Data
3
Legislation.gov.uk. Regulation (EU) 2016/679 of the European Parliament and of the Council – Introduction
4
General Data Protection Regulation (GDPR). Art. 13 GDPR – Information to Be Provided Where Personal Data Are Collected From the Data Subject
5
General Data Protection Regulation (GDPR). Art. 14 GDPR – Information to Be Provided Where Personal Data Have Not Been Obtained From the Data Subject
6
GDPR.eu. Art. 89 GDPR – Safeguards and Derogations Relating to Processing for Archiving Purposes, Scientific or Historical Research Purposes or Statistical Purposes
7
Information Commissioner’s Office. Right to Erasure
8
General Data Protection Regulation (GDPR). Recital 26 – Not Applicable to Anonymous Data
9
General Data Protection Regulation (GDPR). Art. 4 GDPR – Definitions
10
General Data Protection Regulation (GDPR). Art. 25 GDPR – Data Protection by Design and by Default
11
General Data Protection Regulation (GDPR). Art. 30 GDPR – Records of Processing Activities
12
General Data Protection Regulation (GDPR). Art. 17 GDPR – Right to Erasure (Right to Be Forgotten)
13
European Data Protection Board. Facial Recognition: Italian SA Fines Clearview AI EUR 20 Million
14
Information Commissioner’s Office. Principle (e): Storage Limitation