GDPR Cookie Consent Requirements: What Website Owners Must Know

This is article 3 of the Cookie Compliance series. Article 1 mapped GDPR/ePrivacy beside CCPA/CPRA and India’s DPDP Act. Article 2 covered a OneTrust install. Here the focus is what website owners must get right for GDPR-style cookie consent when they reach people in the EEA (and, in practice, when they treat UK traffic with the same care unless counsel says otherwise).

This is practical orientation drawn from public EDPB materials and the ePrivacy/GDPR texts. It is not a substitute for counsel, and national ePrivacy implementations still matter for enforcement detail.

Who this article is for

• Site owners, marketers, and product managers who run analytics, ads, chat, or experiment tags for European visitors.
• Teams configuring CMP geolocation rules and need a plain-language checklist, not a statute reprint.
• Agencies that inherited a theme banner and need to know which patterns fail EDPB cookie-banner scrutiny.

The two-layer legal model (plain English)

Layer 1: ePrivacy Article 5(3)

Article 5(3) of Directive 2002/58/EC (ePrivacy Directive), as amended, restricts storing information, or gaining access to information already stored, in a user’s or subscriber’s terminal equipment. Consent is required unless a narrow necessity exception applies (for example, storage or access that is strictly necessary to provide a service explicitly requested by the user).

That rule is about the device, not only about “personal data” in the GDPR sense. Classic cookies, many pixels, and other client-side storage or access patterns can be in scope. EDPB Guidelines 2/2023 on the technical scope of Article 5(3) walk through when operations count as storage or access on terminal equipment, and remind readers that falling under Article 5(3) does not automatically mean consent is required. You still check whether an exemption applies for that use case.

Layer 2: GDPR consent quality

When consent is the basis (for the ePrivacy storage/access step, and often for later processing of resulting personal data), GDPR standards apply. EDPB Guidelines 05/2020 on consent under Regulation 2016/679, and the EDPB Cookie Banner Taskforce report adopted on 17 January 2023, are the practical references website teams cite most often.

GDPR 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. Article 7 adds conditions on requests, records, and withdrawal.

EDPB Opinion 05/2019 on the interplay between the ePrivacy Directive and the GDPR also notes that website operators (not only telecom providers) can fall under ePrivacy Article 5(3) for cookies, and that both instruments can apply to the same tracking activity.

What “valid cookie consent” means in practice

1. Prior consent before non-essential tags fire

The Cookie Banner Taskforce report is blunt: by default, no cookies that require consent may be set without consent, and consent must be a positive action by the user. Loading marketing and analytics tags on first paint, then asking later, fails that model.

Engineering translation: block or delay non-essential scripts until Accept (or a granular grant) for consent-required regions. A CMP banner alone is not enough if GTM still fires Meta and Google Ads on page one.

2. Informed notice

Users need enough information to understand who is asking, what purposes apply, what categories of data or trackers are involved, and how to withdraw. Link to a readable privacy or cookie notice. Match the notice to the inventory you actually run. Three cookie names in the text while twenty vendors load is a compliance and trust failure.

3. Freely given choice (including cookie walls)

Guidelines 05/2020 state that access to services and functionalities must not be made conditional on consent to store or access information on the terminal equipment (so-called cookie walls) if that means there is no genuine choice. The revised guidance includes an example where content stays blocked behind an Accept button with no other path; that is not freely given consent.

Owner takeaway: do not design “Accept cookies or leave” as your only path when the processing is not necessary for the service. Counsel should review paywall or tracking-wall designs case by case; this article does not bless them.

4. Specific and granular purposes

Bundling unrelated purposes into one forced Accept undermines specificity. Preference centers should let users grant analytics without ads (or the reverse) when those are separate purposes. Pre-ticked optional categories are invalid under GDPR recital 32 and the Taskforce conclusions.

5. Unambiguous affirmative action

Silence, inactivity, and pre-ticked boxes do not count. The Taskforce also rejected designs where scrolling alone is treated as consent. Require a clear click (or equivalent affirmative control) on Accept or on specific toggles.

6. Reject as easy as accept

Taskforce work on deceptive designs stresses comparable prominence. Accept-only first layers, buried Reject links, or colour tricks that hide refusal are enforcement magnets. Put Reject non-essential (or equivalent) on the first layer with Accept, or an equally obvious path that does not force extra mazes.

7. Withdrawal as easy as giving consent

GDPR Article 7(3) and the Taskforce report require that withdrawal be possible at any time and as easy as the original grant. After consent is collected, keep an easily accessible reopen control (footer link, preference icon, or Cookie Settings button). Authorities look at whether withdrawal is genuinely easy in practice; they do not all mandate one specific floating widget design.

What usually does not need marketing-style opt-in

Strictly necessary storage or access for a service the user explicitly requested can fall under the Article 5(3) exemption. Typical examples teams discuss with counsel:

• Load balancing or security tokens required to deliver the page.
• Login session cookies for an account the user asked to open.
• Remembering the fact of a consent choice itself so the banner does not loop forever.

Product analytics, advertising measurement, most A/B testing for marketing optimisation, and social pixels are rarely “strictly necessary” for the service the user requested. Treat them as consent-required in EEA geolocation rules unless counsel documents a different analysis for a narrow case.

Owner checklist you can encode in a CMP

1. Inventory: List every cookie, pixel, SDK, and local storage key with purpose and vendor.
2. Classify: Mark essential vs optional. Wrong classification is how illegal tags get a free pass.
3. Banner copy: Identify the controller(s), list purposes, link the full notice, explain withdrawal.
4. First-layer controls: Accept all, Reject non-essential, and open preferences, with balanced visual weight.
5. Granular preferences: Purpose toggles off by default for optional categories.
6. Blocking: Non-essential tags stay silent until grant in consent-required regions.
7. Records: Store what was shown, what was chosen, when, and which policy version applied.
8. Reopen and withdraw: Persistent Cookie Settings control; honour later denials in tags and Consent Mode.
9. Google Consent Mode v2: For Google tags, set denied defaults where required, then update ad_storage, analytics_storage, ad_user_data, and ad_personalization from the CMP. See Google’s consent mode setup guide.
10. Retest: Clean-profile checks after every major tag or template change.

If you use OneTrust, encode the EEA/UK model in geolocation rules, keep Auto-Blocking or GTM gates honest, and map categories to Consent Mode as described in article 2.

Dark patterns that keep failing reviews

• Accept button loud and colourful; Reject hidden behind “Manage” then three more screens.
• Pre-ticked marketing and analytics toggles.
• Cookie walls that block all content solely to force tracking consent.
• Consent text that claims “essential analytics” for ordinary traffic measurement.
• Banners that disappear on scroll and count that as agreement.
• No way to reopen preferences without clearing site data by hand.
• CMPs that log Accept while tags ignore Reject.

Territorial reach in one paragraph

GDPR can apply to a non-EU company that offers goods or services to people in the EEA or monitors their behaviour (Article 3). ePrivacy cookie rules are implemented in Member State law and enforced through national frameworks, with cooperation discussed in EDPB materials on ePrivacy/GDPR interplay. If your analytics show meaningful EEA traffic, or you run EU-targeted ads, design for prior consent rather than arguing invisibility. UK GDPR and UK privacy rules follow a closely related cookie consent model; many global CMPs apply the same opt-in UX to UK visitors.

How this fits California and India (short)

California CCPA/CPRA is not an EU-style prior opt-in cookie regime for ordinary collection. It focuses on disclosure and, where you sell or share personal information, opt-out and signal handling. India’s DPDP Act does not name cookies; where trackers process personal data, notice and consent principles apply, with Rule detail phasing in on a published runway. Do not copy an EEA banner into those regions without checking whether the UX matches the duty. Article 1 covers the overlap table in more depth.

FAQ

Is a cookie banner legally required under GDPR?

GDPR does not invent a “banner” widget. ePrivacy Article 5(3) plus GDPR consent rules require a prior, valid consent mechanism for non-essential device storage/access. A banner plus preference center is the usual UX, not the only possible one. Whatever UI you use must meet the consent tests above.

Are GA4 cookies essential?

Usually no. Measurement that is not strictly necessary to deliver the service the user requested typically needs consent in the EEA model. Wire Consent Mode and block or restrict tags until grant.

Does reject have to sit on the first screen?

Taskforce conclusions push hard toward refusing as easily as accepting, including comparable prominence. Designs that bury refusal behind extra steps face objections. Put a clear Reject (or equally prominent refuse path) on the first layer unless counsel documents a different, still-valid pattern for your case.

Do I need consent receipts?

GDPR Article 7(1) places the burden of demonstrating consent on the controller. Keep records of what users saw and chose. CMP receipt features exist for that reason.

What about “similar technologies” beyond cookies?

EDPB Guidelines 2/2023 address the technical scope of Article 5(3) for storage and access on terminal equipment beyond classic cookies. Inventory pixels, local storage, and SDK identifiers with the same seriousness as HTTP cookies.

Sources and further reading

• EDPB: Report of the work undertaken by the Cookie Banner Taskforce (adopted 17 January 2023).
• EDPB: Guidelines 05/2020 on consent under Regulation 2016/679 (including cookie wall revisions).
• EDPB: Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive (version 2).
• EDPB: Opinion 5/2019 on the interplay between the ePrivacy Directive and the GDPR.
• Directive 2002/58/EC (ePrivacy Directive) Article 5(3); Regulation (EU) 2016/679 (GDPR) Articles 4(11), 7, and related provisions.
• Google Tag Platform: Set up consent mode on websites.
• Series: Cookie Compliance: A Practical Guide; article 2 on OneTrust setup (draft in this series).

Next in this series

Later posts cover a DPDP-focused checklist, banner patterns that keep choice usable, pre-CMP audits, CMP vs manual builds, Consent Mode v2 with OneTrust in more depth, consent records, and multi-region programs that span CCPA-to-GDPR stacks.

Disclaimer

This article was prepared by Imran using publicly available information. It is for general education only and is not legal advice. Do not rely on it alone when implementing cookie compliance, DSAR handling, consent flows, privacy policies, or other privacy and data-protection controls. Consult your own legal counsel for advice that fits your business, jurisdictions, and systems.

Last updated on 18 September 2026