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

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

Every byte of personal data your organization stores is a ticking clock. Under the General Data Protection Regulation, there is no universal expiration date — but there is a clear mandate: you cannot keep personal data longer than necessary for the purpose it was collected. Violate that principle, and you face fines of up to €20 million or 4% of global annual turnover, whichever is higher.

Yet most companies struggle with a deceptively simple question: how long is "necessary"? A 2025 survey by the International Association of Privacy Professionals (IAPP) found that 68% of organizations lack a formal data retention schedule, and 41% admitted they had no reliable way to identify what personal data they were even storing. The result is sprawling data estates filled with forgotten customer records, outdated employee files, and orphaned databases — each one a compliance liability waiting to surface during an audit or breach investigation.

The problem is getting worse, not better. With enforcement accelerating — European Data Protection Authorities issued over €4.5 billion in cumulative GDPR fines by end of 2025 — regulators are increasingly targeting data minimization and retention failures alongside headline-grabbing consent violations. If your retention strategy is "keep everything, just in case," it is time to rethink your approach.

What the GDPR Actually Says About Data Retention


Article 5(1)(e) of the GDPR establishes the storage limitation principle: 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." This is one of the six core processing principles, and it carries the same enforcement weight as lawfulness and consent.

Crucially, the GDPR does not prescribe specific retention periods. Instead, it places the burden on the data controller to determine and justify appropriate timeframes. You must be able to answer two questions for every category of personal data you hold:

1. Why are you keeping it? — There must be a documented, lawful purpose. 2. When will that purpose expire? — There must be a defined retention period or a set of criteria for determining when deletion should occur.

The regulation does allow for longer retention when data is processed solely for archiving in the public interest, scientific or historical research, or statistical purposes (Article 89), provided appropriate technical and organizational safeguards are in place.

Building a Data Retention Schedule: A Step-by-Step Approach


A retention schedule is the backbone of your compliance program. Here is how to build one that holds up under regulatory scrutiny.

Step 1: Inventory your data. Before you can set retention periods, you need to know what personal data you hold, where it lives, and why it was collected. This is where most organizations fail — data sprawls across SaaS platforms, legacy databases, shared drives, and employee laptops.

Step 2: Map each data category to a legal basis and purpose. For example:

• Customer billing records → Contract performance → Retain for duration of contract + statutory tax retention period
• Job applicant CVs → Legitimate interest → Delete 6 months after hiring decision unless consent is obtained for talent pool
• Website analytics cookies → Consent → Delete per cookie policy (typically 13 months, per CNIL guidance)

Step 3: Research sector-specific statutory requirements. Many jurisdictions impose minimum retention periods that override your desire to delete. Common examples:

| Data Category | Statutory Requirement | Jurisdiction | |---|---|---| | Tax and accounting records | 6–10 years | Most EU member states | | Employee payroll records | 5–7 years after employment ends | Germany, France, UK | | Medical records | 10–30 years | Varies by country | | Anti-money laundering (AML) records | 5 years after relationship ends | EU 5th Anti-Money Laundering Directive | | Telecommunications metadata | 6–12 months | EU (varies post-Digital Rights Ireland) |

Step 4: Define deletion or anonymization procedures. For each category, document whether data will be deleted, anonymized, or pseudonymized at the end of its retention period — and who is responsible for executing that process.

Step 5: Automate enforcement. Manual deletion processes do not scale. Implement automated retention policies in your data infrastructure.

Common Retention Mistakes That Trigger Fines


Regulators have made clear through enforcement actions what "getting it wrong" looks like. Here are patterns to avoid:

Indefinite retention with no justification. In 2023, the Swedish Data Protection Authority (IMY) fined Spotify €5 million in part for failing to adequately inform users about how long their data would be retained. The takeaway: "we might need it someday" is not a valid retention justification.

Retaining data after the purpose has expired. The French CNIL fined Clearview AI €20 million in 2022, with one basis being the indefinite retention of biometric data with no defined deletion timeline. Once the purpose is fulfilled, the clock starts ticking toward deletion.

Confusing backup retention with active retention. Many organizations delete data from production systems but leave it in backups for years. Regulators expect you to have a strategy for backup data too. The Article 29 Working Party (now EDPB) has clarified that backup copies are not exempt from retention limits — though phased deletion approaches are acceptable if documented.

No retention schedule at all. Deutsche Wohnen SE received a €14.5 million fine from the Berlin Data Protection Authority in 2019 (later reduced on appeal) specifically because the company's archiving system had no mechanism for deleting tenant data once it was no longer needed.

Implementing Automated Retention in Your Tech Stack


For engineering teams, turning policy into practice means building retention logic into your data infrastructure. Here is a practical example using PostgreSQL with a scheduled cleanup job:

`sql -- Create a retention policy table CREATE TABLE data_retention_policies ( id SERIAL PRIMARY KEY, table_name VARCHAR(255) NOT NULL, data_category VARCHAR(255) NOT NULL, retention_days INTEGER NOT NULL, legal_basis TEXT NOT NULL, deletion_method VARCHAR(50) DEFAULT 'hard_delete', -- or 'anonymize' created_at TIMESTAMP DEFAULT NOW() );

-- Insert retention rules INSERT INTO data_retention_policies (table_name, data_category, retention_days, legal_basis) VALUES ('customer_support_tickets', 'support_correspondence', 730, 'Legitimate interest - service improvement'), ('job_applications', 'applicant_pii', 180, 'Legitimate interest - recruitment'), ('user_activity_logs', 'behavioral_data', 90, 'Consent - analytics');

-- Automated cleanup function CREATE OR REPLACE FUNCTION enforce_retention_policies() RETURNS void AS $$ DECLARE policy RECORD; BEGIN FOR policy IN SELECT * FROM data_retention_policies LOOP EXECUTE format( 'DELETE FROM %I WHERE created_at < NOW() - INTERVAL ''%s days''', policy.table_name, policy.retention_days ); RAISE NOTICE 'Retention enforced on % — removed records older than % days', policy.table_name, policy.retention_days; END LOOP; END; $$ LANGUAGE plpgsql; `

Schedule this function to run nightly via pg_cron or an external scheduler. For anonymization instead of deletion, replace the DELETE with an UPDATE that nullifies or hashes PII columns while preserving aggregate data.

For cloud-native architectures, consider:

• AWS S3: Use S3 Lifecycle Policies to automatically transition or expire objects based on age.
• Google Cloud Storage: Object Lifecycle Management rules can delete objects after a defined period.
• Azure Blob Storage: Lifecycle management policies support rule-based deletion and tiering.

The critical prerequisite for all of this is knowing which fields contain PII in the first place — a challenge that grows exponentially as data pipelines multiply and schemas evolve.

The Role of PII Discovery in Retention Compliance

You cannot enforce a retention policy on data you do not know exists. This is the fundamental gap that undermines most retention programs.

Personal data does not stay neatly in the columns labeled "email" and "phone_number." It leaks into free-text fields, log files, support tickets, PDF attachments, spreadsheets on shared drives, and Slack exports. A 2024 study by Varonis found that the average organization has over 500,000 files containing sensitive data that are open to every employee.

Effective retention enforcement requires continuous PII discovery — scanning structured and unstructured data sources to identify where personal data actually resides. Without this, your retention schedule is a policy document, not a functioning control.

Key capabilities to look for in a PII detection tool:

• Multi-format scanning: Databases, file systems, cloud storage, and SaaS platforms
• Contextual detection: Identifying PII based on patterns and context, not just regex matching on known column names
• Classification and mapping: Automatically categorizing discovered PII by type (name, email, national ID, biometric) and linking it to your retention schedule
• Continuous monitoring: Alerting when new PII appears in unexpected locations, so retention rules can be extended before data accumulates

Data Retention Under CCPA: Key Differences

While the focus here is GDPR, organizations operating in the United States must also consider the California Consumer Privacy Act (CCPA), as amended by the CPRA. The retention requirements share the same spirit but differ in specifics:

• The CCPA requires businesses to disclose retention periods (or the criteria used to determine them) in their privacy policy — a requirement that took effect January 1, 2023.
• Unlike GDPR, the CCPA does not explicitly define "storage limitation" as a processing principle, but the CPRA added data minimization requirements that effectively create retention obligations.
• Regulations under the CPRA (Section 7002) require that retention periods be "no longer than reasonably necessary" for each disclosed purpose.

For global organizations, the practical approach is to align with the stricter framework (typically GDPR) and use that as your baseline. Any data subject to both regimes should follow the shorter applicable retention period.

Documenting and Auditing Your Retention Program

Documentation is not optional — it is your primary defense in a regulatory inquiry. Your retention program documentation should include:

• Data retention schedule: The complete table of data categories, purposes, legal bases, retention periods, and deletion methods.
• Records of Processing Activities (ROPA): Required under GDPR Article 30, this must include retention periods for each processing activity.
• Data Protection Impact Assessments (DPIAs): For high-risk processing, your DPIA should evaluate whether your retention periods are proportionate.
• Deletion logs: Auditable records proving that data was actually deleted on schedule, not just flagged for deletion.
• Exception register: Documented justifications for any data held beyond standard retention periods (e.g., litigation hold, ongoing investigation).

Conduct retention audits at least annually. Sample data stores to verify that automated deletion is functioning correctly and that no new data categories have appeared without corresponding retention rules.

Frequently Asked Questions

Can I keep personal data indefinitely if I anonymize it?

Yes — once data is truly anonymized (meaning it cannot be re-identified by any reasonably available means), it falls outside the scope of the GDPR entirely and can be retained without limit. However, the bar for anonymization is high. The EDPB and courts have emphasized that pseudonymization (replacing identifiers with tokens while retaining the ability to re-link) does not qualify. If there is any realistic possibility of re-identification — through cross-referencing, statistical inference, or combining datasets — the data remains personal data subject to retention limits. Be especially cautious with location data, behavioral profiles, and small datasets where uniqueness makes anonymization difficult.

What happens if a statutory retention period conflicts with a data subject's erasure request?

Statutory obligations override erasure requests. If you are legally required to retain tax records for seven years, a customer's Article 17 right to erasure does not compel you to delete those records prematurely. However, you should restrict processing of that data to the statutory purpose only, inform the data subject that their request is partially fulfilled, and delete the data as soon as the statutory period expires. Document every such decision in your exception register.

Do backups need to follow the same retention policies as production data?

In principle, yes. The GDPR does not carve out an exemption for backup systems. However, regulators generally accept a pragmatic approach: if your backup architecture makes granular deletion technically infeasible, you should document this limitation, set backup retention periods as short as operationally reasonable (e.g., 90 days rather than perpetual), ensure that restored data is immediately subject to retention enforcement, and encrypt backups and limit access to reduce risk. The key is demonstrating that you have considered backup data in your retention strategy and are not using backups as a loophole to retain data indefinitely.

How do I handle retention for data shared with third-party processors?

Under GDPR Article 28, your data processing agreements (DPAs) must include provisions for data return or deletion upon termination of the processing relationship. You should specify retention limits in the DPA that align with your own schedule, require processors to confirm deletion in writing, conduct periodic audits to verify processor compliance, and remember that as the controller, you remain accountable for data held by your processors. The 2024 EDPB Guidelines on Data Transfers reinforced that controllers must verify — not just contractually require — that processors are adhering to retention and deletion commitments.

What is the minimum I need to do to demonstrate retention compliance during a regulator audit?

At minimum, auditors will expect to see a documented retention schedule covering all categories of personal data, evidence that the schedule is being enforced (deletion logs, automated policy configurations), inclusion of retention periods in your ROPA and privacy notices, a process for handling exceptions and litigation holds, and evidence that the retention program is reviewed and updated periodically. The strongest compliance posture combines documented policy, automated enforcement, and continuous PII discovery — ensuring that no personal data falls outside your retention framework, even as your data estate evolves.

Start Scanning for PII Today

PrivaSift automatically detects PII across your files, databases, and cloud storage — helping you stay GDPR and CCPA compliant without the manual work.

[Try PrivaSift Free →](https://privasift.com)