Withdrawal as easy as consent — and what happens after the click

What "as easy as consent" rules out

The comparison in §6(4) is between two journeys, not two buttons. If consent was one click on a banner and withdrawal is an email to a support address that a human reads within two working days, the journeys are not comparable and the wording of the clause does not leave much room to argue otherwise.

The same logic rules out a few things that are common in practice: making somebody create an account to withdraw when they did not need one to consent; asking for identity documents to withdraw an anonymous cookie decision; and burying withdrawal behind a preference centre that itself requires a login. Each of those adds friction on exactly the side of the transaction where the Act says friction may not be added.

When the code sends an OTP, and when it deliberately does not

This is the part that is usually got wrong in both directions. Verification is not applied uniformly; it is applied when it was applied at the other end.

A withdrawal is gated behind a one-time code where the original grant was itself verified — the consent request required a code, or a verified code exists against that email. Where the consent was an anonymous banner decision with no email attached, there is nothing to verify against and no code is sent; the person clicks and the record moves. Sending a code to an address you never collected is not security, it is an obstacle, and it is the obstacle §6(4) prohibits.

Where the gate does apply, the numbers are fixed and worth knowing: a six-digit code, valid ten minutes, five verification attempts before the attempt is refused, a thirty-second cooldown before a resend, and a verified session that lasts ten minutes and can be used once. Codes are stored as hashes; the raw value never lands in a table.

Per-purpose withdrawal, because bundled consent was never valid anyway

The withdrawal form lists the records that exist and lets the person choose. Submitting without a selection withdraws everything; selecting three of seven withdraws three. This matters because §6 requires consent to be specific to a purpose — and a withdrawal mechanism that can only operate on all-or-nothing has quietly reintroduced the bundling the capture side was careful to avoid.

There is a corollary that surprises people the first time they see it. The system resolves which records belong to the person before it acts, and it resolves broadly — seeding from the identifier given, then following the device handle, the browser fingerprint and the anonymous identifier attached to those records to find the others. The practical effect is that somebody who consented anonymously on the banner in March and later gave an email in a signup form withdraws both in one action, rather than withdrawing the one they remember and leaving the other running.

What actually changes in the record

The consent record's status and decision both move to withdrawn and a withdrawal timestamp is stamped. The record is not deleted. This is the distinction that makes an audit survivable: you need to be able to show both that consent existed and that it was withdrawn, and a system that removes the row can demonstrate neither.

The withdrawal token, if one was used, is marked consumed at the same time — single use, so a forwarded link cannot be replayed. The response is a redirect rather than a rendered page, so a back button cannot resubmit the form.

The downstream fan-out — this is the §6(6) half

A withdrawal creates a parent withdrawal record and one action per vendor that received data under the consent being withdrawn, routed by the rules configured for that purpose. Each action carries its own default deadline, and the defaults differ by what the vendor is being asked to do, because they are not the same job.

• Delete — thirty days. The vendor removes the data.
• Suppress — seven days. Add to a suppression list so the record survives but is not acted on.
• Stop processing — seven days. Halt the activity without touching stored data.
• Retain under a legal obligation — ninety days, and recorded as such, because "we had to keep it" is a position that has to be evidenced rather than asserted.

What fires alongside it

A webhook carrying the identifiers, the number of records updated, the number of downstream actions created and the source of the withdrawal — which distinguishes a token link from a self-service portal action from a retention-policy expiry, so you can tell in your own systems why something arrived.

A trace scan that looks for the person's data and raises an erasure review for the data protection officer, because §6(6) is an obligation to cease processing rather than an obligation to update a flag.

A confirmation email to the person, stating how many consents moved and how many downstream notifications were queued. It is an email rather than a PDF on this path; a signed receipt is available separately.

Where withdrawal breaks in real deployments

Three failure modes, all of them operational rather than technical. The first is a withdrawal route that exists but is not linked from anywhere a person would look — present in the preference centre, absent from the notice and the marketing emails. The second is a vendor with no routing rule, which means the withdrawal is recorded and no action is created for it, and nobody notices until an audit asks who was told.

The third is the one that costs money: consent captured through a form you built yourself, posted straight into your own database, never registered as a consent record. There is nothing to withdraw because there is nothing that knows it exists. If you take one thing from this page, make it that — the withdrawal machinery can only reach records the system has.