Every use of personal data needs a reason
Under the GDPR you can't process someone's personal data just because it's convenient. You need a lawful basis, one of six specific reasons the regulation allows, chosen before you start and written down. Consent is the most talked-about of the six, but it's only one. Getting this right matters because cookies, in almost every non-essential case, lean on consent specifically, and if the consent isn't valid, the data you collected on it isn't lawfully held.
The six legal bases, in plain terms
Article 6(1) of the GDPR lists six lawful bases for processing personal data:
- Consent. The person has clearly agreed. They can say no, and they can take it back.
- Contract. You need the data to deliver something the person asked for, like shipping an order to their address.
- Legal obligation. A law requires you to process it, such as keeping invoices for tax.
- Vital interests. It's needed to protect someone's life. Rare outside emergencies and healthcare.
- Public task. You're carrying out an official function in the public interest. Mostly for public authorities.
- Legitimate interests. You have a genuine business reason that a reasonable person would expect and that doesn't override their rights. Flexible, but you have to weigh it and document the balance.
You pick one basis per processing activity. You can't hedge by claiming consent and legitimate interests for the same thing as a fallback.
Why cookies almost always need consent
Here's the part that trips people up. You might assume you could run analytics under "legitimate interests" and skip the banner. For the cookie itself, you generally can't, and the reason sits outside the GDPR. Article 5(3) of the ePrivacy Directive says storing or reading information on someone's device requires their consent unless it's strictly necessary to deliver the service they asked for. That's a consent-or-necessity rule with no legitimate-interests door. So placing a non-essential analytics or advertising cookie needs consent, full stop. Strictly necessary cookies (the ones that make the site work) are exempt and need no consent at all. The boundary between those categories is covered in cookie categories.
What makes consent valid under the GDPR
Freely given
A real choice, with no penalty for saying no. Access can't be conditional on agreeing to non-essential tracking.
Specific
Separate consent per purpose. Analytics and advertising are different choices, not one bundled 'accept'.
Informed
The person knows who's processing the data, for what, and that they can withdraw, before they agree.
Unambiguous
A clear affirmative action. A deliberate click, never a pre-ticked box, silence, or 'by continuing you agree'.
As easy to withdraw as to give
Article 7(3) requires withdrawal to be as simple as the original opt-in. Reject must sit beside accept.
The pre-ticked box problem
Article 4(11) defines consent as a "freely given, specific, informed and unambiguous" indication of a person's wishes, made by "a statement or by a clear affirmative action." Recital 32 spells out what fails that test: silence, pre-ticked boxes, and inactivity are not consent. The EU's top court confirmed this in the Planet49 ruling, striking down a pre-checked cookie consent box. If your banner treats "didn't object" as "agreed," it isn't collecting valid consent, and a banner that makes rejecting harder than accepting fails the "freely given" part.
What this means in practice
For cookies, valid consent comes down to a banner that blocks non-essential scripts until the visitor makes an active, granular, per-purpose choice, offers reject as prominently as accept, and keeps a record of what was agreed and when. That record is your proof if a regulator asks. CookieBeam is built around exactly that model: it gates scripts before consent, presents balanced choices per category, and logs each decision. To turn this into a checklist for your own site, use the GDPR cookie compliance checklist, and see what the GDPR is for the wider picture.
When consent is the wrong basis
Consent isn't automatically the best choice for every processing activity, and reaching for it by reflex causes problems. If you genuinely can't offer a real choice, because you need the data to deliver the service, then consent is the wrong basis and "contract" or "legitimate interests" fits better. Sending a physical order to a customer's address runs on contract, not consent; you can't ship without it, so pretending the customer could decline is dishonest. The rule of thumb: use consent when the person can realistically say no and you'll respect it. For cookies, that's usually the situation, one visitor accepting and another refusing both leave your site working, so consent is both required (by ePrivacy) and appropriate. For core service data, a different basis is often the honest answer.
The exemption and the higher bar
Two edges are worth knowing. On one side, strictly necessary cookies need no consent and no separate legal basis song and dance: they're the cookies without which the service the user asked for can't run, and both ePrivacy and the GDPR leave them alone. On the other side, some data needs more than ordinary consent. Article 9 treats special categories, health, ethnicity, sexual orientation, political or religious belief, biometrics, as sensitive, and processing them generally requires explicit consent, a higher bar than the standard version. If your cookies or forms touch that kind of data, plain consent isn't enough.