Back to blog
GDPR Compliance Consent Audit Guide

GDPR Consent Audit: How to Check If Your Website Is Actually Compliant

Most consent banners don't work as intended. Here's how to audit your website's cookie consent implementation and find violations before regulators do.

Reconix Team ·

The consent banner is everywhere. Every website has one. Most of them are broken.

Not broken in the sense that they fail to display — they display fine. Broken in the sense that the underlying mechanics don’t actually implement consent. Trackers fire before anyone clicks anything. Analytics load regardless of what the user chooses. The “reject all” button is buried three clicks deep while “accept all” is a single prominent tap.

Regulators have noticed. In 2023, France’s CNIL fined SHEIN €150 million in part over consent violations. Google received a €125 million fine from French and Spanish regulators over cookie consent practices. The Irish DPC, German DSKs, and Dutch AP have all issued enforcement actions in the €50,000–€10 million range for consent violations that were not materially different from what you’ll find on a large percentage of mid-market websites today.

This guide covers what regulators actually look for, how to audit your implementation manually, what proper tooling adds to the process, and how to fix the most common violations.

What Regulators Actually Check

The GDPR’s consent standard under Article 7, combined with the ePrivacy Directive (the “Cookie Law”), requires that consent be:

  • Freely given — rejecting consent cannot be harder than accepting it
  • Specific — consent for analytics cannot be bundled with consent for advertising
  • Informed — the user must know what they’re consenting to
  • Unambiguous — no pre-ticked boxes; silence is not consent
  • Revocable — withdrawal must be as easy as giving consent

Regulators auditing a website for consent compliance are checking a specific sequence of events, not just whether a banner appears:

1. What loads before consent is given?

Load the page in a clean browser with network monitoring active. Before clicking anything on the consent banner, what third-party requests fire? Any Google Analytics, Facebook Pixel, or advertising network requests that fire before consent is a potential ePrivacy violation. The CNIL specifically calls this out as a “pre-consent tracker” violation.

2. Does refusing consent actually change behavior?

Click “reject all” (or the functional equivalent). Then navigate to a second page on the same site. Do the same trackers fire? In many implementations, the consent banner is cosmetically functional but the underlying tag manager fires everything regardless of the consent signal it receives.

3. Is the “reject all” path genuinely equivalent to “accept all”?

GDPR guidance from multiple supervisory authorities — including the UK ICO, CNIL, and German DSK — requires that a user be able to refuse all non-essential cookies with the same number of actions required to accept them. If “accept all” is one click and “reject all” requires opening “Manage preferences,” scrolling through 12 category toggles, and clicking “Save” — that’s a dark pattern under current enforcement guidance.

4. Are consent records being kept?

Article 7(1) requires that the controller be able to demonstrate that consent was given. This means logging consent events: timestamp, what was consented to, the version of the privacy notice at the time, and a way to link the consent record to a specific user interaction. Many sites with functional consent banners fail entirely on the record-keeping requirement.

5. Are pre-ticked boxes or misleading toggles being used?

Pre-ticked checkboxes are explicitly prohibited. Consent toggles that are “on” by default for non-essential categories are the functional equivalent. They’re common, particularly in older OneTrust and Cookiebot implementations that weren’t configured with current requirements in mind.

Common Violations in the Wild

After analyzing thousands of websites, these are the violations we see most frequently:

This is the most common and most serious violation. It typically happens because:

  • The tag manager (GTM, Tealium, etc.) is configured to load all tags immediately, with the consent management platform (CMP) as a separate layer that doesn’t actually gate tag execution
  • First-party analytics scripts are hardcoded in the HTML <head> before the CMP loads
  • Marketing pixels were added directly to the page at some point and the CMP was never updated to cover them

A well-known variation: Google Analytics 4 configured with gtag.js fires a page_view event on load. If GA4 is loaded unconditionally and consent is handled by a separate CMP, that page_view fires before the user sees the banner — and it contains the user’s IP address and URL.

No Functional “Reject All” at the Top Level

The CNIL and German DSKs have been explicit: a button to refuse all non-essential cookies must be accessible without entering a preference management modal. If your banner has “Accept” and “Manage preferences” but no “Reject” or “Decline all,” you are out of compliance with current French and German regulatory guidance.

The IAB Transparency and Consent Framework (TCF) provides a standardized consent string format used by most ad tech. When a user sets their consent preferences, a TC string is stored and sent with ad requests. Misconfigured CMP setups often generate the TC string correctly but fail to pass it to the downstream ad and analytics vendors.

The symptom: a user rejects all advertising consent, but ad network requests still fire — the server at the other end simply ignores the empty consent string because none was sent, or an outdated version was sent.

A CMP configured to only manage cookies may miss non-cookie tracking: localStorage, sessionStorage, IndexedDB, fingerprinting via Canvas or WebGL, and server-side session identifiers. Under GDPR, what matters is whether personal data is processed, not whether the mechanism is technically a “cookie.” If your audit covers cookies only, you may be missing significant tracking vectors.

Many organizations obtained valid consent in 2018 when GDPR came into force, but have since added new vendors, changed their data processing purposes, or updated their privacy notice — without re-obtaining consent for the changed conditions. Consent tied to a privacy notice version that no longer matches current practice is not valid consent.

How to Audit Manually

You can perform a basic consent audit using browser developer tools. It takes about 30 minutes for a typical site and will surface the most serious violations.

Step 1: Clear state and enable network monitoring

Open a private/incognito browser window. Open DevTools (F12). Navigate to the Network tab and enable “Preserve log.” Navigate to the Application tab and clear all storage (Cookies, Local Storage, Session Storage, IndexedDB, Cache Storage).

Step 2: Load the page — don’t click anything

Navigate to the homepage. Wait for the consent banner to appear. Stop. Do not click anything.

In the Network tab, filter for third-party requests. Look for:

  • google-analytics.com, googletagmanager.com, googletagservices.com
  • facebook.com/tr, connect.facebook.net
  • analytics.tiktok.com, snap.com/media-ads
  • Any ad network domains (doubleclick.net, bing.com/action/0, etc.)

Any of these firing at this stage — before you’ve interacted with the consent banner — is a pre-consent tracker violation.

Step 3: Click “reject all” (or the closest equivalent)

Find and use the least-consent path available. If there is no “reject all” at the top level, note that as a violation. Record which cookies and storage items are set after rejection. Navigate to a second page on the site.

Watch the Network tab again. Do the same third-party trackers fire? If analytics and advertising networks load on the second page despite rejection, the consent signal is not being respected.

Repeat the process from a clean state, this time accepting all consent. Compare the network requests to what you saw post-rejection. The difference is the set of trackers that are actually gated on consent. Anything present in both states is not being consent-controlled.

Step 5: Check the CMP configuration

Use browser DevTools to inspect what the CMP stores. For most CMPs:

  • OneTrust stores consent in OptanonConsent cookie
  • Cookiebot stores it in CookieConsent cookie
  • The IAB TCF string is in euconsent-v2 cookie or localStorage

Decode the TCF string if present (tools like iabgdpr.com can parse them) and verify it matches what you selected.

Manual auditing has two significant limitations: it can’t easily replay both states and compare, and it can’t catch violations on pages other than the ones you manually test.

An automated consent audit tool instruments a real browser to:

  1. Load the page pre-consent and capture all network requests, cookies, and storage state
  2. Identify the CMP platform (OneTrust, Cookiebot, Osano, TrustArc, Didomi, etc.) from code signatures
  3. Interact with the CMP programmatically — clicking “accept all” or “reject all” via the CMP’s documented API or DOM interaction
  4. Load subsequent pages and capture post-consent state
  5. Compute the delta — which trackers were present pre-consent vs. added only after acceptance
  6. Classify each tracker by consent tier: Essential (CDN, security, hosting), Functional (live chat, fonts), Analytics, and Marketing/Advertising
  7. Generate a compliance score based on what fired before consent, whether a reject path exists at the top level, and whether consent is properly propagated

The output is actionable: a list of specific trackers that fired before consent with their category and risk level, a verdict on the CMP’s reject-all accessibility, and a summary of the consent tier distribution.

How to Fix Common Issues

Pre-consent trackers: The fix depends on how the trackers are loaded. For GTM-loaded tags, configure consent initialization in GTM’s built-in consent mode: set default consent state to “denied” for all categories and only fire tags when the appropriate consent signal is received. For hardcoded scripts, wrap them in a conditional that checks the CMP’s consent state before injecting the <script> element. Never load analytics scripts unconditionally in the <head>.

No top-level reject button: This is a CMP configuration issue, not a technical implementation problem. In OneTrust, enable the “Reject All” button in the banner template. In Cookiebot, enable the decline button in the configuration panel. Most modern CMPs support this — it’s a configuration choice, usually made without legal review, to not show it.

Consent not propagating to ad vendors: Enable Google Consent Mode v2 if you’re using Google’s advertising products — this sends the consent signal through the Google tag infrastructure. For non-Google vendors, check that your CMP’s TCF publisher controls are configured and that the IAB-registered vendors you use are listed in your CMP’s vendor list.

Outdated consent records: Implement a consent versioning system — most enterprise CMPs support this. When your privacy notice changes materially, increment the consent version. Users whose consent was obtained under an older version should be re-prompted on their next visit.

Consent record keeping: Configure your CMP to log consent events to a server-side store. Most enterprise CMPs have built-in consent logging to their own cloud. For first-party logging, configure the CMP’s webhook or API to write consent events to your own database, including timestamp, user identifier (anonymized), consent version, and category selections.

Reconix’s consent audit runs a dual browser session — pre-consent and post-consent — for any URL, identifies the CMP platform, maps the consent tier for each detected tracker (from a database of 208 subprocessors), and produces a compliance score with specific violation callouts.

It handles CMP-specific acceptance flows for OneTrust, Cookiebot, Osano, TrustArc, Didomi, and Quantcast Choice — so you don’t need to manually navigate different banner UIs. The analysis reveals pre-consent trackers, evaluates whether reject paths are accessible, and shows you the full picture of what loads at each consent tier.

For sites you don’t own, it’s a useful due diligence tool. For sites you do own, run it before your next regulatory interaction — the list of violations it surfaces is exactly the list a regulator would generate using the same methodology.

The consent landscape is not going to simplify. Enforcement budgets are increasing, cross-border cooperation between supervisory authorities is improving, and the technical bar for compliance has risen significantly since 2018. A consent banner that looked acceptable three years ago may not meet current standards.

The good news is that fixing most consent violations is straightforward once you know what they are. The audit — finding them — is the hard part.