GDPR Data Retention Periods 2026: Sector-by-Sector Developer Reference and Implementation Guide

Most SaaS applications store personal data indefinitely. User accounts from 2019 with no activity, payment records from closed subscriptions, support tickets from customers who churned three years ago — all still sitting in production databases. Under GDPR Article 5(1)(e), this is a violation.

The storage limitation principle is deceptively simple: keep personal data "no longer than is necessary for the purposes for which the personal data are processed." The enforcement reality is more complex, because "necessary" is sector-specific, purpose-specific, and increasingly the subject of DPA fines. This guide gives you a concrete reference for defensible retention periods across 15+ categories, plus the implementation patterns to actually enforce them.

The Legal Foundation: Article 5(1)(e) and Its Exceptions

Article 5(1)(e) GDPR 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." The same article carves out exceptions for archiving in the public interest, scientific or historical research purposes, and statistical purposes under Article 89.

Two critical consequences for SaaS developers:

1. "No longer than necessary" is not self-defining. If you collect email addresses for transactional emails, the retention period is not "forever." It ends when the transactional relationship ends — typically when a user account is deleted and the limitation period for disputes expires. A user who cancelled in 2022 doesn't have a legitimate reason to appear in your mailing list in 2026.

2. You must document the retention period before collection begins. Article 30 (RoPA) requires the controller to record "the envisaged time limits for erasure of the different categories of data." If your RoPA says "as long as necessary," that is not compliant — it is a cop-out that DPAs have consistently rejected. You must specify a concrete period, even if it is "3 years from account deletion."

The dual-purpose trap: Many organizations keep data for "business analytics" or "fraud prevention" far longer than the original purpose requires. Using old customer data for new purposes requires either a compatible purpose assessment under Article 6(4) or a new legal basis — and "we might need it someday" is neither.

Sector-by-Sector Retention Periods

The following periods reflect legal minimums (set by sector regulation) and maximum defensible windows (based on DPA guidance, statute of limitations, and enforcement precedent). Where a minimum exists, you must keep data at least that long. The maximum is where GDPR's storage limitation principle kicks in — keeping data beyond the maximum requires a documented, specific justification.

Financial Services and Payments

Developer implication: If you build fintech infrastructure, your data deletion jobs must respect these minimums. Deleting a payment record 3 years after account closure creates both GDPR compliance problems (you can't respond to a SAR) and financial regulation problems (you can't produce records for an AML inquiry). The correct approach is a delete_eligible_at timestamp calculated at record creation.

Employment and HR

Developer implication: HR platforms are the most common source of unnecessary long-term retention. Rejected job applications are particularly problematic — keeping them longer than 6 months without consent is cited in multiple DPA decisions. If you build an ATS, implement automatic purging of rejected candidate records at 6 months post-decision unless the candidate explicitly opts in to a talent pool.

Healthcare and Medical

Developer implication: Health data is special category data under Article 9 GDPR, requiring explicit consent or a legal basis under Article 9(2). The retention periods are set by member state health law, not by GDPR directly — but GDPR's storage limitation principle still applies, meaning you cannot keep health data longer than the national law requires without a specific documented justification. If your SaaS serves healthcare, your data retention policy must reference the applicable national health law, not just GDPR.

E-Commerce and Retail

Developer implication: VAT audit periods are the dominant retention driver for e-commerce. In Germany, the Abgabenordnung requires 10-year retention of financial records. An order with personal data (name, address, VAT number) must therefore be retained for at least 10 years from the tax year end, even after a customer deletes their account. The practical solution: anonymize all non-financially-necessary fields at account deletion (name → "Deleted User," address → country only) and retain only what the tax obligation requires.

SaaS / Software / Technology

Developer implication: The 90-day post-deletion retention window is not a GDPR rule — it is a commonly accepted grace period based on DPA tolerance for dispute handling and accidental deletion scenarios. After 90 days, you need a documented legitimate interests assessment to retain any identified user data. If a user deletes their account in January and you still have their email in your CRM in December, you need to justify it.

Marketing and Advertising

Developer implication: The suppression list is a classic trap. You must keep unsubscribed email addresses in a suppression list forever — because if you delete them, you have no way to prevent re-subscribing them when you receive new marketing consent (which your CRM might have from a third-party source). The address stays; all other data associated with it is deleted. This is a separate table, minimal data (hash of email + timestamp), not a contradiction of storage limitation.

Legal and Contract

Developer implication: If your SaaS acts as a data processor (i.e., you process data on behalf of customers), you must retain your DPA agreements for at least 3 years after expiry according to EDPB Working Party guidance. This is part of your accountability obligations under Article 5(2) — being able to demonstrate compliance when a supervisory authority inquires.

Implementing a Retention Schedule in Code

Pattern 1: Delete-Eligible Timestamp

Add a delete_eligible_at column to tables containing personal data. Set it at record creation based on the applicable retention period.

ALTER TABLE user_accounts 
  ADD COLUMN delete_eligible_at TIMESTAMPTZ;

-- Set at account closure:
UPDATE user_accounts 
SET 
  delete_eligible_at = NOW() + INTERVAL '2 years',
  status = 'closed'
WHERE id = $1;

-- Scheduled deletion job (run daily):
DELETE FROM user_accounts 
WHERE delete_eligible_at < NOW() 
  AND status = 'closed';

Pattern 2: Retention Policy Enum

For tables serving multiple purposes (e.g., audit logs used for both security and compliance), a policy enum makes the retention rationale explicit and auditable.

CREATE TYPE retention_policy AS ENUM (
  'active_account',        -- retain while account active
  'post_deletion_grace',   -- 90 days post account deletion
  'financial_record',      -- 10 years (tax obligation)
  'security_audit',        -- 1 year (security incident investigation)
  'compliance_audit',      -- 3 years (compliance demonstration)
  'suppression_list'       -- indefinite (re-subscription prevention)
);

ALTER TABLE data_records 
  ADD COLUMN retention_policy retention_policy NOT NULL,
  ADD COLUMN delete_eligible_at TIMESTAMPTZ;

Pattern 3: Anonymization Instead of Deletion

For records where some fields must be retained (e.g., financial totals, aggregate statistics) but personal identifiers must be removed:

-- At account deletion, anonymize rather than delete order records:
UPDATE orders
SET
  customer_name = 'Deleted User',
  customer_email = NULL,
  shipping_address = jsonb_build_object('country', shipping_address->>'country'),
  ip_address = NULL,
  anonymized_at = NOW()
WHERE customer_id = $1 AND order_status IN ('completed', 'refunded');

-- Retain: order_total, tax_amount, order_date, country (for VAT compliance)
-- Delete: name, email, full address, IP (not required for VAT)

Pattern 4: Cascading Retention

In microservice architectures, account deletion must cascade to all services holding the user's personal data. A common implementation:

# account-deletion-service/src/delete_account.py
async def delete_account(user_id: str, reason: str):
    # Mark for deletion in account service
    await accounts_db.mark_deleted(user_id, reason)
    
    # Emit deletion event for all downstream services
    await event_bus.publish("account.deletion.requested", {
        "user_id": user_id,
        "reason": reason,
        "requested_at": datetime.utcnow().isoformat(),
        "grace_period_ends": (datetime.utcnow() + timedelta(days=90)).isoformat(),
    })

# Each service subscribes and handles according to its retention policy:
# billing-service: retain financial records, anonymize personal fields
# support-service: close open tickets, retain closed tickets for 3 years
# marketing-service: add to suppression list, delete profile data
# analytics-service: already anonymized (no personal data)

RoPA Documentation Requirements

Article 30 requires controllers to document "the envisaged time limits for erasure of the different categories of data." Your Record of Processing Activities must have a retention period for every row. Here is what DPA auditors expect:

Processing Activity: User Account Management
Data Categories: Contact data, authentication data, usage data
Retention Period: 
  - Active accounts: Duration of contract
  - Churned accounts: Contract end + 90 days (grace period)
  - Financial records within account: 10 years (§257 HGB / national VAT law)
  - Support correspondence: Account deletion + 3 years
Legal Basis for Retention After Account Deletion:
  - 90-day grace period: Art.6(1)(f) legitimate interests (accidental deletion, dispute handling)
  - Financial records: Art.6(1)(c) legal obligation (tax law)
  - Support correspondence: Art.6(1)(f) legitimate interests (limitation period)
Deletion Method: Scheduled job (runs daily), anonymization for financial records

Vague entries like "as long as necessary" or "until no longer required" are non-compliant under Article 30 and will be flagged by any competent DPA auditor.

Enforcement: What DPAs Actually Fine

The CNIL, DSK (German DPA coalition), ICO, and DPC have all issued fines specifically for unlawful retention. Notable patterns:

Unnecessary long-term retention: CNIL fined a French company €300,000 in 2022 for retaining prospect data for 5 years without re-engagement activity — the legal defensible maximum was 3 years.

No deletion mechanism: Multiple DPAs have fined organizations that had no technical mechanism to delete personal data at all. The fine is not for keeping data too long per se, but for having no process — demonstrating that data protection was not designed in (Article 25, privacy by design).

Backup retention: The DSK has issued guidance that backup retention cannot be used to circumvent erasure rights. If a backup contains personal data that should have been deleted, it must be excluded from the next backup cycle or the backup itself deleted at its normal rotation.

Audit logs with personal data: The EDPB Opinion 7/2020 on the concept of controller and processor notes that audit logs containing user IDs (which can be personal data) must comply with storage limitation. Retaining audit logs indefinitely for "security" without a documented, limited retention period violates Article 5(1)(e).

Choosing EU Infrastructure for Enforcement

Implementing a GDPR-compliant retention schedule requires that your deletion jobs actually work. This sounds obvious, but it has an infrastructure consequence: if your data is stored in a US-jurisdiction cloud, your deletion requests to their APIs are subject to US law, including orders under 18 U.S.C. § 2703 that can compel providers to retain and not disclose data. CLOUD Act orders can freeze data you have legally committed to deleting.

Running your scheduled deletion jobs on EU-hosted infrastructure with EU-jurisdiction storage ensures that your retention policy is enforceable without US-law interference. For SaaS companies processing health data, financial data, or children's data — categories with the strictest retention rules — this is not just a compliance preference; it's a risk management necessity.

European PaaS platforms like sota.io provide the infrastructure layer with full GDPR accountability chains: EU-based processing, EU-jurisdiction processors, no US-parent with access to stored data, and Data Processing Agreements that actually align with your deletion obligations.

The Retention Schedule Checklist

Before your next deployment or DPA audit:

• Every table with personal data has a delete_eligible_at column or equivalent
• Scheduled deletion jobs exist and are tested (check logs monthly)
• RoPA has a specific retention period for every processing activity (no "as necessary")
• Account deletion triggers cascading events to all services
• Financial records are anonymized at deletion, not deleted (VAT audit compliance)
• Suppression lists are maintained (unsubscribed emails kept in minimal form)
• Backup rotation policy is documented and backup age ≤ maximum retention period
• Rejected job applications are purged at 6 months or transferred to talent pool with consent
• Support tickets are closed and eligible for deletion 3 years after close
• Audit logs have a documented 1-year or 3-year retention period with rationale

GDPR enforcement is moving from consent and transparency to data minimization and storage limitation. The next wave of DPA fines will be about organizations that collect everything and delete nothing. Building retention into your data model now — not after the audit letter arrives — is the technical implementation of GDPR compliance, not a legal nicety.