Lawful basis, and when consent is the wrong choice
If you will carry on processing after someone says no, consent was never your basis and asking for it made things worse. Consent under GDPR must be freely given, specific, informed and unambiguous, and it must be as easy to withdraw as to give. A system that cannot stop when it is withdrawn has not met the standard, and it has now created a written record of asking permission it did not honour. There are five other bases and most processing belongs on one of them.
Why is consent the wrong default?
Because it transfers control to the individual, and most processing cannot actually be stopped on request. If a payment record, an audit log or a fraud check would continue regardless, consent is not the real basis and presenting it as one is misleading. Article 7 also requires withdrawal to be as easy as giving, which means a single action, and it must propagate to every downstream copy.
Consent is additionally unsound wherever there is an imbalance of power. In an employment relationship regulators treat consent as rarely valid, because a person who can be disadvantaged by refusing is not choosing freely. Public authorities face a comparable constraint from the other direction: legitimate interests is not available to them for processing in the performance of their tasks.
The engineering cost is the part usually missed. Real consent requires a record per purpose with a timestamp, the version of the notice shown, the granularity offered, and a query path that lets every pipeline filter on consent state at the time it runs. If your warehouse cannot exclude a person mid-pipeline, you cannot use consent for anything that pipeline touches.
Which basis fits which processing?
Article 6 offers six, and the choice is a matter of what is actually true rather than preference. Contract covers what is necessary to deliver the thing the person asked for. Legal obligation covers what a statute requires you to keep. Legitimate interests covers processing a reasonable person would expect and that passes a documented balancing test, and Recital 49 explicitly recognises network and information security as such an interest. Vital interests and public task are narrow. Consent is what remains.
The rows below pair each basis with the mechanism it forces you to build, because that is the part that decides whether the choice survives contact with the system.
| Basis | Right for | Wrong for | What you must build |
|---|---|---|---|
| Contract, Article 6(1)(b) | Delivering the service requested | Anything optional or additive | A clear line between core and optional features |
| Legal obligation, 6(1)(c) | Tax, accounting, statutory records | Anything you merely prefer to keep | Retention rules citing the specific obligation |
| Legitimate interests, 6(1)(f) | Security logging, fraud checks, service improvement | Public authority tasks, intrusive profiling | A written balancing assessment and an objection route |
| Consent, 6(1)(a) | Marketing, optional tracking, non-essential extras | Anything that continues after refusal | Per-purpose records and withdrawal that propagates |
| Vital interests, 6(1)(d) | Life threatening emergencies | Routine operations of any kind | An access break-glass route with recording |
| Explicit consent, Article 9(2)(a) | Health or other special category data | A substitute for a missing Article 6 basis | Separate opt-in plus stricter access controls |
So why do we still need a cookie banner?
Because storing or reading anything on a person's device is governed by separate rules, and they require consent almost regardless of your Article 6 basis. In the EU this comes from the ePrivacy Directive as implemented nationally, and the only general carve out is storage strictly necessary to provide a service the user requested: a session cookie for a logged in area qualifies, analytics does not.
The UK diverged on 5 February 2026. The Data (Use and Access) Act 2025 inserted a new Schedule A1 into PECR, commenced by the Data (Use and Access) Act 2025 (Commencement No. 6) Regulations 2026, which adds exceptions beyond strictly necessary. The one that matters here is statistical purposes: analytics used solely to collect statistical information about how the service is used, with a view to improving it, no longer needs PECR consent. The conditions are clear and comprehensive information about that use plus a simple, free way to object. There are also exceptions for adapting appearance or functionality to a user's preferences and for emergency assistance. The ICO set all of this out in its final Guidance on the use of storage and access technologies, published on 29 April 2026.
The limits of the UK exception decide whether it helps you. It covers your own statistics about your own service. It does not cover analytics data shared with third parties for their own purposes, and it does not cover anything feeding advertising or profiling, so a hosted analytics product that reuses the data, and every advertising tag, still needs consent. If you are serving both regimes from one deployment, the EU rule is the binding one unless you vary behaviour by jurisdiction.
This produces a distinction engineers find confusing and it is worth stating plainly: the processing that follows may rest on legitimate interests while the act of storing the identifier is governed separately and, unless an exception applies, needs consent. Both apply, and satisfying one does not satisfy the other.
The operational consequence is load order. If the tag fires before the choice is recorded, the consent is decorative, and this is the most common failure in real implementations. Test it by loading a page with a clean profile, refusing everything, and watching the network panel for requests to any third party. If any fire, the banner is a liability rather than a control.
What does legitimate interests actually require?
A written three part test, completed before processing, not a label. Identify the interest, show the processing is necessary to achieve it rather than merely useful, and weigh it against the individual's rights and reasonable expectations. The assessment is the artefact a regulator asks for, and its absence is what turns legitimate interests from a defensible choice into an assertion.
It is the right basis more often than teams expect. Security telemetry, abuse prevention, service reliability logging and most internal analytics fit it well, and it has the practical advantage that withdrawal is not a mechanism you owe. What you do owe is Article 21: a person can object, and you must stop unless you can show compelling grounds that override their interests. For direct marketing the objection is absolute and there is nothing to weigh.
The test that reveals a wrong choice: for each processing purpose, name the basis and then describe what stops if the person objects or withdraws. If the answer is nothing stops, the recorded basis and the real one differ.
Can you change basis later?
Practically, no. You cannot ask for consent, have it withdrawn, and then continue on legitimate interests for the same purpose, because that makes the original request meaningless and the individual was told something different. Regulators treat swapping basis after the fact as a transparency failure rather than a technicality.
This makes the initial choice more consequential than it looks in a design review. It is also why the safest approach is to decide the basis at the point the pipeline is designed and record it in the same repository, rather than reverse engineering it during a compliance exercise once several teams depend on the data.
Where you genuinely have a mixed purpose, separate the purposes instead of the bases. Core service processing on contract, security telemetry on legitimate interests, marketing on consent, with different retention and different access for each, is more work up front and the only version that stays true.
What should engineering ask before building a pipeline?
Four questions, answerable in a short conversation. What is the specific purpose, in one sentence, without the word improve. Which basis, and where is that recorded. What happens to this pipeline when a person withdraws or objects, expressed as a code path rather than an intention. And is any field in the payload special category data, because that adds an Article 9 condition on top of Article 6 and usually stricter handling.
The fourth question catches more problems than the others combined, because special category data arrives by accident. A free text health note in a support ticket, a dietary requirement in an events form, a trade union deduction in payroll data, or an inference about religion from a name field all pull processing into a stricter regime that nobody planned for.
Where a pipeline cannot answer the third question, treat that as a design defect rather than a compliance gap, and fix it in the architecture. A consent flag that nothing reads is worse than no flag, because it looks like a control to everyone who audits it.
Common questions
- Do you always need consent under GDPR?
- No, and consent is often the weakest option. Article 6 provides six lawful bases, and processing necessary to deliver a contracted service, to meet a legal obligation, or to pursue a documented legitimate interest does not require consent. Consent is appropriate for optional activity such as marketing and non-essential tracking. If you would continue processing after someone refused, consent was never the real basis.
- Why is consent invalid in an employment context?
- Because it must be freely given, and an employee who can be disadvantaged by refusing is not free to refuse. Regulators treat employer to employee consent as rarely valid for this reason. Most workplace processing should rest on contract, legal obligation or legitimate interests instead, with the balancing test written down. Genuinely optional schemes, such as a voluntary benefit, can still use consent if refusal carries no consequence.
- Does legitimate interests mean you can skip consent for cookies?
- No, and the answer now differs by jurisdiction. Storing or reading information on a person's device is governed by separate rules. In the EU the ePrivacy Directive as implemented nationally requires consent unless the storage is strictly necessary to provide the service requested, and analytics is not strictly necessary. In the UK, Schedule A1 to PECR, in force since 5 February 2026, exempts analytics used solely to collect statistics about how your service is used with a view to improving it, provided you give clear information and a simple, free way to object, and provided the data is not shared with third parties for their own purposes or used for advertising or profiling. Your lawful basis under GDPR for the subsequent processing remains a distinct question, and satisfying one does not satisfy the other.
- What does a legitimate interests assessment contain?
- Three parts, written before processing starts: the interest being pursued, why the processing is necessary rather than merely convenient for that purpose, and a balance against the individual's rights and reasonable expectations. It is the artefact regulators ask for. You also owe an objection route under Article 21, and for direct marketing an objection is absolute with nothing to weigh against it.
- Can you switch lawful basis after processing has started?
- Effectively not for the same purpose. Asking for consent, having it withdrawn and then continuing on legitimate interests contradicts what the individual was told, and regulators treat that as a transparency failure. The workable approach is to separate purposes rather than swap bases: core service processing under contract, security telemetry under legitimate interests, marketing under consent, each with its own retention and access rules.
