Consent as a legal basis: when does it work and when is it a trap?

Consent is the best-known legal basis in the GDPR and also the most overrated one. Many business owners think: I put a tick box on my form, the customer clicks it, and I am covered. In practice it often works the other way round. Consent is the only basis the customer can take away again at any moment. If they do, the ground disappears from under your processing and you have to stop. For an AI assistant handling email, WhatsApp or phone calls, that is a risk you built in yourself. This article explains when consent really is the right choice, when it is a trap, and what is expected of you if you use it anyway.

What does consent actually mean under the GDPR?

Start at the beginning. Article 6 GDPR says you may only process personal data if you can rely on at least one of six legal bases. Without a basis the processing is unlawful, however carefully you work otherwise. Consent is the first of them, named in Article 6(1)(a). The other five are: performance of a contract, a legal obligation, vital interests, a public task, and legitimate interests.

What consent is exactly is set out in Article 4(11) GDPR. It has to be a freely given, specific, informed and unambiguous indication of the person's wishes, by which they signify agreement through a statement or a clear affirmative action. Those four words are not atmosphere. They are four separate requirements, and if one is missing the consent is invalid. Invalid consent is legally the same as no consent at all: you are left with nothing, even if you have thousands of ticks sitting in your database.

A fifth requirement follows from Article 7 GDPR. You must be able to demonstrate that someone gave consent, and you must make withdrawing it as easy as giving it. Consent is therefore not a single moment but a file you keep maintaining.

Which requirements apply, and what goes wrong if you miss them?

It helps to put the requirements next to their consequences. Not because every mistake immediately becomes an enforcement case, but because it shows you where your own process leaks.

The requirements for valid consent under the GDPR, what each one means in practice, and what goes wrong if you do not meet it.

Requirement	What it means	What goes wrong
Freely given	The customer can say no without it costing them anything. Your service stays available without consent too.	Tie delivery to the tick box and the consent is not free, so it is invalid. You are then processing with no basis at all.
Specific	One request per purpose. Answering customer questions and later sending a newsletter are two purposes, so two questions.	A single tick for everything collapses as soon as someone challenges it. Even the purposes that were fine on their own lose their basis.
Informed	Clear in advance who you are, what you will do, what the purpose is, and that withdrawal is possible.	Consent based on an unclear or unfindable text does not count. On top of that you breach the information duty in Article 13 GDPR.
Unambiguous	An affirmative action: ticking the box yourself, pressing a button yourself, replying yourself.	Silence, clicking through or a pre-ticked box produce no consent. You think you have consent and you do not.
Demonstrable	For each person you can show when consent was given, for what, and with which wording alongside it.	Without records you can prove nothing. In complaints about marketing messages the burden of proof sits with you as the sender, not with the customer.
Withdrawable	Withdrawing is as easy as giving, and it works through in every one of your systems.	A difficult opt-out route makes the original consent invalid. Everything you do afterwards, you do without a basis.

Why a pre-ticked box is never valid

This is the mistake that sits in existing forms and chat flows most often. A box that is already on, a pop-up where only "agree" is a button, or a line saying "by continuing you agree to our terms". The Dutch data protection authority is short about it: you may not assume that someone gives consent implicitly, and pre-ticked boxes are not permitted.

The reason is the "unambiguous" requirement. There has to be an action that can only be read as a yes. Scrolling on is not a yes. Continuing to use a service is not a yes. Not replying is certainly not a yes. Translate that to your own channels: if your chat window carries a small grey line at the bottom saying "by chatting you agree to the processing of your data", you have not collected consent. You have placed a text.

The same goes for the inverted construction: a box the customer has to untick to get out of something. That is a pre-ticked box with extra steps. And it goes for bulk imports: contacts you picked up somewhere years ago do not suddenly have consent because your new system happens to have an "opt-in" column.

When is consent genuinely freely given?

"Freely given" is the requirement that quietly fails most often in smaller businesses. Consent is not free if saying no is not a realistic option. Three situations keep coming back.

The first is bundling with the service. You ask consent for marketing, but anyone who does not tick cannot complete their order. That is not a choice, it is a toll. The second is bundling of purposes. You put five different purposes behind one box, from order handling to profiling. Someone who only wants their order has to accept everything they do not want as well. The third is an unequal relationship. With your own staff, consent is almost never free, because an employee who says no to their employer feels that as a risk. For monitoring employees, consent is therefore nearly always the wrong basis.

A good test: ask yourself what happens if someone says no. If the answer is "then it does not go ahead" or "then I will call them anyway", you are not asking for consent. You are asking for a signature under something you were going to do regardless.

Why consent is usually the worst choice for ordinary customer contact

This is the heart of the matter. Many owners put consent under everything because it feels safest. The opposite is true. The regulator itself advises against it: if you want a stable basis for your processing, you are better off not basing it on consent but on one of the other grounds, and for a business owner that is usually performance of a contract.

Think about what actually happens in ordinary customer contact. A customer messages: "where is my order?" To answer that you need their name, order number and phone number. That is not something you need to ask permission for. It is necessary to perform the contract they entered into themselves. An AI assistant handling that changes nothing: the question is what happens to the data and why, not whether a human or a system replies.

In that situation consent has three drawbacks. First, it is unstable: the customer can withdraw, and then you may no longer handle the order you are contractually obliged to handle. Second, it is a fake choice: you are going to answer the question anyway, even without a tick, so the consent was never free. Third, it creates administration you never needed: recording per person, storing it, processing withdrawals.

The rule to take away: use consent only where you offer a real choice and where you will actually accept that choice. For everything that simply belongs to the service, performance of the contract is the more honest and sturdier basis. And because every processing activity with its own purpose also needs its own basis, you can happily mix within one channel: handling an order question on the contract, and sending a newsletter on consent.

When do you actually need consent?

There are situations where consent is not just allowed but required. No other basis gets you out of those.

The most important one for smaller businesses is marketing by email, WhatsApp or other electronic messages. That falls under Article 11.7 of the Dutch Telecommunications Act, the anti-spam rule. The Dutch consumer and markets authority sums it up in three lines: only send your messages to people who gave consent in advance, make clear that you are the sender, and make unsubscribing easy. Note that this sits separately from your GDPR basis. You can have a perfectly good legitimate interest and still be in breach of the anti-spam rule.

There is one exception that matters most to the average business: you may send existing customers unsolicited messages about products or services related to their earlier purchases. They must be able to unsubscribe, and you must clearly be the sender. That exception is narrower than it looks. "Existing customer" is not the same as "someone who once asked for a quote", and "related" is not the same as "anything we happen to sell".

Beyond that: placing non-functional cookies and similar techniques falls under Article 11.7a of the Telecommunications Act, which also touches the chat widget on your site if it stores more than strictly necessary. Telephone sales to consumers and to businesses without legal personality are likewise subject to a consent regime. And for special categories of data, such as health data, the prohibition in Article 9 GDPR applies, where explicit consent is one of the narrow ways out.

What happens when someone withdraws consent?

Article 7(3) GDPR governs this. Withdrawal is always allowed, and it must be as easy as giving. If someone could say yes with a single click in a chat, you may not demand a letter by post or a phone call during office hours for the no. You have to tell people in advance that withdrawal is possible.

What withdrawal does is this: from that moment on you may no longer process the data for that purpose. What you did before the withdrawal stays lawful; withdrawal does not work retroactively. You also may not quietly switch to a different basis for exactly the same purpose. If you asked for consent, you told the customer they were in charge of that processing. Sliding legitimate interests underneath it afterwards is not decent and will not hold.

In practice, withdrawal means three things. One: it has to work through in every system where the data sits, including conversation history, exports, mailing lists and any copies held by a supplier. Two: if no other basis remains for that data after withdrawal, the right to erasure in Article 17 GDPR comes into play. Three: data you have to keep for another reason, for instance because tax law requires it for your books, stays where it is. You then stop the use the consent was for, not the retention as such. Write that distinction down, otherwise "deletion" becomes a discussion instead of an action.

How does this work for customers under sixteen?

If you rely on consent, your customer's age suddenly becomes relevant. Article 5 of the Dutch GDPR Implementation Act provides that instead of the consent of the data subject, that of their legal representative is required if the data subject has not yet reached the age of sixteen. In plain terms: for anyone under sixteen the parent or guardian has to give consent, not the child.

That is harder for an online channel than it sounds. A chat window cannot see an age. An AI assistant replying on WhatsApp does not know who is typing. You are still the one who has to sort it out: you have to make reasonable efforts to establish that valid consent exists, measured against available technology and the risk of what you are doing.

Two practical conclusions follow. If young people are a real part of your audience, for instance in a webshop or a clinic with young clients, consent is an expensive basis: you will have to build something to catch age and parental consent. If young people are not your audience at all, consent is usually unnecessary anyway, because you will normally fall under performance of the contract. Either way the outcome is the same: do not lean on consent when you do not have to.

What do you have to be able to show if you do use consent?

Consent is only worth something if you can reconstruct it. Record for each person: when consent was given, through which channel, for which purpose, and with which wording alongside it. That last one is the forgotten column. If you change your form text a year later, you still have to be able to show what it said when this particular customer clicked.

Record withdrawals as well, with the date. Otherwise you cannot explain why someone still received a message after unsubscribing. In complaints about marketing that is the first thing asked, and the burden of proof is yours.

Finally: tell the customer which basis you are using. Article 13 GDPR obliges you, when collecting data, to state not just the purpose but the legal basis as well. Your privacy statement therefore has to make clear, per processing activity, whether it runs on consent, on the contract, or on legitimate interests. That forces the right exercise on you straight away: you can only write down which basis you use once you have genuinely made that choice.

Five rules of thumb to take with you

1. Do not ask consent for something you are going to do anyway. That is not consent, it is a tick box.
2. Split by purpose. Handling customer questions, sending marketing, and using conversations for improvement are three different things.
3. Make unsubscribing as easy as subscribing, in the same channel.
4. Log both consent and withdrawal, with date, purpose and the wording used.
5. Use consent where the law demands it, such as marketing by email or WhatsApp, and outside that prefer a basis that cannot evaporate.

This is reference material about what the law says, not legal advice about your specific situation. If you are unsure about the basis under a particular channel or a particular processing activity, put that choice to a lawyer before you go live.