The Deletion Request That Left a Trace
A subject access and deletion request arrives for a customer. The team runs a profile deletion for the customer's identity. Two weeks later, an audit finds: (a) the customer still appears in a downstream data warehouse table that was populated by a destination connector, (b) the customer's email still exists in an exported audience file retained by the ad platform, and (c) a support ticket notes the customer's profile 'reappeared' after a nightly re-ingestion of CRM data. The team believes deletion is a single button. The CRM is the system of record and has not been updated to reflect the deletion request.
1. Explain each of the three findings and why a profile deletion alone did not satisfy the request.
Read the worked answer
A profile deletion removes the profile from the platform's profile store - it is not a system-wide erasure. Each finding has a distinct cause:
(a) Warehouse table - Data already exported to a destination (including a warehouse connector) lives in the destination's storage. Deleting the source profile does not reach back into downstream systems. Downstream erasure requires a separate action at the destination or a coordinated deletion workflow.
(b) Ad platform export file - Exported audience files are copies held by the destination. The platform cannot retract a file already delivered. The ad platform must honor the deletion through its own process, or the file must be managed under a retention/deletion agreement with that vendor.
(c) Profile reappeared - The CRM is the system of record and still contains the customer. The nightly re-ingestion recreated the profile. Deletion is futile while the source continues to supply the identity. The source must be updated (or the identity suppressed) or the profile will be rebuilt on every ingest cycle.
So the single-button model fails because deletion must propagate upstream (to sources) and downstream (to destinations), and the platform sits in the middle.
2. Design a deletion workflow that would actually satisfy the request, and name the controls you would add to prevent recurrence.
Read the worked answer
Workflow
- Intake & scope: log the request, identify all identities for the person (email, CRM ID, loyalty, etc.) via the identity graph so deletion covers every linked identity, not just one.
- Upstream: update the CRM (system of record) to mark the record deleted/suppressed, and/or add the identity to a suppression list that ingestion honors, so re-ingestion cannot recreate the profile.
- Platform: run profile deletion across all linked identities; confirm dataset-level deletion for records that must be purged, not just the profile.
- Downstream: issue deletion requests to every destination that received the data - warehouse, ad platforms, email - and obtain confirmation. For ad platforms, use their deletion API or a contractual deletion process; do not rely on retention expiry alone.
- Verification: query the profile store, datasets, and each destination to confirm absence; record evidence for the audit.
- Closure: document completion with timestamps per system.
Preventive controls
- A suppression list checked at ingestion so deleted identities are not recreated.
- A destination inventory so every downstream copy is known and reachable for deletion.
- Retention limits on exported files to bound exposure.
- A deletion runbook with SLAs and an audit log, since the request has a legal deadline.
- Periodic reconciliation to catch reappearances (like the nightly CRM re-ingest) automatically.