The banner appeared. The visitor ignored it for four seconds, then clicked Reject. An entirely legitimate interaction — and yet, if you inspect the network tab during those four seconds on the majority of sites running a standard consent management platform, you will see requests already sent to advertising networks, analytics endpoints, and retargeting pixels. The rejection arrived too late. The data left first.
This is the pre-consent execution gap, and it is the most common technical failure mode in GDPR and ePrivacy Directive compliance. The regulation requires that non-essential tracking only begins after a valid, freely-given, specific consent signal. But most CMPs are architecturally built to record consent decisions, not to script execution. Those are fundamentally different products doing fundamentally different jobs.
Why Standard CMPs Don't Block — They Record
A typical consent management platform works through a callback model. The CMP loads, renders the banner, and registers an event listener. When the visitor clicks Accept, the callback fires and sets a cookie like consent_analytics=true. Any script that checks for that cookie before running will respect the consent flow. The problem is that the word "any" is doing enormous work in that sentence.
Tag managers — GTM being the dominant example — load their own container script early in the page lifecycle. That container may include dozens of third-party tags configured to fire on all pages, or on specific triggers. The consent signal from the CMP is one input among many, and only if the tag configuration has been explicitly written to check that input will the tag wait. In practice, many GTM setups are not written that way. A tag added by a marketing analyst three years ago for a campaign that ended may still be firing on every page load, pre-consent, because no one configured the consent check on it.
This is not a GTM-specific problem. Any script injected via <script> tags in your site's HTML, or loaded through a third-party library that initializes on DOM ready, runs before the CMP has had any chance to render, let alone receive a consent decision.
What the Intercept Layer Actually Does
A pre-consent blocking architecture inverts the default assumption. Instead of "scripts run unless consent is explicitly denied," the model becomes "scripts are held in a queue until an explicit positive decision is recorded." The mechanics look roughly like this:
The consent script is the first thing to load — injected in the <head> before any tag manager or analytics snippet. It intercepts calls to browser APIs that trackers rely on: it wraps document.cookie writes, intercepts XMLHttpRequest and fetch calls to known third-party domains, and queues any <script> injection attempts from tag managers until a consent signal arrives. When the visitor makes a choice, the queue either executes (Accept) or is discarded (Reject).
The technical implementation requires careful handling of first-party versus third-party scope. Blocking all cookie writes would break your own session management and authentication. The intercept layer needs a category classification — analytics cookies, advertising cookies, functional cookies — and rules for which categories require consent. First-party strictly necessary cookies are exempted. Third-party analytics domains are held. This is exactly the cookie categorization that GDPR's consent requirements imply.
A Concrete Scenario: The GTM Tag That Kept Firing
Consider a mid-size e-commerce company with EU traffic — around 35% of monthly sessions from Germany, France, and the Netherlands. The legal team had deployed a consent banner and assumed coverage. An internal audit in early 2024 revealed that a retargeting pixel, added to GTM during a paid acquisition campaign the previous year, had no consent trigger configured. The campaign had ended; the tag had not. For over eight months, that pixel was receiving pre-consent pageview data from every EU visitor who ever loaded the homepage before making a consent choice — which, for a banner that renders in 600–800ms, is every EU visitor.
The fix required two things: a proper consent trigger on the GTM tag, and a script intercept at the network layer to catch anything that slipped through GTM configuration in the future. The first fix addressed the known tag. The second addressed the unknown ones — tags that might be added next month by a different analyst, with the same configuration gap.
This is where the CMP-only approach shows its limits. A CMP that records consent but does not intercept at the execution layer is only as good as the diligence of whoever configures the tags. And that diligence fails, routinely, in organizations with multiple teams contributing to the tag manager.
The Nuance: Blocking Is Not Binary
We are not saying that every script must be blocked until consent. Strictly necessary scripts — those required for the site to function — are exempt from GDPR's consent requirement under Article 6(1)(b) (contractual necessity) or Article 6(1)(f) (legitimate interests for security and fraud prevention). Session management, shopping cart persistence, authentication tokens — these do not require an Accept click.
The category question is where the real work lives. "Functional" cookies are a contested boundary; some DPAs interpret functionality broadly, others narrowly. Marketing and analytics are clearer: they require explicit consent under both GDPR and the ePrivacy Directive as implemented across EU member states. A sensible pre-consent blocking implementation holds marketing and analytics by default, allows strictly necessary by default, and gives you configuration control over functional.
The Global Privacy Control (GPC) signal adds another layer. Under CCPA and increasingly under EU interpretations, a browser-level GPC signal indicating opt-out should be treated as a consent withdrawal. An intercept layer that only checks banner clicks will miss GPC-initiated opt-outs entirely. Proper handling requires reading the Sec-GPC header on the server side, or checking navigator.globalPrivacyControl in JavaScript before the tag queue executes.
What Auditors Look For
When a Data Protection Authority investigates a GDPR complaint about pre-consent tracking, the technical evidence they examine is fairly consistent. They look at network logs showing outbound requests to third-party domains timestamped before any consent record exists. They compare those timestamps against your consent log timestamps for the same visitor session. If data left before consent arrived, the lawful basis claim fails.
This means your audit log needs to capture more than just "visitor X clicked Accept at time T." It needs to capture: what banner version was shown, when the banner rendered (not just when it was clicked), and — critically — whether any scripts fired during the interval between page load and the consent decision. A consent log without script execution telemetry cannot demonstrate pre-consent blocking; it can only demonstrate that a banner existed.
The gap between "we have a consent banner" and "we can prove nothing fired before that banner was answered" is exactly the gap that turns a regulatory inquiry into a fine. Closing it is a technical problem, not a legal one — but the legal team typically discovers it only after the inquiry has already started.
This article is for educational purposes only and does not constitute legal advice. Consult qualified legal counsel for guidance on your specific compliance obligations.