GDPR Cookie Consent Banner: What Makes One Actually Compliant
Most cookie banners on the web are theatre. They look like consent — a pop-up appears, you click something, and the site carries on. But what is actually happening under the hood is a different story. Analytics fires before you click. Pre-ticked boxes assume your agreement. The reject option is buried three layers deep while the accept button gleams in blue.
Regulators know this. The French CNIL, the Irish DPC, and the EU Data Protection Board have all published guidance and enforcement actions specifically targeting non-compliant GDPR cookie consent banners. The days of vague "we use cookies" notices are over. Here is what a compliant GDPR cookie consent banner actually requires — technically and legally.
Why Cookie Consent Matters: The ePrivacy Directive and GDPR
The legal basis for cookie consent comes from two overlapping laws. The ePrivacy Directive (often called the Cookie Law) requires that non-essential cookies can only be set with the user's prior consent. GDPR then layers on top: it defines what valid consent means, and it is strict.
Under GDPR Article 4(11), consent must be:
- Freely given — no wall between the service and the refusal option
- Specific — tied to particular purposes, not bundled under a single yes/no
- Informed — the user must know what they are agreeing to
- Unambiguous — a clear affirmative action, not silence or pre-ticked boxes
This is why a scrolling "by continuing to use this site" notice fails. The user has not actively done anything to signal agreement. That is not consent under GDPR.
The Three Things a Compliant GDPR Cookie Consent Banner Must Do
1. Block Non-Essential Cookies and Scripts Before Consent Is Given
The most fundamental requirement — and the one most banners fail — is that non-essential cookies and the scripts that set them must not fire until the user has actively consented.
This is not about the banner appearing. It is about whether Google Analytics, Meta Pixel, Hotjar, and every other non-essential tool is blocked from loading until after the user makes a choice.
2. Make Rejection as Easy as Acceptance
If you have an "Accept All" button, you must have a "Reject All" button at the same level and with similar visual prominence. The CNIL's 2022 guidelines and the EDPB's 2023 cookie banner task force report both make this explicit: if a single click accepts all cookies, a single click must also reject all cookies.
Anything else — a reject option hidden under "Manage Preferences," a greyed-out reject link, a smaller font — is a dark pattern that invalidates consent.
3. Record and Store Consent Evidence
Consent without a record is legally worthless. Under GDPR Article 7(1), if challenged, you must be able to demonstrate that valid consent was obtained. Your GDPR cookie consent banner system must log what the user agreed to, when they agreed to it, and under which version of your banner.
What Makes a Banner Non-Compliant
Regulators have been explicit about what they look for. The following patterns are consistently cited in enforcement guidance:
Pre-ticked boxes. A checkbox that arrives already ticked signals agreement you do not have. GDPR explicitly prohibits using pre-ticked boxes as a mechanism for obtaining consent.
No reject option on the first layer. If your first screen offers "Accept All" but requires users to click "Manage Preferences" to find a way to decline, that is not freely given consent. The asymmetry itself makes the banner non-compliant.
Confusing language. Phrases like "Help us improve your experience" as a label for marketing cookies, or "Functional partners" used to describe advertising networks, are considered deceptive. Consent must be informed, and informed means the user genuinely understands what they are agreeing to.
Colours and design that hide the reject option. The EDPB cookie banner task force specifically called out using the same background colour for the reject button as the banner background, or making the reject text the same grey as body text while the accept button is a vivid primary colour. Visual hierarchy that steers users toward acceptance is a dark pattern.
Cookie walls. Blocking access to content entirely unless users accept all cookies is generally not considered freely given consent, particularly if there is no equivalent paid or consent-free alternative.
Script Blocking: What It Means and Why CSS-Only Banners Fail
A GDPR cookie consent banner that does not block scripts is a cosmetic feature, not a compliance mechanism.
When a visitor lands on your site, the browser begins loading resources. Without active script blocking, a tag manager like Google Tag Manager will fire its full container — including Google Analytics, Meta Pixel, LinkedIn Insight Tag, and any other configured tags — before the user has seen or interacted with any consent interface.
A proper GDPR cookie consent banner must intercept this loading process. Technically, this means:
- The consent management platform (CMP) loads before any analytics or marketing scripts
- Scripts are wrapped or conditionally loaded based on consent status
- Tag manager containers fire only after consent is confirmed for the relevant categories
CSS-only banners — banners that use only stylesheet tricks to appear on screen — cannot block scripts. They are display layers with no ability to influence JavaScript execution. If your banner is just HTML and CSS sitting on top of an already-loaded analytics stack, it is not functional compliance. It is a visual disclaimer on top of non-compliant behaviour.
The "Reject All" Button: First Layer Requirement
This is the issue generating the most enforcement activity in 2024 and 2025. The CNIL has issued formal notices requiring companies to add a first-layer reject option. The Danish DPA has published identical guidance. The Irish DPC has been explicit in its investigation findings.
The rule is straightforward: if a single click can accept all cookies, a single click must be able to reject all cookies. Both options must appear on the same banner layer with comparable visual prominence.
"Comparable visual prominence" means similar button style, similar size, similar colour contrast. It does not require the buttons to be identical — but it does require that the reject option is not deliberately designed to be less noticeable.
Common compliant configurations:
- "Accept All" (blue button) | "Reject All" (outlined button of the same size)
- Three buttons: "Accept All" | "Reject All" | "Manage Preferences"
- Two links of the same weight: "Accept" | "Decline"
Non-compliant configurations:
- "Accept All" (button) and a grey text link for "reject"
- "Accept All" visible, reject accessible only after clicking "Cookie Settings"
- "I agree" as a button with no equivalent disagree option visible
Granular Consent: Categories vs All-or-Nothing
GDPR requires that consent be specific. Bundling analytics, advertising, personalisation, and functionality cookies into a single on/off toggle is technically not specific consent — particularly when these purposes have meaningfully different privacy implications.
Best practice, and the expectation of most supervisory authorities, is category-based consent with at minimum:
- Strictly Necessary — always on, no consent required (session cookies, security tokens)
- Analytics — visitor measurement, behaviour tracking
- Marketing / Advertising — retargeting, ad conversion, interest profiling
- Personalisation — content adaptation based on user behaviour
Each category should have a description that clearly explains what it does and which third parties are involved. Listing "Google, Meta, LinkedIn" alongside the marketing category tells users meaningfully more than "advertising partners."
Re-Consent: When and How Often to Ask Again
Consent is not permanent. GDPR requires that consent be renewed when:
- You add new cookie categories or new vendors in an existing category
- Your privacy policy changes in ways that affect what users agreed to
- The consent itself is approaching expiry — while GDPR does not set an explicit renewal period, regulatory guidance consistently suggests 6 to 12 months as a reasonable maximum
- A user initially rejected and you want to ask again — this is permitted, but not repeatedly. Asking a user who rejected cookies every session is itself considered a dark pattern
Your GDPR cookie consent banner system should store the consent timestamp and version. When either exceeds your defined threshold, trigger a fresh consent request.
Consent Records: What to Log
Under GDPR Article 7(1), the burden of proof sits with the data controller. You must be able to demonstrate that consent was given. This means your consent management system must store a record containing:
- A user identifier (cookie ID or, for authenticated users, account ID)
- The timestamp of consent
- The version of the banner or consent notice shown
- What the user consented to (specific categories accepted or rejected)
- The IP address or country of the user (for geo-targeting records)
- The method of consent (click, keyboard, etc.)
This record must be queryable. If a user submits a DSAR and asks what data you hold on them, or if a regulator requests evidence that consent was validly obtained, you need to be able to retrieve a specific record.
Storing these records securely and retaining them for the same period you retain the underlying data is part of demonstrating accountability under GDPR.
Global Privacy Control (GPC): Must You Honour It?
Global Privacy Control is a browser-level signal that tells websites the user prefers to opt out of data selling and sharing. It originated in the CCPA context but is increasingly relevant under GDPR as well.
Under CCPA (now CPRA), honouring GPC is legally required in California. Under GDPR, there is no explicit statutory obligation to honour GPC — but the EDPB and several national DPAs have noted that browser-based preference signals should be treated as a valid expression of user preference.
Practically, a browser sending a GPC signal represents a user who has expressed a preference before landing on your site. Treating that as a no-consent signal and not loading non-essential scripts is the conservative, defensible position. Several CMPs now support GPC detection natively.
Google Consent Mode v2: Integration with Your Banner
Google Consent Mode v2 became mandatory for EU advertisers using Google Ads and Google Analytics 4 in March 2024. It requires that your GDPR cookie consent banner communicates consent status to Google's tags using a defined API.
When a user accepts or rejects analytics or advertising cookies, your CMP passes the corresponding consent state to Google: analytics_storage, ad_storage, ad_user_data, ad_personalization.
When consent is denied, Google's tags run in a limited "cookieless ping" mode that allows for modelling but does not use cookies or collect personal identifiers.
If your site uses Google Analytics or Google Ads and you have EU visitors, Consent Mode v2 integration is not optional. A GDPR cookie consent banner that does not pass these signals will result in Google tags running without compliance coverage.
Geo-Targeting: Different Rules for Different Visitors
Not every visitor to your site needs to see the same consent banner. Different jurisdictions have different requirements:
- EU / EEA visitors: Full GDPR banner required. Consent must be obtained before non-essential cookies fire. Reject option must be present on first layer.
- UK visitors: UK GDPR applies — effectively the same requirements as EU GDPR
- California visitors: CCPA opt-out mechanism required. "Do Not Sell or Share My Personal Information" must be accessible. GPC signals must be honoured.
- Rest of world: No universal requirement, but best practice is to apply consistent data practices globally
A compliant GDPR cookie consent banner system should detect visitor location (via IP geo-lookup) and serve the appropriate banner variant — GDPR consent for EU/UK, CCPA opt-out for California, and your standard notice for other regions.
Serving the GDPR banner to all visitors globally is a conservative approach that avoids geo-detection errors and simplifies your consent architecture.
Practical Implementation: CMP Platforms vs Basic Scripts
There is a meaningful difference between a full consent management platform and a lightweight cookie script.
A basic cookie script shows a banner and sets a cookie when the user accepts. It typically does not block scripts, does not store granular records, does not handle re-consent triggers, and does not integrate with tag managers at the signal level.
A proper CMP platform:
- Blocks non-essential scripts until consent is given
- Integrates natively with Google Tag Manager and Google Consent Mode v2
- Stores consent records with timestamps and banner versions
- Serves different banner variants by geography
- Handles GPC signal detection
- Provides an audit trail queryable for DSARs and regulatory requests
For most small businesses, a proper CMP adds meaningful cost over a basic snippet. But running a non-compliant banner is not a cost-saving measure — it is a regulatory liability that grows as your site traffic grows.
Custodia's Approach to Cookie Consent
Custodia generates consent configurations based on what it actually finds on your site. Rather than a generic template that lists every possible cookie category, Custodia scans your site, identifies which trackers and cookies are present, and builds a consent record that reflects your actual data practices.
This matters because a consent banner that lists "advertising cookies" when your site has no advertising scripts is harmless. But a banner that fails to list analytics or marketing cookies that are actually firing is a compliance failure — and the kind that regulators can verify with their own scanning tools.
Custodia also stores consent records with timestamps, banner version, and user identifier, so you have the evidence chain required under GDPR Article 7(1). The consent record is linked to your account and queryable when you need to respond to a DSAR or regulatory request.
Practical Checklist: 8 Things to Verify in Your Consent Banner
Non-essential scripts are blocked before consent. Open your browser's network tab, load your site in a private window, and check what fires before you interact with the banner. You should see no analytics, advertising, or non-essential requests.
The "Reject All" option is on the first layer. Users should not have to click into a preferences panel to find a way to decline.
Accept and reject options have comparable visual prominence. Neither option should be visually de-emphasised relative to the other.
No pre-ticked boxes. All categories should default to off and require active selection.
Cookie categories are specific and vendor lists are included. Vague category names with no vendor disclosure do not meet the informed consent standard.
Consent records are stored. Verify that your CMP logs a record with timestamp, banner version, and what was accepted or rejected.
Re-consent is triggered appropriately. If you add a new vendor or change your banner, returning users should be asked again.
Google Consent Mode v2 is configured. If you use GA4 or Google Ads, confirm your CMP passes the four consent signals to Google.
Check Whether Your Banner Is Actually Blocking Cookies
The fastest way to find out whether non-essential cookies are firing before consent on your site is to scan it. Custodia's scanner loads your site before any consent interaction and records every cookie set, every script loaded, and every third-party request made.
If your GDPR cookie consent banner is actually blocking scripts, the scan will show minimal pre-consent activity. If it is not — if analytics and marketing tools are loading regardless — the scan will surface them, along with which specific cookies and trackers are involved.
Scan your site to check whether non-essential cookies are firing before consent →
Last updated: March 27, 2026. This post provides general information about GDPR cookie consent banner requirements. It does not constitute legal advice. For advice specific to your site and jurisdiction, consult a qualified privacy professional.
Top comments (0)