Nobody on your team decided to start sending visitor data to a new US analytics endpoint last night. And yet, this morning, it is happening. A vendor pushed a minor version bump to an SDK you already trust, the bundle now loads an extra host, and personal data is leaving your site to a recipient nobody declared. This is drift, and it is one of the most common ways a compliant website quietly turns into a GDPR problem.
Why a "minor" update is a data protection event
Most tags on a modern site are loaded dynamically. You embed a script from a tag manager, a consent tool, an analytics provider or a chat widget, and that script decides at runtime what else to fetch. You control the first hop. You do not control the second, third and fourth.
When a vendor ships a new SDK version, any of the following can change without a single line of your own code moving:
- A new sub-processor or CDN host starts receiving requests.
- An existing tag begins firing before consent instead of after it.
- The payload grows to include an identifier, a full URL with query parameters, or client hints.
- A pixel that was dormant is switched on by a server-side flag.
Each of these can turn a lawful setup into an unlawful one. The transfer of data to an undeclared recipient, or the loading of a tracker before the user has consented, is exactly the kind of processing that regulators have already acted on. The French CNIL, for example, has repeatedly found that the standard use of one popular analytics tool resulted in unlawful transfers of personal data to the United States, ordering site operators to bring their configuration into compliance. The tool did not change what it fundamentally did. The legal exposure came from where the data went and on what basis.
The gap between your register and reality
Compliance teams document the intended state. You keep a record of processing activities, a vendor register, a data map and a consent configuration. These describe what is supposed to happen.
The browser executes the actual state. What ships to a real user on a real page, after all scripts have resolved their dependencies, is frequently a superset of what the register describes. The distance between those two is where breaches hide.
Drift is dangerous precisely because it is silent:
- There is no deploy on your side, so no change review is triggered.
- The vendor's release notes rarely mention new hosts or changed timing.
- A manual review is a snapshot; the tag may behave differently tomorrow.
- The extra request often only fires under specific conditions (a certain geography, a logged-in state, an A/B bucket), so casual testing misses it.
By the time the undeclared tag surfaces, it may have been collecting data for weeks.
What a "rogue tag" actually looks like
A rogue tag is not usually malicious. It is a legitimate script doing slightly more than you authorised. Common shapes:
- A new host. The declared vendor is
analytics.example.com, but the SDK now also callscollect.example-cdn.net, which is not in your register. - A consent bypass. A tag that your consent management platform is supposed to gate now loads directly from the page, before any choice is recorded.
- A widened payload. The same host receives more than before: the referrer, the page URL with personal data in the path, or a persistent identifier.
Any of these can meet the definition of a personal data breach or an unlawful processing operation, depending on the data involved.
Catch it before the complaint, not after
The 72-hour clock in Article 33 of the GDPR starts when you become aware of a breach, not when it began. That framing rewards teams who can detect drift quickly and punishes those who learn about it from a complaint or a supervisory authority. Continuous, evidence-based monitoring is the difference between a controlled fix and a notifiable incident.
A practical control loop looks like this:
- Render, do not guess. Load your real pages in a real browser so dynamically injected tags actually execute.
- Capture the full waterfall. Record every network request, every host contacted, and the timing relative to the consent event.
- Match against a declared register. Compare each observed host to your authorised vendor list.
- Alert on the delta. When an undeclared host appears, or a gated tag fires before consent, raise it immediately with the evidence attached.
- Keep the trail. Store the before-and-after so you can show a regulator exactly what changed and when you caught it.
This is the model behind Seqlense GDPR: 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. The point is not to add another dashboard. It is to shrink the window between "the vendor changed something" and "we know about it" from weeks to hours, so the story you tell is one of a control that worked rather than a breach you missed.
The takeaway
You cannot freeze the third-party code your site depends on, and you should not pretend your register reflects live behaviour by default. Treat every tag as a moving part. Watch the actual network traffic, compare it to what you declared, and make undeclared drift a signal you receive rather than a fact you discover in an inbox complaint. A silent SDK update only becomes a GDPR breach when nobody is watching the wire.