Ask a marketing team how they handle a deletion request and you will usually get a confident answer: the customer is removed from the email tool. Ask where else that person exists and the confidence goes. In a typical stack the answer is: the email tool, the CDP, the analytics warehouse, a reverse-ETL cache, three ad platforms' custom audiences, and whatever a data scientist exported to a notebook last quarter.
That gap — between "deleted from the tool" and "deleted" — is the single most common complaint about privacy tooling in the category, and it is not because vendors refuse. It is because no one vendor owns enough of the stack to answer the question.
A subject is a person, not a row
The first place an erasure goes wrong is scope. A customer data platform holds at least two records for most people: an anonymous visitor record created before they identified themselves, and a customer profile created when they did. They are linked, and they are separately identifiable.
Erase only the profile and the visitor record survives, still carrying the behaviour that was used to build the profile, still linkable to a new identification tomorrow. Erase only the visitor and the profile remains with the email address on it. So a request against either half has to reach both — and a profile with an unusually large number of linked visitor records should be refused outright rather than half-erased, because a partial erasure is worse than a rejected one.
Where the copies actually are
A real-time CDP is a fan-out architecture: the same person exists in several stores because each one answers a different question quickly. An honest erasure names all of them.
- The operational profile store, which is usually sharded — so the erasure runs on the node that owns each identifier, not once against a single database.
- The search indices that answer audience queries, deleted by query and then refreshed immediately, so the panel stops returning the subject in the same minute rather than at the next indexing cycle.
- Side state: saved cart contents, "seen since the last cycle" sets, device and subscription registries. These are the ones that get forgotten, and they are exactly the ones that would resurrect somebody.
- The consent ledger rows recording that person's decisions.
Everything above is inside the platform, which is what makes a single-pass erasure possible at all. Anything outside it — your warehouse, your bucket, an ad platform's audience — needs its own answer, and a privacy report that pretends otherwise is worse than one that says so plainly.
Three things a good erasure keeps on purpose
"Delete everything" sounds right and is wrong in three specific ways.
The suppression entry stays, hashed. If somebody unsubscribed and then asked to be erased, deleting their opt-out record silently re-enables messaging them the moment they appear again. That is the opposite of what they asked for. Keep the row, anonymise the address it holds, and the list still recognises them without storing them.
The audit trail stays. It is append-only, and it is the evidence of what the platform did — including this erasure. A system that deletes its own record of deleting cannot demonstrate compliance with the request it just fulfilled.
Your own archive is yours. If raw events are written to a bucket you own under a retention policy you set, the platform should say so rather than implying it reached in there. Ownership is the honest answer, and it is a better one than a vague claim.
The receipt is the deliverable
An API returning 200 proves that a request was accepted. It proves nothing about what happened afterwards, and asynchronous work is exactly where a partial failure hides.
So the artefact that matters is a signed receipt: which stores were touched, how many records each one reported, when the work finished, and a signature over all of it. Sign it with a secret the platform holds, and re-verify it every time the report is displayed rather than trusting a stored "verified" flag. A green tick that was never actually checked is worse than no tick at all, because it is believed.
One detail worth insisting on: the receipt must contain no personal data. A receipt carrying the erased email address defeats the erasure it certifies. An identifier and a hash are enough to tie it to the request.
Make failure loud
A partial erasure that quietly retries forever is the worst available outcome: it looks fine on a dashboard, and it produces no artefact anyone can act on. Mark it failed, record the reason, and surface it. Somebody being told "this erasure did not finish, here is why" can escalate. Nobody can escalate a silent retry loop.
The same instinct applies at the other end. Before each record is removed, write every consent purpose on it to denied. That looks pointless on a record about to disappear, and it is not: if the same person is seen again tomorrow, they start from no permission rather than from whatever a stale integration last asserted.
Consent is the half that prevents the request
Erasure is the remedy. Consent is the control, and it works best when it decides what is collected, not only what is sent.
Three properties make it defensible:
- Purposes are separate. Analytics, advertising, personalization, email, SMS and push are different lawful bases. One checkbox standing in for all six is not consent, it is a formality.
- "Never asked" is not "said no". Collapsing the two loses the ability to distinguish a person who declined from one who was never given the choice — and those need different treatment.
- Resolution is biased towards not processing. A newer decision wins; a withdrawal is never lifted by a grant arriving from a bulk import or an inference. Only a deliberate act can re-grant.
And the enforcement itself should be gradual. An enforcement setting that is off by default, with a pseudonymise mode between "off" and "drop", lets a team turn on the gate for one purpose and watch what happens — rather than discovering on a Monday that a strict setting silently stopped a third of their ingestion.
What to ask a vendor
- Name every store a deletion request reaches. Not "our systems" — the list.
- What is kept deliberately, and why?
- What artefact do I receive, and can it be verified after the fact?
- What happens when an erasure fails halfway?
- Can consent stop collection, or only stop sending?
- Are consent decisions per purpose, and is the evidence — source, timestamp, wording, notice version — retrievable?
See how consent, subject access and erasure are implemented on the Consent & Privacy page, or read the platform-level controls on the security page.