Right to Erasure (Article 17): How to Process GDPR Deletion Requests Across Cloud Systems
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Right to Erasure (Article 17): How to Process GDPR Deletion Requests Across Cloud Systems
Article 17 — the right to erasure, often called the right to be forgotten — sounds simpler than it is. A data subject sends a request, the controller has one month (extendable by two more under Article 12(3)) to act, and the personal data is gone. The legal text is six paragraphs. The operational reality is the hardest piece of GDPR engineering most enterprises do, because personal data lives in dozens of systems each with their own retention semantics, and "delete" means different things in object storage, in event streams, in backups, in data warehouses, and in ML feature stores.
This piece is for engineers and CISOs designing the actual deletion workflow, not the policy statement. It assumes you know what Article 17 says and need to make it work across S3, Snowflake, Kafka, Databricks, Salesforce, and your data lakehouse without breaking compliance with conflicting retention obligations.
The Six Article 17(1) Grounds
Article 17(1) lists six grounds where erasure is mandatory: the data is no longer necessary for the purpose, the data subject withdraws consent (where consent was the basis), the data subject objects under Article 21 and there are no overriding legitimate grounds, the data has been unlawfully processed, erasure is required by EU or member state law, or the data was collected from a child under Article 8(1). Most enterprise erasure requests fall under grounds (a) — no longer necessary — and (b) — consent withdrawn. Both require the controller to know which lawful basis applies to which dataset.
Article 17(3) lists the exceptions: freedom of expression, legal obligation to retain, public-interest tasks, public-health archiving, scientific/historical research, and legal claims. Tax retention obligations under member-state law (typically 7-10 years), AML record-keeping, and active litigation holds all fall under exception (b). The standard pattern is conditional erasure — delete from operational systems immediately, retain in a legally-locked archive bucket with access restricted to legal/compliance until the retention period expires.
Inventory: You Cannot Erase What You Do Not Know You Have
Erasure begins with the Article 30 record of processing activities. The RoPA must list, for each processing activity, where the data is stored — including processors and sub-processors. In practice the RoPA is necessary but insufficient; engineering teams need a data lineage map that resolves a subject identifier (customer ID, email, account number) to every physical store. Modern data catalogues (Unity Catalog, Atlan, Collibra) help but rarely cover the full estate; CRM systems, support ticketing, marketing automation, BI extracts, and SaaS sub-processors all need their own integration.
The minimum viable inventory has three columns: system name, identifier shape (customer_id, email_hash, internal_user_id), and erasure mechanism (API, SQL, ticket-based manual). When the deletion request arrives, the workflow iterates the list. Anything not in the list is a compliance gap waiting to be found by a supervisory authority.
Need expert help with right to erasure (article 17)?
Our cloud architects can help you with right to erasure (article 17) — from strategy to implementation. Book a free 30-minute advisory call with no obligation.
System-by-System Erasure Patterns
Different stores require different patterns. The table below summarises the patterns we use across customer cloud estates.
| System type | Erasure pattern | Common pitfall |
|---|---|---|
| Operational RDBMS (Postgres, MySQL, RDS) | UPDATE to NULL or DELETE WHERE id = ?, plus cascade to dependent rows | Forgetting binlog / WAL retention; replicas not yet caught up |
| Object storage (S3, ADLS, GCS) | DELETE objects + delete versions if versioning enabled + lifecycle to purge delete markers | S3 Object Lock or compliance-mode WORM blocks deletion |
| Data warehouse (Snowflake, BigQuery, Redshift) | DELETE row + run VACUUM / OPTIMIZE; clear time-travel history | Time-travel default 90 days; data still recoverable |
| Lakehouse (Databricks Delta) | DELETE FROM + VACUUM with retention 0 hours (after disabling safety check) | Default 7-day VACUUM retention leaves files |
| Event streams (Kafka, Kinesis) | Compact-topic null-tombstone OR retention-period expiry | Long-retention topics leak data; consumer offsets retain references |
| Search indexes (Elasticsearch, OpenSearch) | DELETE by query + force merge to expunge deletes | Snapshots in S3 still contain the data |
| Backups | Crypto-shred via per-tenant key revocation, OR document retention until expiry | Selective deletion in backups is impractical at scale |
| ML feature stores / training data | Delete from feature store + retrain models if subject contributed materially | Article 22 model unlearning is an emerging area; document the approach |
Two patterns deserve highlighting. Crypto-shredding for backups: instead of selectively deleting subject data from petabytes of backups, encrypt each subject (or tenant) with a unique key derived from the subject identifier, and on erasure, destroy the key. The backups remain but are cryptographically inaccessible. The EDPB has not formally endorsed crypto-shredding as Article 17 erasure, but several DPAs have accepted it where the alternative is manifestly disproportionate effort under Article 17(1). Document the design and the key-destruction event.
Time-travel and version retention: Snowflake Time Travel, Databricks Delta time-travel, BigQuery snapshots, and Postgres point-in-time recovery all retain pre-deletion state for a configurable window. Article 17 requires deletion of the personal data, not just the current row. Either reduce time-travel retention before deletion, or document the residual exposure window in the response to the data subject.
Article 17(2): The Notification Obligation Most Controllers Miss
Article 17(2) requires the controller, where it has made the personal data public, to take reasonable steps to inform other controllers processing that data of the erasure request. In a B2B SaaS context, this often means notifying integration partners, public-facing index providers, and any party the data was syndicated to. It is rarely enforced strictly but is a common audit finding when the supervisory authority is already on-site.
For sub-processors under Article 28, the obligation flows through the data processing agreement. Your DPA should require sub-processors to action erasure requests on receipt and confirm completion. Track the confirmations; the lead supervisory authority will ask for evidence under the one-stop-shop mechanism.
Edge Cases: Joint Controllers, Public Records, and AI Models
Joint controllers under Article 26 must agree on which party handles erasure requests. The arrangement must be transparent to the data subject. A common failure mode in ad-tech and platform ecosystems is unclear allocation; the data subject sends the request to one joint controller, who declines on the basis the other holds the data, and 30 days lapse. Article 26(3) is explicit: the data subject may exercise their rights against either joint controller.
Personal data in AI training data is the open frontier. The Italian Garante's March 2023 ChatGPT order, the Hamburg DPA's April 2024 opinion on LLM training, and the EDPB's December 2024 opinion on AI models all converge on a position: training data inclusion is processing, and Article 17 applies. Whether output suppression is sufficient or whether retraining is required remains contested. The pragmatic 2026 position is to prevent inclusion via consent and legitimate-interest gating at training time, retain the ability to retrain or fine-tune to remove a specific subject's contribution if requested, and document the decision. A more comprehensive defensive approach is part of the managed detection and response and AI-governance posture we deploy with customers operating LLM products.
Documenting Refusal Lawfully
When Article 17(3) exception applies — typically a tax-retention or active-litigation hold — refusal must be communicated to the data subject within one month under Article 12(4), with reasons, and with information on the right to complain to the supervisory authority and to seek a judicial remedy. The most common defect is silence; a non-response is treated as a refusal without reasons, which is itself a breach of Article 12. Maintain a templated refusal letter pre-cleared by legal, customised per case, and log the dispatch.
How Opsio Helps
Opsio builds and operates Article 17 erasure workflows for customers running multi-cloud data estates. Our work covers data inventory and lineage mapping, system-by-system deletion playbooks across the 8 store classes above, crypto-shredding designs for backup compliance, sub-processor coordination, and the integration with broader request a GDPR readiness review. We pair the workflow with data governance consulting so the RoPA, retention schedules, and erasure mechanics are a single coherent system, and with sectoral overlays for customers also running India data protection consulting programmes in India where the right-to-erasure framing differs.
About the Author
Group COO & CISO
Fredrik is the Group Chief Operating Officer and Chief Information Security Officer at Opsio. He focuses on operational excellence, governance, and information security, working closely with delivery and leadership teams to align technology, risk, and business outcomes in complex IT environments. He leads Opsio's security practice including SOC services, penetration testing, and compliance frameworks.
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.