Carry the deletion request from the source system to every downstream destination holding the customer's data, including active campaigns, queued sends, and cleanroom audiences
A customer's right to be forgotten is straightforward in the source-of-truth database (delete the row, set a tombstone, close the loop) and brutal everywhere else in the stack. The same customer's data lives in the email platform, in the ad-platform custom audiences, in the cleanroom shares with media partners, in the warehouse copies that the analytics team works against, in the backups, in the queued campaigns that have not sent yet, and in the third-party enrichment results that flowed back days or weeks ago. A deletion that lands in one place and does not propagate to the others is not compliance; it is the appearance of compliance with most of the data still in circulation.
The hard parts are not the obvious destinations. The email platform's data is easy enough to delete through its API. The hard parts are the queued sends that will fire before the deletion reaches the platform, the audiences shared into cleanrooms whose membership is opaque from the source side, the warehouse export that landed in a marketing team's spreadsheet, and the backups that retain the data by design. Each of these is a gap a regulator will eventually find, and each requires the propagation to either reach it or to document why it cannot.
This recipe builds the deletion propagation as a system: a complete destination inventory, a propagation pipeline that drives the deletion through it, and the audit trail that proves it happened on time.
A right-to-be-forgotten request that reaches every downstream destination holding the customer's data within the regulatory window, with the receipt trail that proves it. The metric is the completion rate against the required window (thirty days under GDPR, with shorter targets where the organization commits to them), measured as the percentage of RTBF requests fully propagated across the destination inventory within deadline. The value shows up in the regulator-facing posture (a documented system rather than a scramble) and in the operational side-effect that the destination inventory becomes valuable for unrelated purposes: anything that needs to know where customer data lives now has the answer.
The second outcome is the rejection path for requests that cannot be fully honoured (backups that retain the data through a defined window, partner systems whose deletion timeline is contractually longer), recorded explicitly so the rejection is defensible and the customer is told the truth.
A propagation pipeline that drives the deletion from the source-of-truth system through the destination inventory, recording receipts and surfacing failures. Composable stacks suit this because the destination inventory becomes a first-class artefact rather than tribal knowledge, and the propagation pipeline can be run, retried, and audited. The capability that decides whether the recipe holds up under regulator review is the completeness of the inventory: a propagation that reaches every destination the team can name but misses the three the team forgot is the propagation a regulator will find the gap in, and the inventory has to be maintained as a deliverable rather than as a side-effect of someone remembering.
Compare the tools on Martech Stack Builder
Legal owns the deletion definition (what counts as deletion versus anonymization, what backups and exceptions are defensible, what the customer-facing disclosure says), the verification standard, and the regulator-facing posture when a request is challenged. Data engineering owns the propagation pipeline, the destination inventory, and the receipts that prove the propagation happened. Marketing ops owns the campaign-side: suppression in active and queued sends so the customer does not receive a message after the deletion request, and removal from cleanroom shares so partner systems honour the deletion through the contractual mechanism. Infrastructure handles the backup and archive deletion windows, which are the destinations most teams under-account for and regulators ask about. The recipe takes months because the destination inventory takes months. The propagation pipeline is mechanical; finding every destination, including the ones built by teams that have since moved on, is the work that takes the time. A team that ships the pipeline before completing the inventory ships a propagation that misses the destinations the inventory does not list.
Work in this order. The inventory decides what the deletion can reach, and the receipts prove it did.
Right-to-be-forgotten propagation covers steps 1, 5, 6 and 8, consent state propagation across systems step 2, suppression and exclusion logic step 4, and audit trail generation at the decision point steps 3 and 7.
The first failure is the inventory gap. A propagation that reaches the systems the team remembers and misses the ones it does not is the propagation that fails on the destinations a regulator finds first, because regulators look for the kind of system that is easy for organizations to forget (a marketing team's exported list, a partner share that ran for a quarter then stopped, a backup retained by a since-departed vendor). The inventory has to be a living document maintained against organizational change, and the propagation has to be testable against it, or the recipe protects against the destinations the team can name and not the ones that matter.
The second is the silent partial. A propagation that fails to reach one destination quietly, with no alert, lets the team report completion while the data persists. The receipt requirement is what surfaces the partial, because every destination either confirms the deletion within the window or escalates as a failure. A propagation pipeline that does not collect receipts is a pipeline that cannot prove it ran.
The third is the queued send the propagation did not catch. A campaign queued the morning before the RTBF request arrives, scheduled to fire the next morning, sends to a customer who asked to be forgotten the day before because the queue was a snapshot taken before the deletion propagated. The suppression layer is what catches this: a send-time check against the deletion status, run on top of the audience-build-time check, because the audience built two hours ago does not know about the request that arrived an hour ago.
The Workshop works out with your team which of these matter for your stack right now, and what to do first: a 90-minute session with the people who own the decision.
The destination inventory that says where customer data actually lives, the propagation pipeline that drives the deletion through it, the receipts that prove it happened, the send-time suppression that catches the queued campaign, and the documented rejection path for what cannot be deleted: those are the decisions that turn RTBF from a regulatory exposure into a system the team can defend under audit.
Did this recipe match your situation?Anonymous response. Sign up to leave a longer note tied to your account.
Audit the personalization models for systematic bias in who they exclude, accelerate, or under-serve, so the model's behavior is defensible per protected category and per business-sensitive segment
Record why a particular customer saw a particular experience, in a form a regulator, an internal model reviewer, or the customer themselves can reconstruct months later
Give the customer real control over what they receive on which channel, propagate the choice to every system that sends, and respect the jurisdictional defaults that say what each silence means