What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.
The GDPR is now eight years old, and yet the most common compliance failure on SMB websites is still the cookie banner. Every regulator in the EU has guidance on it; most have issued at least one fine for non-compliance. The bar is not high — it is just specific, and most banners fail on details that look small but matter.
A GDPR cookie audit is the structured check that tells you whether your site would survive scrutiny from the CNIL, the ICO, the Italian Garante, the Irish DPC, or any of their counterparts. This article walks through what the audit actually does, the rules it applies, and the failures we see most often on SMB sites.
The legal foundation (in plain English)
Two laws apply. The ePrivacy Directive (Article 5(3), the “cookie rule”) requires consent before any non-strictly-necessary information is stored on or read from a user’s device. The GDPR defines what valid consent looks like (Article 4(11), Article 7): freely given, specific, informed, unambiguous, and revocable as easily as it was given.
Stitched together, the rule is straightforward. Before you set or read a non-essential cookie, before you fire a tracking pixel, before you load a third-party script that does either, you need to ask. The user must be able to refuse without penalty, in one click, and to change their mind later just as easily.
What an audit checks, step by step
1. First-page-load network capture
The audit visits your site as a fresh user and records every cookie set, every localStorage write, and every network request fired before the user interacts with the consent banner. Anything non-essential firing here is a violation. This is the single highest-yield check — it catches the majority of real failures on SMB sites.
2. Cookie inventory vs. published policy
The audit lists every cookie your site sets and compares it to your cookie policy. The policy is supposed to disclose all of them — purpose, duration, whether first- or third-party. Most SMB cookie policies are stale templates. Regulators read them.
3. Banner-design check
The audit examines the banner UI for the patterns regulators have specifically called out:
- Equal-weight Accept/Reject. If “Accept all” is a prominent button and “Reject” is hidden in a settings link, the consent is not freely given. CNIL fined Google and Facebook €150M and €60M respectively for this exact pattern.
- No pre-ticked boxes. Every category — analytics, marketing, functional — must default to off.
- Granular categories. A single “accept everything” switch is no longer enough; users must be able to consent to analytics without consenting to advertising.
- Withdrawal as easy as consent. A persistent “Cookie settings” link in the footer, opening the same banner, is the standard.
- No dark patterns. No countdowns, no “continued use of this site means consent,” no “legitimate interest” toggles for advertising.
4. Consent-record proof
The GDPR requires you to be able to prove, for every visitor, that consent was given and what it covered. A modern Consent Management Platform (CMP) does this for you; home-rolled banners almost never do.
5. Third-party script behaviour
The audit re-runs after “Accept all,” after “Reject all,” and after granular partial consents to verify that scripts respect the user’s choice. The most common failure here: a script that loads anyway after “Reject,” often because a tag manager fires it on the wrong trigger.
The failures we see most often on SMB sites
Meta Pixel firing on page load. By far the most common. The Meta Pixel installation guide tells you to drop the snippet in <head>; the snippet fires immediately. In the EU, that’s a violation on every visit. The fix is to either gate the snippet behind your CMP or use Meta’s consent-mode tags.
Google Analytics with no consent gate. GA4 has a consent-mode v2 that most SMBs do not configure. The audit catches it because the script fires regardless of the banner’s state.
Hotjar / Microsoft Clarity / Hubspot recording before consent. Session recorders are particularly sensitive — they capture what the user types, where they move the mouse, and personal data revealed in the page DOM. They cannot run pre-consent without a clear ePrivacy violation.
YouTube embeds in privacy mode but not really. youtube-nocookie.com reduces tracking but still sets cookies and contacts Google. Some regulators accept this as “essential” for video content; most require consent for embeds.
The “continued use of this site” banner. Implied consent has been explicitly rejected by every EU regulator. If your banner uses that phrasing, replace it today.
How to pass the audit
The fix list, in priority order, is the same on most SMB sites:
- Install a real CMP that records consent (not just a banner that hides). Cookiebot, Usercentrics, Iubenda, OneTrust, and Termly all work; pick one that integrates with your stack.
- Move every analytics, advertising, and session-recording script behind the CMP’s consent gate. In Google Tag Manager, this means using consent triggers; in plain HTML, it means deferring the script until the CMP fires its “granted” event.
- Replace the existing banner with one that has equal-weight Accept and Reject, no pre-ticked categories, and granular toggles.
- Add a persistent “Cookie settings” link in the footer.
- Regenerate the cookie policy so it lists what your site actually sets.
- Re-run the audit against the new banner under both Accept and Reject paths.
Why continuous scanning matters here
Cookie compliance breaks silently. Marketing adds a new tag in GTM, a developer drops in a chat widget, a third party updates their script and starts setting a cookie they didn’t before. None of these will trigger an alert in your existing tooling. The audit pattern that works for SMBs is: a baseline scan, fixes, then weekly scans that diff the cookie inventory and flag anything new.
Veracly does exactly this — a free baseline scan, then continuous monitoring with a diff alert when a new tracker appears. Run a scan and see your site as a regulator would see it.
See also: What is a cookie banner audit? · Tracking pixel audit: GDPR & ePrivacy · What is a website compliance audit?
Common questions
What is a GDPR cookie audit?
A GDPR cookie audit is a structured check of your site to verify that consent is captured before any non-essential cookie or tracker is set. It captures network traffic on the very first page load, inspects every cookie and storage write, and compares the inventory to your published cookie policy.
Which cookies need consent?
Strictly necessary cookies (session, security, load balancing, remembering consent itself) do not need consent. Everything else does — analytics, advertising, personalisation, A/B testing, session recording, and any third-party widget that sets cookies on its own.
Is Google Analytics 4 GDPR compliant by default?
No. GA4 still requires explicit consent in the EU before any data leaves the browser, and the data should be IP-anonymised and configured for EU storage where available. Several EU regulators (CNIL, Datatilsynet, the Italian Garante) have ruled specific GA4 configurations unlawful.
What is the fine for a non-compliant cookie banner?
Fines vary. The CNIL has issued €60M (Google), €40M (Meta), and €600,000 (smaller controllers) for non-compliant banners. The principle is: the fine scales with revenue and the volume of affected visitors, not the egregiousness of the failure.
See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report — EAA, GDPR, ADA, UK Equality Act, AODA — with copy-paste developer fixes.
Run a free scan