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 type | Typical retention | Rationale |
|---|---|---|
| Customer account data | Duration of contract + 12 months | Service delivery + reasonable follow-up period |
| Transaction records | 7 years | Tax and financial reporting obligations |
| Marketing consent records | Duration of consent + 3 years | Demonstrating valid consent if challenged |
| Employee records | Duration of employment + 6 years | Employment law limitation periods (UK/EU) |
| Website analytics (with PII) | 26 months | Aligned with common tool defaults; minimise where possible |
| Support tickets | 3 years after resolution | Service improvement and dispute resolution |
| Job applicant data | 6–12 months post-decision | Recruitment process review; discrimination claim limitation |
| CCTV footage | 30 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.
2. Identify the legal basis for each data type
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:
- Verify the identity of the requester
- Determine whether an exemption applies (legal obligation, public interest, legal claims)
- Locate all instances of the individual's data across all systems
- Delete or anonymise the data within 30 days
- Notify any processors or third parties to whom you disclosed the data
- 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
The SOC 2 Readiness Checklist: 12 Steps Before Your First Audit
A practical, step-by-step checklist covering everything from scoping your Trust Services Criteria to preparing your evidence room — so your first SOC 2 audit goes smoothly.
How to Build a Vendor Risk Management Framework That Actually Works
Most vendor risk programs start strong and die in a shared spreadsheet. Here's how to build one that scales — with automated assessments, tiered scoring, and continuous monitoring.