Free scan
Post-audit drift · troubleshooting

Your tracking changed after the audit

The audit said clean. Months later there are third-party domains in the network tab that weren't in the report. Nothing failed — this is just what tracking stacks do over time, and it's why a one-time audit has a shelf life.

What it looks like

Compare today's network tab against the evidence in your audit report (or your last clean scan). The tell is new third-party domains that appear nowhere in the audit: an ad pixel that wasn't there, a chat vendor you don't remember approving, a recorder script, new cookies in Application → Cookies. The site looks identical; the request log doesn't.

This is drift, not a broken fix. Tracking stacks change through channels that never touch your code review — and each ungated addition quietly reopens the gap the audit closed.

DevTools → Network — fresh incognito, banner untouched:
audit report (March): 0 pre-consent trackers ← clean bill of health
GET analytics.tiktok.com/i18n/pixel/events.js ← …new since the audit
GET www.clarity.ms/tag/abcdefg ← …also new, nobody remembers adding it

Not sure what's firing on your site? See every pre-consent tracker — free, 30 seconds.

Real browser scan, no signup to run it. You see a summary of the findings; the full report with every tracker unlocks with your email.

Why it happens

1. Someone published a new GTM tag

Tag Manager edits ship instantly with no code deploy and no review gate. A marketer or agency adds a campaign pixel, hits publish, and the site's tracking posture changes the same minute — outside any process your audit covered.

2. A plugin, theme, or app update re-injected a tracker

Platform updates re-add snippets you removed or ship new integrations enabled by default. Shopify apps and WordPress plugins are the classic vector: an update adds "helpful" analytics, ungated.

3. A new integration trial brought its own scripts

Someone trialed a chat widget, an A/B-testing tool, or a new ads channel. The trial's script tag stayed — and it was never routed through the consent setup because it never went through the tag process.

4. Tag piggybacking

One approved tag loads others. Ad tags in particular can chain-load additional vendors, so the network log grows without anyone adding anything directly.

The risk context

California's Invasion of Privacy Act (CIPA), Penal Code § 631, prohibits intercepting a communication without the consent of all parties. Since 2022, plaintiff firms have applied that decades-old wiretapping statute to websites — arguing that new trackers transmitting visitor data before consent — on a site that had already been fixed before the visitor consents is an intercepted communication. Statutory damages under § 637.2 run up to $5,000 per violation, and plaintiffs argue each affected visitor session is a separate count, which is why even small sites receive demand letters. Similar all-party-consent statutes in Pennsylvania (WESCA), Florida (FSCA), and Massachusetts have produced parallel filings.

The timing math is what makes drift expensive: plaintiffs argue each affected visitor session is a separate violation, so exposure re-accrues from the day the new tracker appeared — your audit date doesn't stop the meter. The flip side is that dated evidence works for you too: a documented clean scan, a dated detection of the new tag, and a prompt fix is a strong good-faith record.

To be precise about what a network log can tell you: a tracker firing before consent is a technical finding — it establishes when a script transmitted data, not whether any law was broken. But timing is exactly what these claims are built on, which is why fixing the timing is the practical response.

How to fix it

  1. Re-scan now and diff against the audit: list every third-party domain in today's network log that isn't in the report. That delta is your work queue.
  2. Gate or remove each addition the same way the audit fixes did — consent requirements in GTM, CMP-managed snippets, or deletion for tools nobody claims.
  3. Put change control on GTM: use workspaces and versions, restrict publish rights, and make consent settings a required field of every new tag's review.
  4. Restrict who can install plugins/apps, and add "does it inject scripts?" to the approval question for every new integration.
  5. Close the loop with continuous monitoring: scheduled re-scans that email you the moment a new tracker appears turn drift from a silent liability into a same-week ticket. That's the gap RegSentry monitoring exists to cover.

Verify the fix in 30 seconds — free re-scan, no signup.

Real browser scan, no signup to run it. You see a summary of the findings; the full report with every tracker unlocks with your email.

Common questions

Why does my site have new trackers after a compliance audit?

Tracking stacks change through channels that bypass code review: GTM tags publish instantly, plugin and app updates re-inject or add snippets, new integration trials leave their scripts behind, and existing tags can chain-load additional vendors. None of that requires touching your codebase, so an audit's findings age from the day it's delivered.

Does a past audit protect me if a new tracker appears?

A past audit documents that the site was clean on that date — useful evidence of good faith. But pre-consent tracking claims are argued per visitor session going forward, so a new ungated tracker starts accruing new sessions from the day it appears regardless of the audit. Prompt detection and a dated fix are what keep the record strong. Not legal advice.

How do I catch new trackers before they become a problem?

Diff every deploy-day network log against your last clean scan, or automate it: RegSentry re-scans your site on a schedule and emails you the moment a new tracker appears, with the evidence and the fix for each one.

Related

Monitoring plansThe state of website tracking (report)Consent banner not blocking trackersHow the scan works
Monitor my site ($99/mo) Estimate my exposure