GDPR Right to Erasure vs. Backup Retention: The Developer's Compliance Playbook 2026

When a user submits a GDPR deletion request, your primary database row disappears in milliseconds. But that same data still lives in last night's backup, yesterday's transaction log, a six-month-old cold-storage snapshot, and a dozen microservice event stores. The right to erasure under Article 17 GDPR applies to all of them.

Most developers learn this the hard way during a DPA audit. This guide explains exactly what "erasure" means across backup tiers, which technical mitigations are legally sufficient, and how to structure your deletion workflows so that a subject access request doesn't become a compliance incident.

The Legal Foundation: What Article 17 Actually Says

Article 17(1) GDPR gives data subjects the right to obtain from the controller "the erasure of personal data concerning him or her without undue delay" under six grounds — the most common for SaaS being withdrawal of consent, objection under Art.21, or the data no longer being necessary for its original purpose.

Critically, Article 17(1) contains no technical carve-out for backup systems. The law says "personal data" — not "personal data in live databases." Recital 65 reinforces this: the controller should take "every reasonable step" to inform third parties (processors) of the erasure request.

What "without undue delay" means in practice: The EDPB's guidance and national DPA decisions consistently treat 30 days as the outer boundary for primary systems. For backups, regulators accept a longer timeline — but only if:

1. You have a documented, time-bound backup rotation policy
2. The data is inaccessible during the interim period (or encrypted with a deleted key)
3. You tell the data subject when the final erasure will complete

The ICO (UK), CNIL (France), and DPC (Ireland) have all issued guidance confirming that "we will erase it when the backup expires" is a valid response — provided your backup rotation period is reasonable (typically 30–90 days) and the data cannot be restored into a live system in the interim.

The Three-Tier Problem

Think of your data persistence in three tiers, each with different erasure characteristics:

Tier 1: Active Systems (Databases, Caches, Search Indexes)

This is straightforward. SQL DELETE, Elasticsearch delete by query, Redis DEL. Your ORM cascade rules handle relational integrity. The data subject expects this done within hours.

Common gaps developers miss:

• Search index replicas not covered by deletion scripts
• Redis session stores containing user profile data
• CDN edge caches with user-generated content (requires cache invalidation or short TTL)
• Analytics events in your data warehouse (BigQuery, Redshift) — these are personal data unless properly anonymised

Tier 2: Operational Backups (Daily/Weekly Snapshots)

This is where most engineering teams have no documented process. Your nightly database dumps or snapshot backups contain the data as it existed before deletion.

Legally acceptable approaches:

Option A — Backup Isolation with Time-Bound Expiry: Mark backup sets containing the user's data as "pending erasure." Do not restore from these backups into a live system. When the backup rotation expires (e.g., at 30 or 60 days), the data is gone naturally. Document this in your ROPA and your deletion confirmation email to the user.

Option B — Encryption Key Deletion (Crypto-shredding): If each user's data in your backup is encrypted with a per-user key (stored in a KMS), deleting the KMS key renders the data permanently unrecoverable even though the encrypted bytes persist. ENISA's pseudonymisation guidelines and the EDPB's encryption guidance both recognise this as an effective erasure mechanism for backup data. The condition: the encryption must be strong (AES-256), the key must be the only decryption path, and key deletion must be immediate and irrecoverable.

Option C — Point-in-Time Selective Deletion: For databases supporting it (PostgreSQL WAL with PITR, MongoDB change streams), you can surgically remove a user's data from backup sets without invalidating the entire backup. This is technically complex but the cleanest compliance path.

Tier 3: Long-Term Archives and Audit Logs

Transaction logs, audit trails, and compliance archives present the hardest erasure problem because they often have legal retention obligations that conflict with the erasure right.

When You Can Refuse Erasure: Article 17(3) Exceptions

Article 17(3) lists six grounds where erasure does not apply. For SaaS developers, the most relevant:

17(3)(b) — Legal Obligation: If you're required to retain financial transaction data under anti-money-laundering law (e.g., AMLD6), VAT records under tax law, or employment records under national labour law, you can retain that data for the legally required period. The key is that the retention must be genuinely required by law, not just convenient.

17(3)(c) — Public Interest in Public Health: Rarely relevant for SaaS.

17(3)(e) — Legal Claims: You can retain data needed to establish, exercise, or defend legal claims. If a user has an unresolved dispute with you about a billing charge, you can retain the relevant transaction data. But you cannot use this as a blanket excuse to retain all data indefinitely.

Practical rule: Create a retention taxonomy for each data category:

The Log File Problem

Application logs are where GDPR violations silently accumulate. A typical SaaS application log line might look like:

2026-01-15T14:23:01Z INFO user_id=usr_4829 email=alice@example.com action=login ip=203.0.113.42 user_agent="Mozilla/5.0..."

Every field there is personal data under GDPR. User ID, email, IP address — all identifiable, all subject to Article 17.

What you must NOT do:

• Retain logs containing user email or full IP addresses beyond operational necessity (90 days is the common DPA expectation for security purposes)
• Index log data into searchable analytics platforms without anonymisation
• Share log data with US-headquartered log aggregation services (Datadog, Splunk Cloud US, Papertrail) without appropriate transfer mechanisms

What you should do:

Structured log anonymisation at ingestion: Replace user identifiers with pseudonyms at the point of log emission. Instead of email=alice@example.com, log user_hash=sha256(email + salt). Use a separate, access-controlled table to resolve hashes only when operationally necessary. The salt rotation policy should align with your deletion workflow: rotating or deleting the salt for a given user makes all their log entries permanently unresolvable.

IP truncation: Log 203.0.113.0 (last octet zeroed) for EU visitors, or use a /24 prefix. The CJEU confirmed in Breyer v. Germany (C-582/14) that even a truncated IP is personal data if the ISP could theoretically identify the person — but regulators accept truncation as a reasonable pseudonymisation measure that significantly reduces re-identification risk.

Log TTL enforcement: Set your log retention policy in configuration — not as a human intention. If your log aggregator (Loki, OpenSearch, Elasticsearch) supports ILM (Index Lifecycle Management), configure automatic deletion at 90 days. Make this a documented, enforced policy, not a manual cleanup task.

Microservice Event Stores and Message Queues

Event-driven architectures create erasure complexity because personal data is embedded in event payloads that may be replayed, snapshotted, or consumed by multiple downstream services.

Event sourcing and the erasure problem: If you use event sourcing (Kafka, EventStore, Axon), your event log is immutable by design. An OrderPlaced event from three years ago contains the customer's shipping address. Deleting it would break replay integrity.

Compliant approaches:

Per-entity encryption in event payloads: Encrypt personal data within event payloads using per-user keys. When erasure is requested, delete the key. Historical events remain structurally valid — they just contain unresolvable ciphertext. This is the approach recommended by the Dutch DPA (AP) in their event sourcing guidance.

Separate personal data from business events: Store event payloads with only pseudonymous identifiers (user_id: uuid). Keep the mapping between UUID and actual personal data in a separate, erasable store. When erasure is requested, delete the mapping — all historical events become permanently pseudonymous.

Kafka topic compaction with tombstone records: For Kafka topics using log compaction, you can publish a tombstone record (null value) for the user's key, which causes the compaction process to remove all previous records for that key. This requires your schema to use the user identifier as the Kafka message key.

The Processor Chain: Your Art.28 Obligations

When you process erasure requests, you are legally required under Article 17(2) to inform all processors who handle the data. This includes:

• Cloud database providers (if you've shared data through them)
• Email service providers (user email addresses in lists)
• Analytics platforms (user profiles, event data)
• CRM and support tools (Zendesk, Intercom, HubSpot)
• Cold storage services (S3, Azure Blob, GCS)

Your GDPR Data Processing Agreement (DPA) with each processor should include explicit contractual obligations for them to delete data upon your written instruction. If a processor cannot guarantee deletion within a reasonable timeframe, that is a material gap in your Art.28 compliance.

Practical approach: Build a "deletion propagation" step into your erasure workflow that automatically sends deletion API calls to your key processors. Most major SaaS processors expose deletion APIs. Document each one in your ROPA.

ROPA Documentation Requirements

Your Records of Processing Activities (Article 30 ROPA) must document:

1. Data categories and which backup system contains them
2. Retention periods — including backup rotation schedules — justified against a specific legal basis
3. Deletion procedures — the actual technical steps, not just "we will delete it"
4. Processor list with links to their sub-processor DPAs

DPAs consistently flag ROPA entries that say "retention: as long as necessary" without defining what "necessary" means per data category. A ROPA that says "transaction logs: 90 days, encrypted, auto-rotated via Loki ILM" is audit-ready. One that says "logs: as needed" is not.

The 5-Step Developer Deletion Workflow

Here is a production-ready deletion workflow that covers all three tiers:

Step 1 — Identity Resolution (Day 0): Resolve the deletion request to all internal identifiers associated with the data subject: primary user ID, historical user IDs (if accounts were merged), device IDs, session tokens, and any pseudonymous IDs in your analytics systems.

Step 2 — Active System Deletion (Day 0–1): Delete from primary database (with cascade), invalidate CDN cache entries, purge search index documents, delete session data from Redis/Memcached, trigger deletion in your analytics platform.

Step 3 — Processor Notification (Day 1–2): Send deletion API calls to all processors in your ROPA. Log the API call, the processor response, and the timestamp.

Step 4 — Backup Handling (Day 1 → Backup Expiry): Either: (a) mark backup sets containing the user as "do not restore," document the expiry date, and confirm to the user when final erasure will complete; or (b) if using crypto-shredding, delete the per-user KMS key immediately and document this as the erasure action.

Step 5 — Confirmation and Documentation (Day 1–30): Send the user a deletion confirmation email stating: what was deleted, which systems still contain it (backup only), and the date by which backup erasure will complete. Retain this confirmation record for 3 years (Art.17(3)(e) legal claims ground — ironic but necessary).

Infrastructure Jurisdiction Matters

If your backup infrastructure is operated by a US-headquartered cloud provider (AWS S3, Azure Blob, Google Cloud Storage), the CLOUD Act means US law enforcement can compel access to those backups — even if the data is stored in EU regions. This is a separate but related compliance issue.

Implication: A GDPR deletion request fulfilled on your side does not prevent a CLOUD Act compelled disclosure of backup data that should have been deleted but hasn't been yet. This makes prompt backup deletion not just a GDPR obligation but a data security measure.

EU-native backup storage (Hetzner Storage Box, OVHcloud Object Storage, Scaleway Object Storage, Exoscale SOS) removes this exposure entirely. Your Data Processing Agreement with an EU-native provider will never contain CLOUD Act override language, because no such obligation exists under EU law.

What DPAs Have Said: Enforcement Examples

ICO (UK) — Right to Erasure Audit 2024: The ICO noted that organisations frequently failed to include backup data in their deletion processes. Its guidance explicitly states that while a time-bound approach is acceptable, "indefinite retention in backups because deletion is technically difficult is not a compliant response."

CNIL — Retention Period Decisions: The CNIL has fined multiple companies for retaining personal data in backup systems beyond documented retention periods. The most common finding: the live system was compliant, but the backup system had no automated rotation.

EDPB — Opinion on Erasure in Event-Sourced Systems (2023): The Board endorsed per-entity encryption and pseudonymous event identifiers as compliant approaches for immutable event logs, confirming that crypto-shredding satisfies Article 17 obligations.

Quick Reference: Erasure Obligations by Data Store

Takeaway

The GDPR right to erasure is not a checkbox you tick when you delete the database row. It follows data across every system where it was ever written — backup, log, event store, and processor. The good news: regulators accept technical solutions that make data permanently inaccessible (crypto-shredding, time-bound backup rotation) as equivalent to physical deletion. The key requirements are documentation, time-bounded commitments, and a propagation workflow that reaches your entire processor chain.

If your backup strategy is "we restore when something breaks," your erasure strategy is "we don't have one." Build the deletion workflow into your data architecture from the start, and your next DPA audit will be significantly less stressful.

Running EU-native infrastructure ensures that your backup data is subject exclusively to GDPR — not CLOUD Act compelled disclosure. sota.io provides managed EU-native application hosting with storage endpoints in EU-controlled jurisdictions.