Skip to main content
Regulyze
GDPR6 min read

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

GDPR doesn't specify exact retention periods — but it requires you to justify them. This guide breaks down the principles, common retention schedules, and how to document your approach.

Sarah Lindqvist

VP of Product ·

The retention paradox

Article 5(1)(e) of the GDPR — the storage limitationprinciple — says personal data should be kept "no longer than is necessary" for the purposes for which it was collected. But the regulation doesn't prescribe specific retention periods. That's for you to determine, document, and justify.

This creates a practical paradox: you need data for legitimate business operations, but holding it a day longer than necessary creates regulatory risk. Fines for storage limitation violations have reached into the tens of millions of euros. Getting retention right is both a legal obligation and a risk-management imperative.

"We keep everything forever because storage is cheap" is no longer an acceptable data-management strategy under the GDPR.

Key GDPR principles governing retention

Three GDPR principles directly affect how long you can hold personal data:

Purpose limitation (Article 5(1)(b))

Personal data collected for a specific, explicit purpose cannot be further processed in a manner incompatible with that purpose. Once the original purpose is fulfilled, retaining the data requires a new, valid lawful basis.

Storage limitation (Article 5(1)(e))

Data must be kept in a form that permits identification of data subjects for no longer than necessary. Data that is truly anonymised — irreversibly stripped of all identifying characteristics — falls outside the GDPR's scope entirely. Pseudonymised data does not.

Accountability (Article 5(2))

You must be able to demonstratecompliance. That means documenting your retention periods, the rationale behind them, and the processes that enforce them. "We have a policy" is not enough — you need evidence that the policy operates in practice.

Common retention schedules

While the GDPR doesn't dictate specific periods, the following are widely adopted starting points based on legal obligations and industry practice:

Data typeTypical retentionRationale
Customer account dataDuration of contract + 12 monthsService delivery + reasonable follow-up period
Transaction records7 yearsTax and financial reporting obligations
Marketing consent recordsDuration of consent + 3 yearsDemonstrating valid consent if challenged
Employee recordsDuration of employment + 6 yearsEmployment law limitation periods (UK/EU)
Website analytics (with PII)26 monthsAligned with common tool defaults; minimise where possible
Support tickets3 years after resolutionService improvement and dispute resolution
Job applicant data6–12 months post-decisionRecruitment process review; discrimination claim limitation
CCTV footage30 days (unless incident flagged)Security monitoring; minimal retention

Important: These are illustrative. Your retention periods must reflect your actual legal obligations, contractual commitments, and business needs. Consult legal counsel for jurisdiction-specific requirements.

1. Inventory your data

Before you can set retention periods, you need to know what personal data you hold. Map every data category across every system:

  • What personal data do you collect? (names, emails, payment details, IP addresses, device IDs, etc.)
  • Where is it stored? (databases, SaaS tools, file shares, backups, logs)
  • Why was it collected? (contract performance, consent, legitimate interest, legal obligation)
  • Who has access to it? (engineering, support, marketing, third-party processors)
  • Where does it flow? (cross-border transfers, sub-processors, analytics providers)

This inventory should feed into your Record of Processing Activities (RoPA) — a GDPR Article 30 requirement for most controllers and processors.

For each category of personal data, identify the lawful basis under GDPR Article 6 that justifies retention:

  • Contractual necessity — data needed to perform a contract with the data subject
  • Legal obligation — data required by law (e.g., tax records, AML requirements)
  • Legitimate interest — data processed for a legitimate business purpose, balanced against data subject rights
  • Consent — data subject has given specific, informed, unambiguous consent

The lawful basis determines the retention logic. Contractual data is kept for the duration of the contract plus any legally required wind-down period. Consent-based data must be deleted when consent is withdrawn.

3. Set justified retention periods

For each data category, define a specific retention period and document the reasoning. The retention period should be the minimum necessary to fulfil the stated purpose plus any applicable legal obligation.

Avoid these anti-patterns:

  • "We keep it indefinitely" — no lawful basis supports indefinite retention of identifiable personal data.
  • "We keep it as long as the competitor does" — industry norms are useful input but not a legal justification.
  • "We might need it someday" — hypothetical future need is not a valid purpose.

Document each retention period in a formal retention schedule — a table linking data categories to retention periods, lawful bases, responsible teams, and deletion methods.

4. Implement automated deletion

Manual deletion is unreliable. People forget, priorities shift, and stale data accumulates. Implement automated processes to enforce your retention schedule:

  • Set database-level TTLs (time-to-live) for data with fixed retention windows
  • Schedule periodic batch jobs that identify and purge expired records
  • Implement soft-delete with a grace period followed by hard-delete for recoverability
  • Extend deletion to backups — data deleted from production but retained in backups indefinitely still violates storage limitation
  • Verify deletion across all systems — including SaaS tools, logs, caches, and third-party processors

Maintain an audit trail of deletion actions. Supervisory authorities may ask you to demonstrate that deletion actually occurred on schedule.

5. Review annually

Retention schedules are not set-and-forget. Review them at least annually — or whenever you:

  • Collect a new category of personal data
  • Enter a new market or jurisdiction
  • Change the purpose for which data was originally collected
  • Receive guidance from a supervisory authority
  • Experience a data breach (which often reveals retention issues)

Assign a data-protection owner to each retention schedule entry. That person is responsible for keeping the period, justification, and deletion mechanism current.

Handling erasure requests

GDPR Article 17 gives data subjects the right to request deletion of their personal data (the "right to be forgotten"). When you receive an erasure request:

  1. Verify the identity of the requester
  2. Determine whether an exemption applies (legal obligation, public interest, legal claims)
  3. Locate all instances of the individual's data across all systems
  4. Delete or anonymise the data within 30 days
  5. Notify any processors or third parties to whom you disclosed the data
  6. Confirm completion to the data subject in writing

Erasure requests override your standard retention schedule. Even if data hasn't reached its retention period, a valid erasure request requires action — unless a specific exemption applies.

Documentation requirements

Under the accountability principle, you must maintain documentation that demonstrates compliance with storage limitation. At minimum, keep:

  • A formal data retention policy, approved by management
  • A retention schedule mapping data categories to periods and justifications
  • Records of retention reviews and any changes made
  • Evidence that automated deletion processes operate as intended
  • Logs of erasure requests and their outcomes
  • Audit trail of deletion actions across all systems

Common mistakes

  • Forgetting about backups.If personal data is deleted from production but lives on in backups for years, you haven't complied with storage limitation. Define a backup rotation schedule aligned with retention periods.
  • Ignoring SaaS tools.Data doesn't just live in your database. It exists in CRM systems, support platforms, email marketing tools, analytics dashboards, and communication channels. Deletion must cover all of them.
  • No audit trail."We deleted it" without evidence is an assertion, not compliance. Log every deletion action with a timestamp and the data categories affected.
  • Treating anonymisation casually.True anonymisation is irreversible. If there's any reasonable possibility of re-identification — through data linkage, inference, or retained keys — the data is pseudonymised, not anonymised, and still within GDPR scope.

Next steps

Building and enforcing a retention schedule is one of the most operationally complex parts of GDPR compliance. Regulyze's GDPR module includes data-processing inventory management, retention schedule tracking with automated alerts, and evidence collection demonstrating that your retention practices match your documented policies.

If you're ready to replace ad-hoc deletion with a structured, auditable retention program, book a demo to see how Regulyze can help.

Related articles

Automate GDPR data retention with Regulyze

Track retention schedules, automate deletion workflows, and demonstrate compliance — all in one platform.