Consent is only valid if it is freely given, specific, informed and unambiguous. Freely given is the condition that fails most often, and it fails structurally rather than through bad drafting — it means the person had a genuine choice and no meaningful penalty for refusing. Where saying no costs them the service, or where they are in no position to refuse you, the consent is not merely weak. It is invalid, and the processing it supported has no basis.
This article covers what the condition requires, the conditionality test in Article 7(4), the imbalance and bundling problems Recital 43 identifies, where a B2B SaaS runs into all three, and what you have to be able to show later.
One Of Four Conditions, And The One That Breaks
Article 4(11) defines consent as a freely given, specific, informed and unambiguous indication of the data subject's wishes by a statement or clear affirmative action. All four have to hold.
The other three are largely solvable by design. Specific means separate agreement per purpose rather than a bundle. Informed means the person knew the controller's identity, the purposes and their rights. Unambiguous means a positive act — no pre-ticked boxes, no inferring agreement from silence or continued use.
Freely given is different because it is not about how the request is worded. It is about the relationship the request sits inside, and a company cannot fix an imbalance of power by improving its copy. That is why this condition tends to be the one that fails on facts nobody thought were part of the consent question at all. The broader mechanics of collecting, recording and managing consent — banners, granularity, records, withdrawal flows — are a subject in their own right; what follows is only the condition itself.
Article 7(4): Conditionality Is The Test
Article 7(4) supplies the operative rule. In assessing whether consent is freely given, utmost account is taken of whether the performance of a contract, including the provision of a service, is made conditional on consent to processing that is not necessary for the performance of that contract.
Read that carefully, because it is narrower and sharper than the paraphrases. It does not prohibit conditionality outright — it makes conditionality a heavily weighted factor against validity where the processing is not necessary for the service.
The test therefore folds back into necessity. If the processing is genuinely required to deliver what the person asked for, you probably should not be using consent at all; contract is the appropriate basis. If it is not required, then withholding the service from someone who declines is precisely the pattern Article 7(4) targets.
That produces an uncomfortable symmetry worth stating plainly: the processing you most want consent for is usually the processing that consent covers least well.
Recital 43: Imbalance And Bundling
Recital 43 names two situations directly.
Imbalance of power. Consent is presumed not to be freely given where there is a clear imbalance between the data subject and the controller. The recital names public authorities, and the reasoning applies with obvious force to employer and employee. An employee asked to consent is not positioned to refuse, which is why consent is the wrong basis for almost all workplace processing and why security monitoring and workplace surveillance run on legitimate interests instead.
Bundling. Consent is presumed not to be freely given where it does not allow separate consent to different processing operations despite it being appropriate in the individual case. One checkbox covering analytics, marketing and third-party sharing is a bundle, and separating them is the fix.
Both are presumptions rather than absolute prohibitions, which means they can in principle be displaced. In practice, displacing them requires facts most companies do not have.
Where A B2B SaaS Runs Into This
Three patterns recur, and all three are ordinary product decisions rather than compliance mistakes.
Conditioning a free tier on analytics consent. If the analytics is not necessary to deliver the free product, requiring consent as the price of entry is squarely within Article 7(4). The strength of your position depends on how genuinely optional the alternative is — and it is why whether product analytics needs consent is a harder question than it first appears.
Asking employees to consent. To monitoring, to photographs, to internal directories, to processing during onboarding. The imbalance presumption applies, and the correct response is usually to identify the real basis rather than to collect a signature.
Cookie walls. Blocking access unless a visitor accepts non-essential tracking is the same structure as the free-tier case, and supervisory authorities have treated it sceptically. A genuine, equivalent alternative changes the analysis; a nominal one does not.
A fourth situation is worth naming because it catches people out: consent from children below the applicable age is not valid at all, and that age varies by Member State rather than being a single European figure.
Proving It Later
Article 7(1) puts the burden on you: where processing is based on consent, the controller must be able to demonstrate that the data subject consented. Not that a consent flow existed — that this person consented, to this purpose, at this time.
That means a record carrying who, what they were shown, when, by what mechanism, and which version of the wording was on screen. A consent log without the version of the notice cannot demonstrate the consent was informed, because you cannot reconstruct what was said.
This is the same evidential problem that shows up in a completely different corner of the business, when a DPA is accepted by click-through and nobody records what was presented or who accepted it. Valid without a record and provable are different things, and only one of them survives being questioned.
Withdrawal completes the picture. Article 7(3) requires it to be as easy to withdraw as to give, and withdrawal has to reach the processing, not just a preference table.
Common Mistakes With Freely Given Consent
Making the service conditional on consent to processing it does not need. This is the specific pattern Article 7(4) singles out. If the processing were necessary, contract would be the right basis; if it is not, withholding the service is the problem.
Asking employees for consent. The imbalance presumption in Recital 43 means workplace consent is rarely valid. Collecting it anyway produces a document that looks like compliance and provides none, while obscuring what the real basis was.
Bundling purposes into one checkbox. Analytics, marketing and third-party sharing are different processing operations and need separate agreement. A single "I agree" is the textbook example the recital describes.
Treating continued use as agreement. Consent requires a clear affirmative action. Scrolling, browsing, or not objecting is not a statement of wishes, and a banner that says continued use implies agreement does not create consent.
Keeping the consent but not the context. Article 7(1) requires you to demonstrate consent was given. A timestamp without the wording, the version and the mechanism cannot show it was informed, which means it cannot show it was valid.
FAQ
Can we ever make a service conditional on consent?
Rarely, and only where the processing is genuinely necessary for the service — in which case contract is the better basis anyway. Article 7(4) does not ban conditionality outright, but it weighs heavily against validity, and the burden of showing consent was free despite it sits with you. Treat conditionality as a signal you have chosen the wrong basis.
Is consent from a business contact freely given more easily than from a consumer?
Not automatically. The condition is about the individual's freedom to refuse, not about the commercial context. A business context can affect reasonable expectations in a legitimate interests balancing test, but it does not relax the freely given requirement where consent is the basis you are relying on.
Does an incentive invalidate consent?
Not necessarily, but it depends on scale and framing. A modest benefit for opting into something optional is generally acceptable. An incentive large enough that refusing carries a real detriment starts to look like a penalty, which is the structure the condition is aimed at.
We collected consent years ago under a bundled checkbox. Is it still good?
Almost certainly not, if it was bundled. Consent that did not meet the conditions when given was never valid, and time does not cure it. The practical response is to identify whether another basis genuinely applies to that processing, and to re-collect properly where it does not.
Closing Thought
The reason freely given catches so many organisations is that it is the only consent condition you cannot fix at the interface. Specific, informed and unambiguous are all solved by better design — separate the purposes, say more, require a click. Freely given asks a question about the relationship rather than the request, and no amount of interface work changes whether an employee can say no to their employer or whether a visitor can decline without losing the thing they came for. That is why the honest response is usually not a better consent flow but a different lawful basis.
Which makes this a design decision that happens well before anyone writes the banner. ComplyDog provides a cookie consent banner alongside a compliance portal on your own domain with your DPA, subprocessor list, data subject request forms and security page. It does not decide whether consent is the right basis for a given purpose, or whether your free tier makes it conditional — those are product judgements, and they are the ones that determine whether the banner is doing anything at all.
