Cookie Consent: What the Law Actually Requires

Cookie consent is one of the most misunderstood requirements in digital privacy. Many businesses believe they are compliant because they show a cookie banner. But a banner is not consent. Consent is a specific legal concept with precise requirements — and failing to meet those requirements can mean your entire data collection is unlawful.

The Legal Foundation

Cookie consent sits on two legal pillars:

ePrivacy Directive Article 5(3) establishes the requirement: storing or accessing information on a user's device requires the user's consent, unless the storage is strictly necessary for a service the user has explicitly requested. This is the rule that specifically governs cookies.

GDPR Article 4(11) defines what consent means: "'consent' of the data subject means any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her."

These two provisions work together. The ePrivacy Directive tells you when consent is needed (for non-essential cookies). The GDPR tells you what valid consent looks like. Both must be satisfied.

The Five Requirements of Valid Consent

Drawing from GDPR Article 4(11), Article 7, and the EDPB's Guidelines 05/2020 on consent, valid cookie consent must meet five criteria:

1. Freely Given

The user must have a genuine choice. Consent is not free if:

• Access is conditional on consent. If the user cannot use the website without accepting all cookies (a "cookie wall"), consent is not freely given. The EDPB has confirmed this position, though some national DPAs allow limited cookie walls under specific circumstances — particularly if a genuine alternative exists (such as a paid, cookie-free version).
• There is a significant imbalance of power. In employer-employee or government-citizen relationships, consent may not be truly free. For most websites, this is less relevant, but it matters for government services and intranet platforms.
• Refusing is significantly harder than accepting. If "Accept All" is a prominent button and "Reject All" requires navigating through settings, consent is not freely given. The Italian Garante and the French CNIL have both issued specific guidance requiring that rejecting cookies be as easy as accepting them.

2. Specific

Consent must be given for each distinct purpose separately. This is why cookie categories exist. A valid consent mechanism must allow users to accept analytics cookies while rejecting marketing cookies, or vice versa. Bundling all cookies into a single "accept" or "reject" does not meet the specificity requirement — though offering both "Accept All" and "Reject All" as shortcuts alongside per-category controls is acceptable.

3. Informed

Before giving consent, the user must be told:

• Who is setting the cookies (the website operator and any third parties)
• What each category of cookies does
• How long the cookies last
• How to withdraw consent

This information must be presented clearly and in plain language. A 5,000-word cookie policy buried behind three clicks does not make consent "informed" in any meaningful sense. The first layer of your consent mechanism should include enough information for the user to make an informed decision.

4. Unambiguous

Consent requires a clear affirmative action. The user must actively do something to indicate consent — clicking a button, checking a box, toggling a switch.

What does NOT constitute unambiguous consent:

• Pre-ticked checkboxes. The CJEU ruled definitively in Planet49 (Case C-673/17, October 2019) that pre-ticked boxes do not constitute valid consent. This applies to cookie consent settings where categories are checked by default.
• Continued browsing. "By continuing to use this site, you consent to cookies" is not valid consent. Simply scrolling or clicking a link is not an "unambiguous indication." Multiple DPAs have confirmed this, and the EDPB's guidelines are explicit on this point.
• Browser settings. Relying on the user's browser settings as a form of consent has been rejected by regulators. The website operator must obtain consent directly.
• Silence or inactivity. If the user ignores the banner and continues browsing, that is not consent. No cookies should be placed until the user has made an active choice.

5. Prior

While not listed as a separate element in GDPR Article 4(11), the ePrivacy Directive makes clear that consent must be obtained before cookies are placed. This is the requirement many websites still fail to meet. Scripts that fire on page load — setting analytics and marketing cookies before the user has even seen the consent banner — violate this fundamental requirement.

Technically, this means non-essential scripts must be blocked until consent is given. Simply showing a banner while cookies are already being set does not satisfy the prior consent requirement.

What Valid Consent Looks Like in Practice

A compliant cookie consent implementation:

1. Blocks all non-essential cookies before the user interacts with the consent mechanism.
2. Presents a clear first layer that explains the categories of cookies used, with options to accept or reject each category.
3. Offers "Accept All" and "Reject All" at the same level of prominence — same size, same visual weight, same number of clicks required.
4. Does not use dark patterns — no misleading button colors, no hidden reject options, no confusing language, no nudging toward acceptance.
5. Links to a detailed cookie policy that lists every cookie by name, purpose, duration, and provider.
6. Records the consent with a timestamp and the specific categories the user accepted or rejected.
7. Only fires the relevant scripts after consent is given for that specific category.

The Consent Lifecycle

Consent is not a one-time event. It has a lifecycle that your implementation must support:

Collection

First visit: show the consent mechanism, block non-essential cookies, wait for user action.

Storage

When consent is given, store the user's choice in a strictly necessary cookie (no consent needed for this cookie, as it is required to respect the user's privacy preferences). Also store a server-side record as proof of consent.

Application

On subsequent page loads, read the consent cookie and fire only the scripts that match the categories the user accepted. Do not show the banner again — respect the stored choice.

Withdrawal

GDPR Article 7(3) is explicit: "It shall be as easy to withdraw as to give consent." Your website must provide a persistent, easily accessible way for users to change their cookie preferences at any time. A common approach is a small icon or link in the footer that reopens the consent management interface.

Renewal

Consent does not last forever. The CNIL recommends renewing consent every 13 months. The EDPB has not set a specific duration but requires that consent remain valid and that the user's choice still reflects their actual wishes. Best practice is to re-prompt at least once a year or whenever your cookie usage changes significantly.

Changes

If you add new cookies, new third-party services, or new purposes, existing consent may no longer cover them. Users should be re-prompted to give (or withhold) consent for the new processing.

Consent Records and Proof

GDPR Article 7(1) states: "Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented." For cookie consent, this means you must maintain records of:

• When consent was given (timestamp)
• What the user consented to (which categories were accepted, which were rejected)
• How consent was collected (what the consent mechanism looked like at the time — a version identifier or screenshot)
• Who gave consent (usually an anonymized identifier, not the user's name)

If a regulator asks you to prove that a specific cookie was placed with valid consent, these records are your defense. Without them, you have no evidence that your consent mechanism works — and the burden of proof is on you, not the regulator.

Common Consent Failures

Based on enforcement actions across Europe, these are the most frequently penalized consent failures:

1. Cookies placed before consent. Analytics and marketing scripts firing on page load, before the user interacts with the banner.
2. No reject option on the first layer. Requiring users to click "Settings" or "Manage preferences" to reject cookies, while "Accept All" is immediately available.
3. Pre-checked categories. Consent toggle switches that default to "on" for analytics and marketing.
4. No way to withdraw consent. Once the banner is dismissed, there is no way for the user to change their choice.
5. Consent wall / cookie wall. Blocking access to content unless all cookies are accepted.
6. Misleading design. Using green for "Accept" and gray for "Reject," making the accept button larger, or using confusing language like "Continue without accepting" vs "Accept and continue."

Passiro scans your website's cookie consent implementation and checks for these common failures, helping you identify and fix compliance gaps before a regulator does.

Next: when exactly is consent required? The answer involves a few important nuances, including the strictly necessary exemption and the ongoing debate around first-party analytics.