GDPR / RULE REFERENCE

Art. 17 — Right to erasure

Article 17 is where privacy programs meet their write path. "Without undue delay" means days in practice, and "taking into account available technology" means your architecture is the excuse — or the defense. Controllers must also notify downstream recipients, so deletion is not a row problem; it is a propagation problem across replicas, caches, exports, and backups.

The rule

On a valid request you must delete personal data "without undue delay" — every copy, in every store you control. A tombstone in the auth table while rows persist elsewhere is not erasure.

What it means for how you build

Deletion has to be a cascade with a defined blast radius: user-owned artifacts destroyed, shared tenant data left intact, and the operation idempotent so retries are safe.

Self-check

Does a single request cascade to every store, replica, cache, and search index holding the subject’s data?
Are backups covered — via rotation expiry or crypto-shredding of per-user keys?
Can retries of the same request run safely (idempotent) without resurrecting data?
Do you emit a completion artifact — a record that erasure happened, without keeping the erased data?

Common pitfalls

Soft-delete flags: a tombstoned row still containing the data is not erasure — regulators treat it as a lie, not a shortcut.
Orphaned copies: deleting the primary while read-replicas, BI exports, and search indexes keep the records.
Reversible "anonymisation" — a salted hash of an email is still personal data while you hold the salt.

How the engine checks it

Destructive anonymization on UserDeleted — identifying fields overwritten, never reversibly hashed, across both sovereign partitions.

Sources

Related rules

Last reviewed 2026-11-01.