Chapter 46 — The right to erasure across a distributed system

In one sentence

"Delete this customer's data" sounds like one database row but actually means every replica, cache, search index, backup, warehouse extract, log line, event stream, and third-party processor — so erasure has to be an orchestrated, verified pipeline built on the data-flow map, not a single DELETE statement.

Where we are

Ch 41 mapped where data lives. Ch 42/44 gave you per-tenant/per-subject keys. This chapter is where those investments pay off: turning "please delete my data" into a bounded, provable operation instead of an open-ended search.

How it works

The legal shape (know the deadline and the exceptions):

   GDPR Art. 17 ("right to erasure" / "right to be forgotten") -- "without
     undue delay", generally operationalised as within the same ONE MONTH
     window as a DSAR response (Art. 12(3)), extendable by two further
     months for complex requests with notice to the subject.
   CCPA/CPRA -- a parallel deletion right for California residents, with
     its own service-provider-notification obligations.
   EXEMPTIONS (both regimes, similarly shaped) -- you may RETAIN data
     despite a deletion request where necessary for: compliance with a
     legal obligation (tax/financial records retention laws), establishing/
     exercising/defending legal claims, public-interest archiving/
     scientific/historical research/statistics (with safeguards), or
     freedom-of-expression contexts. Document WHICH exemption applies,
     PER RECORD RETAINED -- "we kept it because reasons" doesn't survive
     a regulator's questions.

Where the data actually is (the hard part is completeness, not any single deletion):

   PRIMARY DATABASE          straightforward: DELETE or a documented
     retention-then-purge job.
   READ REPLICAS             deletes propagate via normal replication --
     verify replication lag doesn't leave a stale readable copy
     indefinitely reachable by some path.
   CACHES (Redis, CDN)       must be explicitly invalidated/evicted; a
     forgotten cache entry can outlive the "deleted" primary record for
     its whole TTL. Short TTLs on anything containing RESTRICTED data
     reduce this window structurally.
   SEARCH INDICES            a delete-by-query against the index alias
     (Part 5 Ch 27's per-tenant indices make this cleanly scoped); watch
     for index snapshots/backups of the search cluster too.
   OBJECT STORAGE             delete the object AND any versioned/
     previous-version copies (S3 versioning keeps old versions unless you
     also delete/expire them) AND any CDN edge cache of it.
   BACKUPS AND SNAPSHOTS      the classic hard case -- backups are often
     IMMUTABLE by design (ransomware resilience, G1 Ch 51) for a
     retention window. Two honest approaches, not mutually exclusive:
       (a) CRYPTO-SHREDDING (Ch 44/Part 2 Ch 9): if the subject's/
           tenant's data was encrypted under a KEY SCOPED TO THEM,
           destroying that key renders every backup copy permanently
           unreadable WITHOUT touching the backup files at all -- the
           cleanest answer, but requires the key boundary to have been
           designed in from the start (per-tenant keys, or per-subject
           field keys for fine-grained erasure).
       (b) DOCUMENTED RETENTION-BOUND EXCEPTION: state plainly (in your
           privacy notice and your RoPA) that backups may retain deleted
           data for up to N days until they age out naturally, and that
           this is a deliberate, bounded, disclosed exception -- regulators
           broadly accept this IF it's short, documented, and the data is
           inaccessible in normal operation during that window.
   DATA WAREHOUSE / BI EXTRACTS   often a SEPARATE deletion job is needed
     because warehouse ETL runs on its own schedule; if you followed
     Ch 45 and only ever loaded de-identified/aggregated data here, there
     may be NOTHING identifiable to delete -- itself a reason to prefer
     that architecture.
   EVENT STREAMS / KAFKA           you generally can't delete one message
     from a topic. Options: short retention windows for topics carrying
     RESTRICTED fields (the data ages out on its own); COMPACTED topics
     with a TOMBSTONE record (a null-value message for that key causes
     the compactor to eventually remove it); or -- the robust answer --
     encrypt RESTRICTED fields in the event payload under a per-subject
     key (Ch 42) so crypto-shredding covers the event history too.
   LOGS / TRACES / APM             retention policy + scheduled purge;
     ideally RESTRICTED data was never logged in the first place (G1
     Ch 50's redaction-at-source) so there's nothing to chase here.
   THIRD-PARTY PROCESSORS / SUB-PROCESSORS   your Data Processing
     Agreements (Ch 47) must contractually obligate them to delete on
     your instruction and confirm completion -- your erasure pipeline
     calls THEIR deletion API (or sends a documented request) as one more
     step, not an afterthought.
   ML TRAINING DATA / TRAINED MODELS   an open, genuinely hard problem
     ("machine unlearning"). Practical mitigations rather than a full
     solution: avoid training directly on raw PII; if you must, tag
     training examples by subject so a future retrain can exclude them;
     periodic full retrains on a rolling dataset naturally age out
     removed subjects over time; document this limitation and timeline
     explicitly rather than claiming instant model-level erasure you
     can't deliver.
   SUPPORT TICKETS / EMAIL / CHAT LOGS / LLM PROMPT HISTORY   often
     forgotten because they live in a different tool entirely (Zendesk,
     Gmail, a support Slack channel, a prompt/context log for an AI
     feature) -- these must be in the data-flow map (Ch 41) and the
     erasure orchestrator's system list, or they will be the gap an
     auditor or a diligent customer finds.

The orchestrated pipeline:

   1. INTAKE      a DSAR/deletion request arrives (a form, an email, a
      support ticket) -> logged with a timestamp (starts the legal clock).
   2. VERIFY IDENTITY   don't delete someone's data because anyone typed
      their email address in a form -- verify via the account's own
      authenticated channel, or a documented identity-verification
      process for non-account requests.
   3. DISCOVER SCOPE   pull EVERY system for this subject from the DATA-
      FLOW MAP (Ch 41) -- this is precisely why that map must be complete
      and current; an erasure pipeline built on an incomplete map will
      confidently miss systems.
   4. CHECK EXEMPTIONS   for each system/record, is there a documented
      legal-retention exception? Flag and retain those, with the reason
      recorded.
   5. EXECUTE, per system: hard-delete, crypto-shred, or trigger the
      third-party's deletion API -- record a COMPLETION event per system
      (a "deletion certificate": system name, timestamp, method, verifier).
   6. VERIFY   spot-check (or, better, automatically re-query) that the
      data is actually gone/inaccessible from each system -- don't just
      trust that the delete call returned 200.
   7. RESPOND to the data subject within the legal window, with what was
      deleted and what was retained-and-why (the exemptions from step 4).
   8. AUDIT TRAIL   the whole pipeline's log (requests, verifications,
      completions) is itself retained (as a RECORD OF HAVING COMPLIED,
      which is a legitimate, narrow retention purpose) separately from the
      deleted data itself.

Worked example

Running an erasure request through SecureShop's real system list.

   Customer submits a verified deletion request via their account
   settings (step 1-2 satisfied by design -- they're authenticated).

   DISCOVERY (from the Ch 41 data-flow map, system by system):
     [ ] users table (primary Postgres, RLS-scoped, Part 5 Ch 27)
         -> HARD DELETE the row; cascades to owned records via FK.
     [ ] orders/invoices (contains a 7-year FINANCIAL-RECORDS-RETENTION
         legal exemption in most jurisdictions)
         -> RETAIN, flagged with exemption "tax/accounting record
            retention, jurisdiction X, 7 years from transaction date";
            but CRYPTO-SHRED the customer's PII FIELDS within those
            records if they were field-encrypted under a per-subject key
            (Ch 42) -- satisfies erasure of the PERSONAL data while
            preserving the required financial record shape (amounts,
            dates, tax IDs where legally required) which was never in
            that per-subject-encrypted field to begin with, BY DESIGN.
     [ ] Redis session/cache          -> explicit key eviction; short TTL
         means most would have expired anyway.
     [ ] OpenSearch (per-tenant index, Part 5 Ch 27)
         -> delete-by-query on the customer's documents.
     [ ] S3 exports/invoices bucket    -> delete objects + all versions;
         confirm CDN edge cache purge.
     [ ] Kafka `orders.events`         -> field-level encryption under a
         per-subject key means crypto-shredding that key handles this
         topic too, without touching the log itself.
     [ ] Analytics warehouse           -> nothing identifiable present
         (Ch 45's de-identification-at-ingest design) -- NOTHING TO DO,
         confirmed and logged as such.
     [ ] Support tool (Zendesk)        -> call its deletion API for the
         customer's tickets; DPA (Ch 47) obligates this.
     [ ] Backups (nightly encrypted snapshots)
         -> per Ch 44/Part 2 Ch 9, crypto-shredding this customer's
            per-subject key ALSO covers every backup that ever contained
            their field-encrypted data, retroactively and immediately,
            with NO need to touch the backup files.

   COMPLETION: 9 systems checked, each with a completion record;
   2 legitimately retained-with-exemption records noted; response sent to
   the customer within the legal window listing both. The whole run took
   minutes because the per-subject key boundary (designed in Ch 42/44) did
   most of the actual "deletion" work for anything append-only or
   immutable, and the data-flow map (Ch 41) meant nothing was missed.

Practice (75 min)

Using your Ch 41 data-flow map, list every system a real deletion request would need to touch. For each, decide: hard-delete, crypto-shred, an exemption, or "nothing identifiable present."
Build a minimal erasure orchestrator: given a subject ID, it calls a deletion function per registered system, records a completion event with timestamp and method, and produces a final report.
Implement crypto-shredding for real: encrypt a test record under a per-subject DEK (Ch 42), put copies of the ciphertext in three "systems" (a table, a file, a mock backup), destroy the wrapping key, and confirm all three are now unrecoverable without touching the copies themselves.
Write the two example exemption statements (financial-record retention, legal-claim defence) you'd actually use, and confirm they're mirrored in your privacy notice/RoPA (Ch 41).
Add a verification step: after "deleting," actually re-query each system for the subject and assert zero results, rather than trusting a 200 response.

Common mistakes

Deleting from the primary DB and calling it done. Caches, search indices, backups, warehouses, and third parties are usually the ones actually missed.
No identity verification before executing a deletion request. An attacker requesting someone else's deletion is a denial-of-service / sabotage vector.
Retaining data with no documented exemption. "We might need it someday" isn't a lawful basis; write down the specific legal ground, per record class.
Treating backups as an unsolvable problem. Crypto-shredding (if designed in) or a short, disclosed retention-bound exception both work; silence or "we can't do anything about backups" doesn't.
Building the pipeline without the data-flow map. It will be exactly as complete as your inventory — no more.
Never verifying completion. A deletion call that silently failed (a timeout, a permissions error) looks identical to success unless you check.
No plan for ML training data. Acknowledge the limitation explicitly rather than promising instant model-level erasure you can't actually deliver.

Check yourself

What starts the legal clock on a GDPR erasure request, and roughly how long do you have?
Give two legitimate exemptions that let you retain data despite a deletion request, and what you must document for each.
Why are backups the hardest part of erasure, and name two honest ways to handle them.
How does per-subject/per-tenant field encryption (Ch 42/44) simplify erasure across immutable or append-only stores?
List the eight steps of an orchestrated erasure pipeline.
Why is verifying deletion (re-querying) different from — and necessary in addition to — just calling the delete API?