After the Withdrawal Click: What Has to Stop, and Who Has to Hear About It
A visitor gave consent in March, used your site for months, and withdrew it on a Tuesday afternoon. Your banner did its job. It recorded the withdrawal, flipped the preference, and showed the right confirmation. Then nothing else happened. The analytics tag kept firing because the tag manager had cached the old state. The ad vendor kept the profile because nobody sent it the update. The record says consent ended at 2:14 pm. The data says otherwise.
That gap is where withdrawal cases are lost. The regulator does not ask whether the banner worked. It asks whether the processing stopped, who was told, and what the record shows. The EDPB guidelines on consent put the burden of proof on the controller, and Article 7(3) of the GDPR says withdrawal must be as easy as giving consent. Paragraph 114 of the guidelines makes the test concrete: one click in should mean one click out. The same standard applies after the click. Stopping has to be as reliable as starting was.
What has to stop
Withdrawal ends the legal basis for the processing it covered. If consent was the basis for analytics, analytics stops. If it was the basis for advertising, advertising stops. Anything that relied on another basis, like a contract or a genuine legitimate interest, can continue, but only the part that basis covers. The common failure is treating withdrawal as a preference change in one system while the rest of the stack keeps running on the old value.
Check the places consent actually flows. The tag manager is first, because it decides which tags fire. Then the analytics tool, which may have a server-side path that ignores the browser state. Then any vendor script loaded directly in the page, outside the tag manager. Then the mobile SDK, if the site has an app. A withdrawal that reaches the banner and the tag manager but not the directly loaded scripts is a withdrawal that did not happen in practice.
Timing matters too. There is no published grace period for stopping. The EDPB expects withdrawal to take effect without undue delay, and a vendor that keeps receiving data for days after a withdrawal has a record problem. Test it the way a visitor experiences it: withdraw, wait five minutes, and watch the network requests. If a consent-dependent request still fires, the pipeline has a hole.
Who has to hear about it
Consent is rarely a two-party matter. The vendors on your list received the original consent signal, and most of them are still holding the data it produced. Withdrawal has to propagate to them, and the propagation has to be visible. A consent management platform that updates its own record and sends nothing to the vendors has done half the job.
The practical test is the vendor list. Open the current list, pick the three vendors that receive the most data, and trace the withdrawal signal to each of them. The TCF consent string should update, and the vendor should receive the new string on its next request. If a vendor only reads the string on page load, a visitor who withdraws mid-session and keeps browsing will keep feeding that vendor until the next load. That is a real gap, and it is the kind of gap an audit finds.
Subprocessors count too. Your consent platform may pass the signal to a processor that passes it onward. Ask for the chain. If the platform cannot show you the propagation path, you cannot show it to a regulator either.
The record you keep
The withdrawal itself needs a record, and the record needs the same fields as the original consent: who, when, what was withdrawn, and the version of the banner and vendor list in force at the time. A log entry that says only that a preference changed is not enough. The regulator wants to see the before and the after, tied to the same visitor, with the vendor list version that applied.
Keep the record in the same place as the consent records, and keep it for the same retention period. Splitting withdrawals into a separate log that expires sooner is a quiet way to lose the evidence. When a visitor complains, the first thing you will be asked for is the full history of their choices. One file, one timeline, no gaps.
Keep reading: the one-click withdrawal test, the parity test for withdrawing consent, and what a vendor list change triggers cover the nearby cases in this series.
Frequently asked questions
How fast does processing have to stop after someone withdraws consent?
There is no fixed number of minutes in the law. The EDPB expects withdrawal to take effect without undue delay, and a regulator will look at whether your tags and vendors stopped in practice. Test it yourself: withdraw, wait five minutes, and watch the network requests. Any consent-dependent request still firing after that is a hole to fix.
Does withdrawing consent delete the data already collected?
No. Withdrawal stops future processing that relied on consent. Data collected while consent was valid stays lawful, and the visitor has a separate right to erasure if they want it deleted. Do not promise deletion as part of the withdrawal flow unless you can actually do it.
Do I have to tell my vendors when a visitor withdraws?
Yes, in practice. The vendors received the original consent signal and are still holding data from it. The withdrawal has to reach them, usually through an updated consent string, and you should be able to show the propagation path. A platform that updates only its own record has done half the job.
What should the withdrawal record contain?
The same fields as the original consent record: who, when, what was withdrawn, and the version of the banner and vendor list in force at the time. Keep it in the same place as the consent records, for the same retention period, so a complaint can be answered from one timeline with no gaps.