GDPR Cookie Consent & ePrivacy Guide (2025): Valid Consent, Strictly Necessary Exemption, Google Analytics, IAB TCF, and PECR
Cookie consent is governed by the ePrivacy Directive (PECR in the UK) as the threshold question and GDPR as the personal data processing framework — both apply. The CJEU Planet49 decision (2019) established that pre-ticked boxes and "browsing as consent" do not satisfy the GDPR consent standard. Most cookie banners in production today — even after 7 years of GDPR enforcement — still contain consent defects: dark patterns, absence of a one-click reject, operator-set analytics pre-enabled, or withdrawal mechanisms that require more steps than consent did.
Cookie Categories: Consent Requirements Under GDPR/ePrivacy
| Cookie Category | Examples | Consent Required? | GDPR Legal Basis | Key Note |
|---|---|---|---|---|
| Strictly Necessary | Session ID, CSRF token, load balancer, consent preference record | No (PECR exempt) | N/A (no personal data processing beyond session) | Must still be disclosed in cookie policy |
| Functional/Preferences | Language preference (user-set), accessibility settings, user-chosen theme | No (user-explicitly-requested) | N/A if user-requested; legitimate interests if operator-set | Operator-set preferences are NOT exempt |
| Analytics (cookie-based) | Google Analytics (GA4), Mixpanel, Amplitude with device cookies | Yes under ePrivacy | Consent (Art. 6(1)(a)) | Most common compliance failure — requires prior consent |
| Analytics (cookieless) | Plausible, Fathom, server-side Matomo (no device storage) | Contested — likely no ePrivacy consent | Legitimate interests (Art. 6(1)(f)) | Requires LIA; some DPAs still require notice |
| Marketing/Advertising | Google Ads, Meta Pixel, The Trade Desk, RTB cookies | Yes under ePrivacy + GDPR | Consent (Art. 6(1)(a)) | Cannot be based on legitimate interests for behavioral advertising |
| Social Media | Facebook Like button, Twitter/X Share (third-party) | Yes (set on page load before user interaction) | Consent | Social share widgets set cookies before user clicks — require consent at page load |
| A/B Testing / Optimization | Optimizely, VWO, Google Optimize variants | Yes (operator-initiated, not user-requested) | Consent or legitimate interests (fact-specific) | Not strictly necessary — user did not request A/B testing |
Contract Risk — $97
Scan Your Privacy Policy or Cookie Policy for GDPR Compliance Gaps
Upload your privacy policy, cookie policy, or data processing agreement. BizLegal AI reviews whether your cookie disclosure accurately describes each cookie category and its legal basis, checks whether your consent mechanism descriptions align with GDPR consent conditions, flags missing disclosures for third-party cookies set by advertising or analytics partners, identifies whether your cookie policy treats analytics cookies as "strictly necessary" (a common error), and reviews international transfer disclosures for DPF, SCCs, and BCRS adequacy requirements.
Scan Your Privacy or Cookie Policy →Frequently Asked Questions
What law actually governs cookie consent in Europe — GDPR or the ePrivacy Directive (PECR) — and how do they interact?
This is one of the most persistently misunderstood questions in European data privacy law, and the confusion leads to fundamental compliance errors. The short answer: the ePrivacy Directive (implemented in the UK as PECR — Privacy and Electronic Communications Regulations 2003) governs cookie consent as a threshold matter. GDPR governs what happens with the personal data collected via cookies after that consent threshold is cleared. The two legal frameworks stack, not substitute. The ePrivacy Directive (Directive 2002/58/EC, amended by Directive 2009/136/EC) is the lex specialis for cookies and electronic communications — it governs whether you can set a cookie at all. Article 5(3) of the ePrivacy Directive requires informed consent before storing or accessing information on a user's terminal equipment (device). This applies to all cookies and tracking technologies — pixel tags, device fingerprinting, local storage, session storage, supercookies — not just traditional HTTP cookies. The EU ePrivacy Directive was supposed to be replaced by an ePrivacy Regulation, but that regulation has been stalled in EU legislative process since 2017 and is still not adopted as of 2026. In the meantime, the Directive and its national implementations remain in force. Each EU Member State has implemented the ePrivacy Directive into national law differently. The UK implemented it as PECR (effective since 2003, with 2011 amendments reflecting the 2009 Directive amendment). Germany uses the TTDSG (Telekommunikation-Telemedien-Datenschutz-Gesetz, in force December 2021) plus BDSG. France uses L.34-5 of the CPCE and CNIL regulations. The consent standard under ePrivacy was initially lower than GDPR consent — the original Directive referenced "opt-out" mechanisms. The 2009 amendment brought the standard closer to GDPR by requiring "prior consent." After the GDPR came into force in 2018, regulators and courts (including the CJEU in Planet49 — Case C-673/17, 2019) clarified that ePrivacy consent must meet the same high standard as GDPR consent: freely given, specific, informed, and unambiguous affirmative action. This means: (a) no pre-ticked boxes (Planet49 — the CJEU expressly held that pre-ticked checkbox consent is not valid consent under ePrivacy); (b) no "browsing as consent" (continued browsing does not constitute affirmative consent); (c) consent must be as easy to withdraw as to give; (d) consent cannot be bundled with acceptance of terms of service. GDPR then governs the personal data processing that occurs after cookie consent is obtained. If the cookie collects personal data (and most tracking cookies do, since they can be linked to an identifiable individual via device fingerprinting, login state, or cross-device tracking), GDPR applies to the storage and use of that data. The legal basis for processing personal data collected via cookies is typically Article 6(1)(a) consent — the same consent used for the cookie placement. It is also possible (though contested) to use legitimate interests under Article 6(1)(f) for certain analytics processing after the cookie placement consent is obtained under ePrivacy, but this is jurisdictionally inconsistent.
What cookies are exempt from consent requirements under the PECR "strictly necessary" exemption, and what does NOT qualify?
The PECR (and underlying ePrivacy Directive) create one critical exemption to the prior consent requirement in Regulation 6(4): cookies are exempt from consent where they are "strictly necessary for a service explicitly requested by the subscriber or user." This exemption is narrow and has been consistently interpreted narrowly by EU/UK data protection authorities. Cookies that DO qualify for the strictly necessary exemption: (1) Session authentication cookies: cookies that identify and maintain a logged-in session for a user who has actively authenticated (signed in). Without this cookie, the session breaks and the user is logged out after every page load. This is strictly necessary for providing the service. (2) Shopping cart cookies: cookies that remember items in a user's shopping cart for an e-commerce session. The user explicitly added items and the cart state is necessary to complete the requested transaction. (3) Security cookies: cookies set for security purposes — CSRF tokens (cross-site request forgery protection), load balancer cookies (to route a session to the correct server), fraud detection cookies (detecting bot vs human for the specific session). These are strictly necessary for operating the service securely. (4) Cookie consent record cookies: the cookie that records the user's own cookie consent preference — strictly necessary (the banner could not remember consent was given without it). (5) User preferences cookies: cookies that store non-tracking preferences explicitly requested by the user — e.g., language preference set explicitly by the user clicking a language selector, accessibility settings the user has explicitly toggled. (6) Load balancing: server-side session affinity cookies used to distribute load. What does NOT qualify for strictly necessary exemption — the most commonly miscategorized: (a) Analytics cookies (Google Analytics, Plausible, Fathom, Matomo, Mixpanel): these are NOT strictly necessary for providing the service. The user did not request "please monitor my behavior and report it to the operator." Even privacy-preserving analytics tools (Plausible, Fathom) that claim to be GDPR-compliant by default are still collecting data about the user's device/session and must have a legal basis. The legal basis for privacy-preserving analytics is frequently argued to be legitimate interests under GDPR (not ePrivacy consent), but this is an evolving area — CNIL guidance and Austrian DSB decisions have taken different positions. (b) Preference/personalization cookies (that are operator-selected, not user-selected): if the operator decides to remember the user's browsing history to customize content, that is NOT strictly necessary. The user did not explicitly request personalization. (c) Affiliate tracking cookies: cookies that attribute a conversion to an affiliate partner. Not necessary for the service itself. (d) Social media sharing buttons: Facebook Like, Twitter/X Share, LinkedIn Share buttons set third-party cookies as soon as the page loads (before the user clicks the share button). These are NOT strictly necessary. (e) Third-party advertising ID cookies (ANID, NID, IDE, uid, etc.): advertising and cross-site tracking cookies. Not necessary for the service. (f) A/B testing cookies: cookies used by the operator to run A/B tests — not requested by the user. The proportionality test: even within "strictly necessary," the cookie must be proportionate — only the data necessary to achieve the strictly necessary purpose should be collected. A session cookie with a long TTL (persistent across sessions when the user logged out) does not qualify for strictly necessary because the persistence is not necessary.
What are the exact GDPR consent requirements for a cookie banner to be legally valid, and what makes a banner invalid under CJEU and DPA enforcement?
The GDPR consent standard (Article 7 + Recital 32 + Recital 42) plus Planet49 (CJEU 2019) plus Orange Romania (CJEU 2020) plus multiple DPA enforcement decisions collectively establish a high and specific bar for valid cookie consent. Valid consent under GDPR must meet all 5 conditions simultaneously: Condition 1 — Freely given: consent is not freely given if it is conditioned on accessing a service, if refusing consent carries a meaningful penalty, or if there is an imbalance of power between the controller and the data subject. This means: (a) "Consent walls" (requiring cookie consent to access content, with no alternative) — the status of consent walls is contested. The German DSK and Austrian DSB have held that cookie walls violate the freely given requirement unless there is a genuine, equivalent alternative (like a paid version). The Dutch AP has taken a more nuanced position. Spanish AEPD Circular 1/2022 permits cookie walls under conditions. The EDPB Guidelines 05/2020 on consent state that consent is not freely given if the data subject "has no real choice." (b) "Cookie paywalls" (pay for no-tracking) — offering a paid subscription as an alternative to cookie consent has been addressed by the EDPB in Opinion 08/2024 on "Consent or Pay" models. The EDPB found these models must be assessed carefully — the fee must not be "disproportionate" to data protection being valued as a luxury. Major platforms (Meta, YouTube) have faced scrutiny under this model. (c) "Take it or leave it" where the service has no alternatives may impair freely given consent, especially for dominant platforms. Condition 2 — Specific: consent must be granular and specific to each purpose and each category of controller/third party. "I consent to cookies" is not specific. "I consent to [Controller X] placing analytics cookies for audience measurement" is more specific. Under the IAB TCF, each purpose and each vendor must be specifically consented to (though bundling all marketing purposes into a single toggle is still common and contested). Condition 3 — Informed: the user must know what they are consenting to before giving consent. The information must include: who the controller(s) are, what types of cookies are set, what purposes each cookie serves, what data is collected, and data subject rights. This information must be accessible before consent is given — not buried behind a "more information" link that most users do not open. Condition 4 — Unambiguous indication of agreement (Recital 32): consent must be given by a "clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject's agreement." This means: (a) No pre-ticked boxes — Planet49 expressly confirmed this (the "Sports Betting" lottery case where pre-ticked boxes for marketing partners were found non-compliant); (b) No "by continuing to browse" consent mechanisms — scrolling, swiping, or continued navigation does not constitute unambiguous affirmative agreement; (c) Cookie banners with only an "Accept" button and no "Reject" or "Manage" button make refusal harder than acceptance — multiple DPA enforcement actions confirm that consent is not freely given when rejection requires more steps than acceptance. Condition 5 — Withdrawable as easily as given: Article 7(3) GDPR: "The data subject shall have the right to withdraw his or her consent at any time... It shall be as easy to withdraw consent as to give it." A banner where accepting requires one click but withdrawing requires opening settings → finding the privacy section → unchecking → confirming withdrawal violates this requirement. Common banner patterns that have been found non-compliant: (a) Dark patterns — "Accept All" in prominent color, "Reject" buried in small gray text, or requiring multiple clicks to reject; (b) Reject button absent on first layer — users must click "Manage" to reject (Belgian APD has issued fines for this); (c) Bundled consent — single "Accept cookies" accepts all categories without granular options; (d) Default-on toggles — analytics or advertising categories pre-selected; (e) Nudge language — "Support our free content by accepting cookies" combined with the accept button (CNIL issued guidelines on this); (f) Infinite consent screen — a settings page that is so complex that most users give up and accept all.
Does Google Analytics require cookie consent under GDPR and ePrivacy, and what has changed since the Austrian and French DPA decisions?
The enforceability of Google Analytics under GDPR has been one of the most significant data privacy enforcement topics since January 2022, when the Austrian DSB (Data Protection Authority) issued the first of what became a series of coordinated DPA decisions finding that Google Analytics transfers violated the EU-US data transfer restrictions (pre-DPF). Understanding where things stand in 2025-2026 requires tracking the regulatory timeline. The Austrian DSB January 2022 decision: the DSB found that the use of Google Analytics transferred IP addresses and other identifiers to Google LLC in the US without adequate safeguards (the Privacy Shield had been invalidated in Schrems II, July 2020, and Standard Contractual Clauses required a Transfer Impact Assessment showing the US did not provide equivalent protection). The DSB found that Google could be subject to US FISA 702 surveillance orders and that SCCs plus Google's supplementary measures were insufficient to protect EU data subjects. This finding was replicated by DPAs in France (CNIL, January 2022), Italy (Garante, June 2022), and other EU Member States. The European Data Protection Board (EDPB) coordinated this response via its joint taskforce on SCCs and US surveillance. The EU-US Data Privacy Framework (DPF), implemented July 2023: the European Commission issued an adequacy decision for the DPF (Commission Decision C(2023) 4745) on July 10, 2023. Google participated in the DPF by self-certifying to the US Department of Commerce. Under the DPF adequacy decision, transfers to DPF-certified US entities are presumed adequate without requiring SCCs or a Transfer Impact Assessment. Google Analytics 4 (GA4), Google Ads, and other Google services covered by the DPF certification now have an adequate transfer mechanism. This significantly changes the transfer law analysis for EU entities using GA4. However, the DPF faces ongoing legal challenges: Max Schrems and NOYB filed a complaint challenging the DPF with the Irish DPC, and the case was referred to the CJEU in 2024. If the CJEU invalidates the DPF (as it did Privacy Shield in Schrems II), the transfer issue would resurface. The separate ePrivacy consent requirement remains unchanged by the DPF: regardless of the transfer law status, Google Analytics sets cookies on users' devices. Under PECR/ePrivacy, this requires prior consent from EU/UK users. The DPF does not change the ePrivacy consent requirement — the consent is for device access, not for the transfer. Google Analytics 4 server-side tagging: some practitioners argue that GA4 server-side implementation (where JavaScript runs on the server and does not set cookies directly on the user's device) is outside the scope of the ePrivacy "terminal equipment" access requirement. This argument has not been adjudicated definitively by DPAs. If server-side GA4 uses probabilistic identification (without device-set identifiers), the analysis shifts to GDPR legitimate interests rather than ePrivacy consent — but this remains legally uncertain. Privacy-preserving analytics alternatives (Plausible Analytics, Fathom, Matomo in cookieless mode): these tools are designed to operate without cookies or device fingerprinting, using aggregated, non-identifiable data. The GDPR/ePrivacy analysis for these tools: if no cookie is set and no individual-level data is collected, the ePrivacy consent requirement may not apply (the "strictly necessary" for server logs and aggregate analytics argument). However, server-side IP address collection is still regulated under GDPR (IP addresses are personal data per the CJEU in Breyer — Case C-582/14). The legal basis for server-side cookieless analytics is frequently argued to be legitimate interests under Article 6(1)(f) GDPR, but some DPAs (particularly in Germany) have challenged even this analysis. Practical recommendation: for consent-required analytics, implement a CMP with granular analytics consent. For consent-optional analytics, use a cookieless analytics tool and document your legal basis assessment (anonymous data if truly aggregated, or legitimate interests with a completed LIA for server-side analytics).
What is the IAB Transparency and Consent Framework (TCF), and when do websites need to implement it vs a custom CMP?
The IAB Transparency and Consent Framework (TCF) is an industry technical standard developed by IAB Europe (Interactive Advertising Bureau Europe) designed to provide a scalable mechanism for obtaining and transmitting GDPR and ePrivacy consent for digital advertising. Understanding when it's required (vs optional) and its own compliance challenges is essential for any publisher that runs programmatic advertising. What the TCF is: the TCF creates a standardized consent string format (TC String) that encodes: (a) which "purposes" (11 purposes defined by IAB) the user has consented to or granted legitimate interests for; (b) which specific vendors (from the IAB Global Vendor List, which has thousands of adtech vendors) the user has consented to or denied. Publishers implementing a TCF-compliant CMP collect these signals and pass them upstream to their supply-side platform (SSP), which passes them to demand-side platforms (DSPs) and advertisers. This allows the programmatic ecosystem to respect consent signals. When TCF is effectively required: any publisher running programmatic advertising through Google Ad Manager (GAM) or Google AdMob must use a TCF-registered CMP or Google's own Funding Choices. Google's EU User Consent Policy requires that publishers running GAM traffic use a Google-approved CMP that passes valid TC strings. If you do not pass a valid TC string, GAM defaults to non-personalized ads — significantly reducing CPMs (often 50-80% lower). Publishers on The Trade Desk, AppNexus/Xandr, or similar programmatic platforms similarly benefit from passing TC strings. When a custom CMP is sufficient: publishers who do not run programmatic advertising and only use first-party analytics (Plausible, server-side Matomo) do not need TCF. Their consent requirements are simpler: a clear banner with accept/reject options, granular consent for each cookie category, and a mechanism to withdraw consent. Custom CMPs (OneTrust custom configs, Cookiebot, Termly, simple hand-coded banners) are sufficient when: (a) the site uses only first-party non-advertising cookies; (b) no third-party advertising tech is used; (c) the site doesn't need to pass consent signals to a programmatic supply chain. TCF's own compliance challenges: the IAB TCF has faced significant regulatory scrutiny. The Belgian APD in its February 2022 decision found that TCF 2.0 itself violated GDPR: (a) the IAB Europe's TC String (which encodes consent preferences) itself constitutes personal data because it can be linked to an individual; (b) IAB Europe was therefore a controller of that data and had not fulfilled its own GDPR obligations; (c) publishers who operated under TCF 2.0 may have violated GDPR by processing non-compliant consent signals. IAB Europe was fined €250,000 and ordered to remediate. IAB Europe released TCF 2.2 (August 2023) incorporating changes required by the Belgian APD and other regulators. However, the fundamental controversy about the TCF — that it facilitates mass consent signal processing by thousands of adtech vendors whose identity and purposes are not practically meaningful to a user clicking "Accept" on a CMP — has not been resolved and continues to be scrutinized. CMP vendor comparison (practical): TCF-registered CMP examples: OneTrust, Didomi, Quantcast Choice, Cookiebot by Usercentrics, Sourcepoint. Non-TCF CMPs: Plausible Privacy Policy banner, Cookieyes, Termly. Key difference: TCF-registered CMPs can validate and submit TC strings to the IAB global vendor register; non-TCF CMPs cannot participate in programmatic consent signal chains. For publishers relying on Google Ads monetization: use a Google-certified CMP from the Google CMP Partner Program list. The TCF registration and Google certification are separate — a CMP must be both TCF-registered and Google-certified to satisfy Google's requirements.
What are the cookie consent requirements for UK websites under PECR, and how does UK post-Brexit compliance differ from EU GDPR?
The UK's post-Brexit data protection landscape creates a parallel (but not identical) compliance regime to EU GDPR for UK-established organizations and for organizations directing services to UK users. Understanding the differences is critical for organizations serving both EU and UK audiences. UK cookie law framework: the Privacy and Electronic Communications Regulations 2003 (PECR) SI 2003/2426, as amended by SI 2011/1208, implement the ePrivacy Directive in the UK. Post-Brexit, the UK retains PECR as domestic law under the European Union (Withdrawal) Act 2018. The UK GDPR (the GDPR as retained and amended in UK law) governs personal data processing after the cookie is set. The ICO enforces both PECR and UK GDPR. Key substantive differences between UK and EU cookie law: (1) PECR Regulation 6 legitimate interests exemption: the UK's PECR Regulation 6 includes a separate ground for cookie storage (beyond the Regulation 6(4) strictly necessary exemption) — "to the extent that such action is necessary for the performance of a task carried out in the public interest." This is less commonly used but is one divergence point. More significant: the ICO's guidance takes a pragmatic position on analytics cookies that differs somewhat from some EU DPA positions — the ICO has long supported "privacy-preserving analytics" as a justified use case with fewer consent hurdles, though this has not been enshrined in regulatory decisions as definitively as some practitioners assume. (2) UK GDPR vs EU GDPR consent standard: the UK GDPR retains identical consent requirements to EU GDPR — freely given, specific, informed, unambiguous, withdrawable. Planet49-style requirements apply in the UK as implemented through the ICO's cookie guidance. No practical difference in the consent quality standard. (3) PECR enforcement history: the ICO has historically focused PECR enforcement on direct marketing (spam SMS and calls) rather than cookie banners. However, the ICO issued its third audit of cookie consent in 2023 and has sent enforcement notices to websites with non-compliant banners. Compared to the French CNIL (which fined Google €150M and Facebook €60M in January 2022 for cookie rejection mechanisms requiring multiple clicks), the ICO has been less aggressive on cookie banner design enforcement — but this is shifting. (4) The proposed UK PECR reform (DPDI Bill): the Data Protection and Digital Information Bill (DPDI Bill), passed as the Data (Use and Access) Act 2025, includes provisions that would create a "recognized legitimate interests" list for PECR — which would move certain analytics and security cookies from requiring consent to a legitimate interests ground. This represents a significant divergence from EU ePrivacy if implemented. The Act received Royal Assent in June 2025; the PECR amendments will come into force on a commencement date to be determined by SI. (5) Cross-border: if a UK organization uses EU-targeting advertising cookies, the EU GDPR and national ePrivacy laws of the EU Member States where users are located govern the EU side of the tracking, regardless of the UK's post-Brexit rules. Organizations serving both EU and UK users should implement EU GDPR-compliant consent (the higher standard) for all users, rather than trying to serve different banners based on user location (which is technically complex and creates risk of misidentifying user jurisdiction). Practical UK PECR compliance requirements (unchanged): (a) Consent is required before non-strictly-necessary cookies are set — confirmed by ICO; (b) Pre-ticked boxes are not valid consent; (c) Consent must be as easy to withdraw as to give; (d) Cookie information must be provided prior to consent; (e) Consent records must be maintained.