Your consent banner says everything is under control. Your tag manager shows a tidy list of vendors. And yet, when someone renders your homepage in a real browser and watches the network traffic, hosts appear that nobody declared, firing before consent, or after a user said no. This gap between what your consent stack reports and what a page actually loads is where most cookie enforcement risk now lives.
Why the CMP view is incomplete
A Consent Management Platform (CMP) governs the tags it knows about. It reads a vendor list, blocks or allows scripts based on the user's choice, and writes a consent string. That is genuinely useful, but it only covers declared inventory. Three blind spots recur:
- Piggybacked tags. A declared vendor loads a second vendor, which loads a third. Your CMP sees the first hop and misses the chain. Ad tech and social pixels are notorious for this.
- Hardcoded scripts. A marketing team pastes a snippet straight into the template, bypassing the tag manager entirely. The CMP never receives a signal for it.
- Server-side and consent-mode gaps. With server-side Google Tag Manager and Consent Mode, tags can still send signals in a cookieless or reduced form. Whether that is lawful depends on configuration, and the CMP dashboard rarely tells you what actually left the browser.
The result: a register that looks complete on paper and a live page that behaves differently.
What Article 5(3) actually requires
The legal test is not "did the CMP fire correctly." Under Article 5(3) of the ePrivacy Directive, reading or writing information on a user's device requires prior consent, with narrow exemptions for strictly necessary storage. Regulators read this literally. It applies to any access to the terminal, not only to cookies labelled as such, which is why pixels, local storage, and fingerprinting scripts are all in scope.
Enforcement has followed. In September 2025 the CNIL fined Google 325 million euros in a decision that turned in part on ePrivacy and cookie practices, one of several actions signalling that regulators will look at behaviour on the page, not just the wording of a policy. See the EDPB summary and the CNIL announcement.
The practical takeaway: a supervisory authority can open a browser, load your site, and check what fires before consent. If an undeclared tracker appears, "the CMP was configured correctly" is not a defence.
What a real-browser scan reveals
A real-browser scan does what a static audit and a CMP dashboard cannot: it renders the page the way a visitor's machine would, executes the JavaScript, and records the full network waterfall. That surfaces the things a declared inventory hides.
| Signal | What it tells you |
|---|---|
| Hosts contacted before any consent choice | Tags firing without a legal basis |
| Hosts not in your vendor register | Undeclared or piggybacked third parties |
| Cookies and storage keys written | Access to the terminal under Article 5(3) |
| Requests after an explicit "reject" | A CMP that fails to block in practice |
The scan answers a simple, awkward question that governance documents cannot: when a person actually visits, what leaves their browser, and to whom?
Turning a scan into a repeatable control
A one-off scan finds today's problems. Third-party inventories drift constantly, because marketing adds tags, vendors change their own dependencies, and A/B tests inject scripts on some sessions and not others. So the useful posture is continuous, not annual.
A workable process looks like this:
- Maintain a declared vendor register: the hosts you have assessed and can justify.
- Render key pages in a real browser on a schedule, capturing every host contacted.
- Diff the observed hosts against the register.
- Raise an alert the moment an undeclared host ships, and route it to whoever owns that page.
- Keep the evidence, so you can show a regulator both the state and the date it changed.
The point is to move detection ahead of the complaint. You want to learn about a rogue tag from your own monitoring, not from a supervisory authority's screenshot.
A note on tooling
This is the gap Seqlense's GDPR monitoring is built to close. It renders live pages in a real browser, captures the full network waterfall, matches every detected host against your declared vendor register, and raises a drift alert when an undeclared tag ships. Instead of trusting that the CMP reflects reality, you observe reality directly and get told when it diverges. For DPOs and privacy teams, that turns third-party monitoring from a periodic manual audit into a standing control with an audit trail.
None of this replaces good consent design or a well-configured CMP. It checks them. The consent banner tells you what should happen. A real-browser scan tells you what did.