How Long Can You Keep Personal Data Under GDPR? (It's Not "Forever")

The Storage Limitation Principle

Article 5(1)(e) requires that personal data 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." When the purpose is gone, the legal basis for holding the data is gone.

The practical implication: you need a defined retention period for every category of personal data you hold, documented in your privacy policy or a Record of Processing Activities (RoPA). "We keep it until you delete your account" is a retention policy. "We keep it indefinitely" is not.

Common Retention Periods by Data Type

These aren't GDPR mandates — they're what's commonly defensible based on legal obligations and DPA guidance:

• →Financial and billing records: 6–7 years. Required by tax law in most EU member states. UK HMRC requires 6 years; German Handelsgesetzbuch requires 10 years for some records.
• →Marketing consent records: Until the person withdraws consent, plus a reasonable period after to demonstrate compliance history (typically 1 year after withdrawal). When a data breach occurs, having minimal old data reduces what's exposed.
• →Web server logs (IP addresses, access logs): 30–90 days is common. The CNIL recommends no more than 12 months for security purposes.
• →Closed/cancelled customer accounts: Long enough to handle disputes and chargebacks (typically 12–24 months post-closure), then delete.
• →Application/error logs containing user data: 30–90 days. Log data often contains PII accidentally — IP addresses, user IDs, sometimes email addresses in error messages.
• →Job application data (unsuccessful candidates): ICO guidance suggests 6 months. Some DPAs suggest up to 12 months to handle any discrimination claims.
• →Support tickets: Duration of customer relationship plus 1–2 years. Longer if there are ongoing disputes.

Automated Deletion vs Manual Review

Setting a retention period is the easy part. The hard part is actually deleting the data when the period expires. This intersects directly with users' right to erasure — shorter retention periods reduce the scope of what needs deleting. Most organisations have data sitting in databases, data warehouses, backups, and spreadsheets that should have been deleted years ago.

The gold standard is automated deletion: a scheduled job that deletes records past their retention period. Many databases support this natively (PostgreSQL with partitioning, for example). For simpler cases, a weekly cron job that queries for expired records and deletes them works fine.

If automated deletion isn't feasible for some data, you need a documented manual review process — who reviews, on what schedule, and what the decision criteria are. "We'll get around to it" isn't a process.

Anonymisation vs Pseudonymisation

Genuinely anonymised data is outside GDPR's scope — you can keep it indefinitely. But "anonymised" has a high bar: the data must be irreversibly de-identified such that the individual cannot be re-identified even by combining it with other data.

Pseudonymisation — replacing names with IDs, hashing email addresses — is not anonymisation. It's a security measure, and GDPR acknowledges it. But pseudonymised data is still personal data under GDPR because re-identification is possible (especially if you hold the key).

If you're aggregating analytics data (total monthly visitors, average session duration), that's typically genuinely anonymised and falls outside GDPR. If you're keeping a hashed email with behavioural data, that's pseudonymised — still regulated.