Data Retention GDPR Rules: How Long Can You Keep Personal Data?

If you collect personal data from EU residents, data retention GDPR rules decide how long you may keep that data before you must delete or anonymize it. The General Data Protection Regulation (GDPR) does not hand you a fixed timetable: it requires you to justify every retention period yourself, document it, and disclose it to your users. This guide explains the storage limitation principle, how to set defensible retention periods, and how to build a retention policy that survives regulator scrutiny. It is educational information rather than legal advice, so consult a qualified attorney for decisions specific to your business.

Getting retention wrong is not a technicality. Keeping data too long violates a core GDPR principle and sits in the highest fine tier: up to 20 million EUR or 4% of global annual turnover under Article 83(5).

What Data Retention Means Under GDPR

Data retention is the practice of storing personal data for a defined period and then deleting or anonymizing it. Under GDPR, retention is governed by the storage limitation principle in Article 5(1)(e): personal data must be kept in a form that permits identification of individuals for "no longer than is necessary for the purposes for which the personal data are processed."

Three points follow directly from that wording:

• Retention is purpose-bound. The clock is tied to the purpose you collected the data for, not to how useful the data might be someday. When the purpose ends, the justification for keeping the data ends with it.
• "Just in case" is not a purpose. Regulators consistently reject indefinite storage on the grounds that data might be useful later. The Article 29 Working Party and its successor, the European Data Protection Board (EDPB), have repeated this position for years.
• Identifiability is the trigger. You can escape retention limits by genuinely anonymizing data, because anonymous data falls outside GDPR entirely (Recital 26). Pseudonymized data, where re-identification is still possible, does not qualify.

The accountability principle in Article 5(2) adds a second layer: you must be able to demonstrate compliance. It is not enough to delete data on time. You need documented retention periods, a justification for each one, and evidence that deletion actually happens.

The Storage Limitation Principle in Practice

Article 5(1)(e) contains a frequently overlooked exception. Personal data may be stored longer when processed solely for archiving purposes in the public interest, scientific or historical research purposes, or statistical purposes, subject to the Article 89(1) safeguards such as pseudonymization. For a typical business, this exception rarely applies. A SaaS company keeping churned customer records "for statistics" does not meet the Article 89 bar if the records remain identifiable and serve commercial analysis.

For everyday operations, the principle translates into a simple test you should be able to answer for every data category you hold:

1. What purpose does this data serve right now? If you cannot name an active purpose, the data is overdue for deletion.
2. Is there a legal obligation to keep it? Tax, accounting, and employment laws often mandate minimum retention. These obligations are a valid basis to retain data under Article 6(1)(c), but only the specific records the law covers.
3. Is there a foreseeable dispute or claim? Retaining data for the duration of a limitation period for legal claims is widely accepted, but you must tie the period to an actual statute of limitations, not a vague fear of litigation.
4. When does the period end, and what happens then? A retention period without an enforcement mechanism (automated deletion, scheduled review, or a deletion workflow) fails the accountability test.

Retention Versus Other GDPR Duties

Retention interacts with several other obligations. The right to erasure in Article 17 lets individuals demand deletion before your retention period expires, unless an exception in Article 17(3) applies. A subject access request forces you to reveal what you still hold, which exposes over-retention quickly. And if you maintain records of processing under Article 30, those records must state the "envisaged time limits for erasure of the different categories of data" (Article 30(1)(f)).

How Long Can You Keep Personal Data Under GDPR?

GDPR deliberately avoids fixed periods, because a period that is proportionate for payroll records would be excessive for marketing leads. You set the periods; you carry the burden of justifying them. That said, common practice and national laws produce recognizable benchmarks.

Data category	Typical retention period	Basis
Invoices and accounting records	6 to 10 years	National tax law (for example, 10 years in Germany, 6 years in the UK)
Employee records after departure	Duration of employment plus limitation period, often 3 to 6 years	Employment and social security law
Customer account data	Life of the account, then deletion or short wind-down period	Contract performance (Article 6(1)(b))
Marketing contact data	Until consent is withdrawn, or a defined inactivity window such as 2 to 3 years	Consent (Article 6(1)(a)) or legitimate interests
Job applicant data (rejected candidates)	Typically 6 months, longer only with consent	Limitation periods for discrimination claims
Server logs and security data	Weeks to months, commonly 30 days to 12 months	Legitimate interest in security, proportionality assessed case by case
CCTV footage	Days to weeks in most member states	National DPA guidance

Treat these as starting points, not safe harbors. The correct period for your business depends on the member states you operate in, your sector, and your actual purposes. When two purposes justify different periods for the same record, retain for the longer period but restrict processing to the surviving purpose. An invoice kept 10 years for tax law cannot be mined for marketing in year seven.

Criteria Instead of Fixed Periods

Where you genuinely cannot fix a period in advance, GDPR lets you define the criteria that determine it (Articles 13(2)(a) and 14(2)(a)). A criterion must be concrete enough for a user to predict the outcome. "We keep support tickets for two years after the ticket is closed" is a criterion. "We keep data as long as necessary" is not, and supervisory authorities have called out exactly that phrasing as insufficient.

Building a GDPR Data Retention Policy

A GDPR data retention policy is the document that turns the storage limitation principle into operational rules. It is also one of the first documents a supervisory authority requests during an investigation. Build it in five steps:

1. Map your data. Inventory every category of personal data you process: customer accounts, billing records, support tickets, analytics, logs, HR files, backups. If you already maintain records of processing activities, start there, because Article 30 records should list retention periods anyway.
2. Assign a purpose and legal basis to each category. The purpose drives the period. A record with two purposes gets the longer of the two justified periods, with processing restricted once the shorter purpose expires.
3. Set a period or criterion per category. Research the statutory minimums that apply to you (tax, employment, sector rules) and set everything else by necessity. Document the reasoning next to each period, because the reasoning is what you will defend later.
4. Define what happens at expiry. Choose between hard deletion and anonymization for each category, name the system owner responsible, and specify how backups are handled. A common, defensible approach is to let expired data age out of backup rotation on a fixed schedule while excluding it from restores.
5. Automate and audit. Manual deletion fails silently. Build scheduled deletion jobs where possible, log every deletion run, and review the schedule at least annually or whenever you add a new tool that stores personal data.

If you run a subscription product, the specifics of applying these steps to SaaS data, including trial accounts and churned customers, are covered in our guide to building a data retention policy for SaaS.

A Worked Example

An e-commerce store selling to EU customers might end up with a retention schedule like this:

• Order and invoice data: 10 years from the end of the fiscal year, required by national tax law.
• Customer accounts: deleted 3 years after the last login, following a warning email at 30 days before deletion.
• Abandoned cart emails: contact data deleted 12 months after collection if no purchase occurs.
• Web server logs: purged after 90 days, retained only for security monitoring.
• Newsletter subscribers: kept until unsubscribe, with proof of consent retained for the duration of the subscription plus the limitation period for enforcement claims.

Each line names a category, a period, and a justification. That structure is exactly what a regulator expects to see.

Data Retention GDPR Disclosures in Your Privacy Policy

Your retention rules are not only internal. Articles 13(2)(a) and 14(2)(a) require you to tell individuals, at the time of collection, how long their data will be stored or the criteria used to determine that period. This disclosure belongs in your privacy policy, broken down by data category rather than buried in a single generic sentence.

A compliant retention section typically states:

• The categories of data you collect (account data, payment data, usage data, support communications).
• The retention period or criterion for each category.
• The legal obligations that force longer retention, such as tax record laws.
• What happens after expiry: deletion or anonymization.
• How users can request earlier deletion under Article 17.

Writing this section by hand for every data category is tedious and easy to get wrong, which is why many businesses use a privacy policy generator that includes structured retention disclosures aligned with GDPR's transparency requirements. If your data practices change, for example when you add a new analytics tool, the retention section must change with them. TermsBox subscribers get this maintenance handled automatically: the platform's scanner detects new trackers and services on your site, and hosted documents are updated to reflect them.

Deleting and Anonymizing Data Correctly

Expiry of a retention period triggers one of two outcomes, and the distinction matters legally.

Deletion means the data is irreversibly removed from production systems and, on a defined schedule, from backups. Soft deletes that merely flag a database row as hidden do not count if the data remains retrievable and identifiable. For deletion requests under Article 17, the ICO and other authorities accept that data may persist in backups for a limited time, provided it is beyond normal use and will be overwritten in the ordinary backup cycle. Document that cycle.

Anonymization removes the data from GDPR's scope entirely, but only if re-identification is no longer reasonably possible by you or anyone else (Recital 26). Consider these tests before relying on it:

• Can the record be linked back to a person using other data you hold, such as an internal ID that maps to an account?
• Could someone single out an individual from the remaining attributes, for example a rare combination of location and job title?
• Would removing the direct identifiers still leave inference possible?

If the answer to any of these is yes, the data is pseudonymized, not anonymized, and your retention obligations continue. Pseudonymization is a valuable security measure under Article 32, but it does not stop the retention clock.

Third parties must delete too. Article 28(3)(g) requires your data processing agreements to obligate processors to delete or return personal data at the end of the service. When your retention period expires, data sitting in your email platform, CRM, and analytics tools must go as well. Your deletion workflow should enumerate every processor that holds a copy.

Common Data Retention Mistakes and Enforcement Examples

Retention violations are among the most commonly cited findings in GDPR enforcement, because they are easy for auditors to spot: the data is either there past its justification or it is not. Recurring failures include:

• No retention schedule at all. Data accumulates indefinitely because nothing forces the question. This is the default state of most databases and the first thing an auditor checks.
• Schedules that exist on paper only. A policy stating "2 years" while the database holds 8-year-old records is worse than no policy, because it proves you knew the standard and missed it.
• Retention hidden in vague privacy policy language. "As long as necessary for our business purposes" fails the Article 13(2)(a) transparency requirement.
• Forgetting secondary systems. Production is cleaned, but exports, spreadsheets, logs, and processor systems keep full copies.
• Refusing erasure requests without a valid Article 17(3) ground. Legal retention obligations cover specific records, not entire customer profiles.

Enforcement is well established. In 2019, the Berlin data protection authority fined real estate company Deutsche Wohnen 14.5 million EUR for archiving tenant personal data, including salary and financial records, without any deletion mechanism. In the same year, the Danish DPA reported taxi company Taxa 4x35 for keeping records of roughly 9 million rides beyond the company's own stated retention period, recommending a fine of 1.2 million DKK. The company had deleted names but kept phone numbers, which still identified customers. CNIL in France fined SGAM AG2R La Mondiale 1.75 million EUR in 2021 partly for retaining data on millions of prospects for years beyond its own schedule.

The pattern across these cases is consistent: the authorities did not dispute that some retention was lawful. They penalized the absence of enforced limits. If you are working through GDPR obligations more broadly, our GDPR compliance checklist places retention in the context of the full set of requirements, and our overview of what counts as personal data under GDPR helps you decide which records the rules cover in the first place.

Frequently Asked Questions

How long can you keep personal data under GDPR?

GDPR does not set fixed retention periods. Article 5(1)(e) requires you to keep personal data no longer than necessary for the purpose it was collected for. You must define and justify your own retention periods per data category, based on the purpose and any legal obligations such as tax record requirements.

Does GDPR require a data retention policy?

GDPR does not explicitly name a retention policy as a required document, but you cannot meet the storage limitation and accountability principles (Articles 5(1)(e) and 5(2)) without documented retention rules. Organizations subject to Article 30 must also record envisaged retention periods in their records of processing activities.

Do I have to state retention periods in my privacy policy?

Yes. Articles 13(2)(a) and 14(2)(a) require you to tell individuals how long you will store their personal data, or if that is not possible, the criteria used to determine the period. Vague statements like 'as long as necessary' with no criteria do not satisfy this requirement.

Can I keep personal data indefinitely if it is anonymized?

Yes, truly anonymized data falls outside GDPR because it no longer relates to an identifiable person (Recital 26). The bar is high: if anyone can reasonably re-identify individuals, including by combining datasets, the data is only pseudonymized and GDPR retention rules still apply.

What happens if I keep data longer than necessary under GDPR?

Keeping data too long violates Article 5(1)(e), which carries the highest GDPR fine tier: up to 20 million EUR or 4% of global annual turnover under Article 83(5). Real fines have been issued for this, including a 14.5 million EUR fine against Deutsche Wohnen by the Berlin data protection authority.

Does a deletion request override my retention schedule?

Not automatically. Article 17 gives individuals the right to erasure, but Article 17(3) allows you to refuse when you have a legal obligation to keep the data, such as tax or accounting laws. You must delete the data for all other purposes and explain the legal basis for what you retain.