One click to accept, three menus to leave

Here's a test your banner has to pass. A visitor clicks "Accept all" and moves on. A week later they change their mind. How many steps does it take to withdraw? If the answer is "reopen a buried settings panel, scroll, uncheck several toggles, and confirm," while accepting took one tap, your banner fails Article 7(3) of the GDPR. The rule is short and specific: it must be as easy to withdraw consent as to give it.

Article 7(3) also says people have the right to withdraw at any time, that withdrawal doesn't unwind processing that was lawful before it happened, and that you have to tell people about the right before they consent. The "as easy" clause is the one that trips up real banners, because a lot of them are designed to make saying yes effortless and saying no a chore.

What "as easy" means for a cookie banner

The EDPB's Guidelines 05/2020 on consent put a sharp edge on it: withdrawal should be possible through the same kind of interface, without friction. If consent was gathered through the website, withdrawal happens through the website too, not by phoning a call center or emailing a privacy inbox. Their example is online ticketing: if you consented while buying a ticket online, you withdraw through the same online process.

Translated into cookie-banner terms, three things follow:

A persistent way back in. A floating button, a footer link, or a re-open trigger that's available on every page, rather than only at the first visit. If the only way to reach preferences is to clear cookies so the banner reappears, that's not "as easy."
Roughly symmetric effort. If "Accept all" is one click, withdrawing or rejecting should be reachable in a comparable number of steps.
No dark patterns on the exit. Confirmshaming, hidden reject buttons, and pre-selected "keep everything on" toggles all cut against the requirement. See dark patterns in cookie banners.

Three things a withdrawal has to actually do

Recording that someone withdrew isn't the same as acting on it. A compliant withdrawal does three things, and skipping the middle one is the failure regulators find most often.

Update the stored consent state, so the next page load reads "denied" for the categories the user turned off.
Stop the processing. The tags and scripts that were firing have to actually stop. This is where banners break: the withdrawal is written to a log, but the pixel keeps loading and the analytics keeps collecting because the tag-loading logic never rechecks consent.
Signal downstream where you can. For platforms that support it, propagate the change, for example updating Google Consent Mode to denied, so the vendor adjusts its own behavior rather than relying on your page alone.

Logging a withdrawal while the tag keeps firing is the classic failure

The most common consent-withdrawal defect isn't a missing button. It's a withdrawal that gets recorded but never enforced. The user turns marketing off, the database dutifully stores "marketing: denied," and the Meta Pixel keeps loading on the next page because the script-loading logic reads a stale value or never rechecks at all. From the user's point of view, and a regulator's, you ignored the request. Make your tag logic read the current consent state on every page load, and treat withdrawal as an event that must change what actually executes.

Withdrawal is not the same as erasure

These two rights get conflated, and the distinction matters. Withdrawing consent stops future processing based on that consent. It doesn't automatically delete the data you already collected. Deleting existing data is the separate right to erasure under Article 17. That said, the two connect: once consent is withdrawn and you have no other lawful basis to keep the data, erasure often follows, because you've lost your reason to hold it. Be clear in your own process about which request you're handling. See erasure requests for the deletion side.

Consent withdrawal readiness

A persistent re-open control on every page
Footer link or floating button, not a one-time first-visit banner.
Withdrawal in comparable steps to acceptance
If accept is one click, reject and withdraw should be similarly reachable.
Tags actually stop when consent is withdrawn
Read current consent on every page load, not a cached value from first visit.
Downstream signals updated
Propagate denied state to Consent Mode and similar vendor mechanisms.
Every withdrawal logged like a grant
Append-only records so the full consent history survives an audit.
Users told about the right before they consent
Article 7(3) requires the notice up front, not buried in a policy.

How CookieBeam meets the standard

CookieBeam keeps a persistent preferences control on the page so visitors can reopen their choices at any time and change them, which is the "as easy" requirement met in the interface rather than promised in a policy. Withdrawal is granular, so a visitor can turn off marketing while keeping analytics, and the change takes effect on the categories they touched.

Because the runtime rechecks consent and gates scripts on it, turning a category off stops the corresponding tags rather than only recording the intent, and where Consent Mode is in use the denied state propagates downstream. Every grant and every withdrawal is written to an append-only log with a timestamp, so your consent records show the full history if a regulator asks. If you also re-prompt visitors periodically, that's a related but separate discipline covered in consent expiry and re-consent. The mechanics of stopping scripts on withdrawal build on the same engine described in how to block scripts before consent.