Consent Compliance Drifts. That’s Why It Isn’t a One-Time Fix.

There is a tidy version of this story where you fix your consent setup once and the matter is closed. It is an appealing story and it is not true, for a reason that has nothing to do with anyone being careless.

A consent configuration is a statement about a website at a particular moment: these are the scripts that run, this is the category each belongs to, this is what happens when someone declines. Websites do not hold still. Every change to the site is a change to the thing the configuration describes, and the configuration does not update itself.

So a site that was correct in March can be wrong by June without a single mistake having been made. Here is how that happens.

Marketing adds a tag

This is the most common path by a wide margin, and it is the one hardest to police with process.

A campaign launches on a platform you have not used before. The platform supplies a pixel. Someone adds it through the tag manager, which is exactly what tag managers are for and exactly what that person was hired to do. The campaign performs, everyone is pleased, and a new third-party tracker is now firing on every page in a category that does not exist in your consent configuration — which means it is ungated.

You can try to solve this with policy: nobody adds a tag without review. In practice that policy holds for a few months and then a campaign has a deadline. It is a better idea to assume tags will be added and to detect them quickly than to assume they won’t.

A plugin update adds something

A plugin you have run for years ships an update that introduces analytics, a support widget, or a phone-home for telemetry. You apply the update, the site works, you move on.

Nothing about this is visible. There is no notification and no symptom. The only way to catch it is to compare what the site loads this month against what it loaded last month.

A vendor changes what its script does

Subtler again. The script tag on your page is unchanged, but the code it fetches is served from the vendor’s infrastructure and they can alter it whenever they like. A chat widget adds visitor analytics. An A/B testing tool starts writing an additional identifier. A tool you categorized accurately in the spring is doing something different by autumn, from the same URL.

Your configuration is now describing behavior that no longer matches reality, and nothing on your end changed at all.

Someone builds a new page

A landing page goes up for a product launch, built quickly, possibly by an outside agency, possibly with a tracking snippet pasted directly into the page rather than routed through your tag manager.

Scripts added this way bypass consent gating entirely, because your consent platform only controls what it knows about. The page is live, it converts well, and it is the one page on the site where nothing is being blocked.

The rules change underneath you

The regulatory floor keeps moving. New state laws have taken effect each January for several years running, with more enacted and phasing in. Existing laws get amended. Requirements that were recommended practice become mandatory — the obligation to honor browser-level opt-out signals has spread state by state rather than arriving all at once.

Ad platforms move too, and on their own schedule. Google’s consent signal requirements for European traffic arrived with a deadline and consequences for measurement. That kind of change lands regardless of whether anyone has complained about your site.

Why this is hard to catch internally

Every failure above shares a property: the site keeps working perfectly.

Nothing breaks. No error appears. Pages load, forms submit, conversions record. The banner still shows up and still looks right. There is no moment where anybody has a reason to look.

Compare that to a broken checkout, which announces itself within the hour. Consent drift has no equivalent alarm. It is found either because someone deliberately goes looking, or because an outside party looks first — and the outside parties who look at this are demand letter firms running automated scans across thousands of sites, which is a considerably worse way to find out.

What ongoing actually means

The work is not large, but it does have to be repeated, and it has to be repeated by something other than human memory.

• Re-scan on a schedule. Monthly, automatically, across representative pages rather than just the homepage. Load the site as a fresh visitor and record everything that fires before consent.
• Compare against the last scan. The useful output is the diff. A new domain appearing in this month’s results that was not in last month’s is the entire signal.
• Re-run the reject test. Blocking rules can be broken by a platform update as easily as by a new script.
• Categorize and gate what’s new — quickly, so the window where something is ungated stays short.
• Track the regulatory floor so a new requirement becomes a configuration change rather than a surprise.

The point of doing this monthly is not that something changes every month. Most months nothing does. The point is that when something does change, you find out in weeks rather than in a letter.

Getting a site correctly configured is a project with an end. Keeping it that way is a maintenance function, in the same category as backups and security updates — unglamorous, largely uneventful, and noticeable only in its absence.

We’re not attorneys and this isn’t legal advice. We handle the technical side: making sure what’s on your site does what you think it does.

---

Find out what your site is actually loading

We’ll run the audit and show you what fires before anyone clicks accept — then re-scan every month and fix what shows up.