Update: July 2026
Collecting consent is usually the easy part: one click on a banner or a form, and you have a lawful basis to process someone’s data. Handling the moment they withdraw consent is where most organisations’ processes actually get tested. GDPR sets a specific, strict standard for this, and getting it wrong is a compliance failure in its own right, separate from anything else about how the original consent was collected.
• Article 7(3) GDPR requires that withdrawing consent be exactly as easy as giving it, and your organisation has to build a withdrawal process that meets that standard, not just a request-handling process.
• Withdrawal stops future processing based on that consent, but it does not retroactively make processing you already carried out unlawful.
• A withdrawal request is legally distinct from an erasure request, and your organisation needs to be able to tell the two apart, since they trigger different obligations.
• Every channel you use to collect consent- a form, an account setting, a cookie banner- needs an equally accessible way to withdraw it, or the mechanism itself becomes the compliance gap.
• Article 5(2)’s accountability principle means your organisation needs to be able to demonstrate that a withdrawal was received and actioned, not just that it happened.
When a data subject withdraws consent, they are telling your organisation that a specific processing activity, tied to a specific consent they previously gave, should stop. That might be marketing emails, participation in a research study, or a non-essential cookie. Your organisation’s obligation is to stop that specific processing once the withdrawal is valid and received. In contrast, any other processing of that person’s data that relies on a different legal basis can continue unaffected.
Article 7(3) GDPR states that a data subject can withdraw consent at any time, and that doing so must be “as easy” as giving consent was. The EDPB’s Guidelines 05/2020 on consent make the practical implication explicit: if your organisation collects consent through one click on a website, the withdrawal process cannot require a phone call, a printed form, or logging into an account the person may no longer have access to.
This has direct design consequences. If consent is collected through a cookie banner, withdrawal needs to be available through an equally visible mechanism, not buried three menus deep in account settings. If consent is collected on a sign-up form, an unsubscribe link or a one-click toggle in a preference centre should do the same job in reverse. Building the withdrawal mechanism as an afterthought, once the consent-collection flow is already live, is how organisations end up with a process that technically exists but does not meet the Article 7(3) standard.
Not automatically. Withdrawal stops the processing that relied on that consent going forward, but it does not make earlier, consent-based processing unlawful retroactively. If your organisation sent three marketing emails before someone unsubscribed, those emails were lawfully sent under the consent that existed at the time. What changes is what happens next, not what already happened.
If the individual also wants the underlying data deleted, that is a separate right: erasure under Article 17, sometimes called the right to be forgotten. Withdrawal and erasure requests often arrive together, but your organisation needs to treat them as legally distinct actions with different conditions attached, rather than assuming one automatically covers the other.
A withdrawal request does not need to use specific legal language to be valid, but it does need to be recognisable as one. Requests can arrive through a reply to a marketing email, a message to a general support inbox, a form submission, or a verbal statement during a phone call. Staff handling customer communications need a clear process for recognising these requests and routing them to whoever manages consent records, rather than treating an unsubscribe request as routine correspondence that can sit unanswered.
Ambiguous requests are the harder case. A message asking a company to “stop contacting me” or “stop using my data” should generally be treated as a withdrawal covering at least the processing the person is most likely objecting to, with a follow-up to clarify scope where genuine ambiguity exists, rather than being ignored until the wording matches an internal template exactly.
Once a valid withdrawal request arrives, your organisation needs to stop the processing tied to that consent without unreasonable delay, update internal records to reflect the withdrawal, and notify any third parties the data was shared with, where that sharing depended on the same consent. Confirming receipt of the request back to the individual is good practice and, in most cases, expected, even though GDPR does not fix an exact confirmation deadline the way it does for subject access requests.
Organisations relying on multiple systems- a CRM, an email platform, an analytics tool- need a process that actually propagates the withdrawal across all of them. A withdrawal recorded in one system while a connected tool keeps processing the same data on the old consent is still a live compliance failure, regardless of whether it was intentional.
Confirmation does not need to be elaborate, but it should specify what was withdrawn and what will happen as a result. A short, direct message works better than a generic auto-reply, because it shows the request was actually processed rather than just received. Useful confirmation language covers three things: what processing has stopped, whether any other processing of the person’s data continues under a different basis, and who to contact if the person still receives communications after the change should have taken effect.
A workable template reads something like: “We’ve processed your request to withdraw consent for marketing emails. You will not receive further marketing communications from us. Your account and order history remain unaffected, since these are processed under our contract with you rather than consent. If you receive further marketing messages after today’s date, please let us know.” Adapting this to the specific consent being withdrawn, rather than sending a blanket “we’ve updated your preferences” message, reduces the follow-up queries your team has to handle later.
Where you shared the data with a processor or another controller based on that consent, yes, in practice you need to pass the withdrawal along. If a marketing platform, an analytics tool, or a partner organisation received data under a consent that has now been withdrawn, continuing to let them process it defeats the purpose of honouring the withdrawal in the first place. Your Data Processing Agreements with vendors should already specify how instructions like this get communicated and how quickly the vendor is expected to act on them.
This is where withdrawal requests most often fail in practice, not because an organisation refuses to act, but because the request gets actioned in the primary CRM and never propagates to the six other tools connected to it.
No, and treating them as interchangeable is a common source of mishandled requests. Withdrawal stops a specific processing activity that relied on consent. Erasure, under Article 17, is a request to delete the personal data itself, with its own conditions and exceptions, including cases where your organisation has to retain certain records for legal or accounting reasons regardless of what the individual wants. Someone can withdraw consent without requesting erasure, for example if they are happy for a company to keep their purchase history but want marketing emails to stop, so your intake process needs to capture which one is actually being requested.
At minimum, offer a channel that mirrors however consent was originally collected.
• Online preference centres or account settings: the option that handles the most volume without extra staff time, letting individuals toggle consent off directly without contacting anyone. This is the standard most regulators expect for any organisation collecting consent digitally at scale.
• Email and written requests: a functioning reply-to or unsubscribe link on every marketing communication, plus a documented process for handling requests that arrive through a general support inbox rather than a dedicated tool.
• Verbal and in-person requests: for organisations that still take phone calls or in-person interactions, staff need a defined process for logging these requests immediately, since a verbal withdrawal carries the same legal weight as a written one even though it leaves no paper trail unless someone records it.
Cookie consent needs its own equivalent: a persistent, easy-to-find way to change cookie choices, usually a link in the site footer or a “manage cookies” control, without requiring a separate request process at all. Our guide to cookie consent covers what a compliant setup for that specific channel looks like.
Article 5(2)’s accountability principle puts the burden on your organisation to demonstrate compliance, not just to comply. That means keeping a record of when a withdrawal request was received, what it covered, what action was taken and when, and confirmation that the request was communicated to any relevant third parties. This record serves two purposes: it protects your organisation if a regulator later asks how a specific request was handled, and it prevents someone re-adding a person to a marketing list months later because the withdrawal was actioned but never logged anywhere permanent.
Keep these records separate from the marketing or processing systems they relate to, so a withdrawal history survives even if the underlying platform changes.
Anyone who talks to customers, support, sales, or account management needs to recognise a withdrawal request when they see one, even an informal one, and know where to route it. The most common failure is not a badly designed withdrawal form; it is a support agent who reads “please stop emailing me” as a complaint to log rather than a legal request to action. Building this recognition into existing customer service training, rather than treating it as a separate compliance module nobody revisits, keeps it current as staff turn over.

The right to withdraw consent only means something if your organisation’s withdrawal process actually works the way consent collection did. Article 7(3) sets that standard directly, and it applies to every channel you use to collect consent, not just the ones that are easiest to update. Test your own withdrawal mechanisms the way a regulator eventually might: use them, and confirm that the processing genuinely stops, that the record gets kept, and that any connected third party finds out too.
No. GDPR does not allow an organisation to charge for processing a withdrawal or demand a justification from the individual. The right exists specifically so people can change their mind without penalty or explanation, and requiring either creates unnecessary friction that itself risks breaching Article 7(3).
Continuing to process data after a valid withdrawal, once your organisation has had a reasonable opportunity to act on it, becomes unlawful processing. This exposes the organisation to a complaint to the relevant data protection authority and, depending on scale and intent, potential enforcement action.
No, not unless that specific processing also relied on consent. Processing necessary to fulfil a contract, such as shipping an order, typically relies on a different legal basis and is unaffected by someone withdrawing consent for something separate, like marketing. Your organisation needs to know which legal basis underpins each processing activity to apply a withdrawal correctly.
There is no fixed statutory period specifically for withdrawal records. A reasonable approach is retaining them for as long as you would need to demonstrate compliance if challenged, which in practice often mirrors your general accountability record retention schedule rather than a separate rule of its own.
Disclaimer: This blog post is intended solely for informational purposes. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.
About the Author
Ana Mishova
Sales and Business Development Consultant — GDPRLocal
Ana focuses on helping organisations understand their compliance obligations and find the right data protection solutions. At GDPRLocal she works closely with businesses of all sizes, making GDPR and privacy compliance clear, practical, and accessible.