A website that passed its compliance review in January rarely fails the same way in September – it fails quietly, one small change at a time. That gradual erosion is what practitioners call compliance drift, and it’s one of the least understood risks in website governance because nothing “breaks” in the way a 500 error breaks. The cookie banner still loads. The privacy policy link still resolves. But underneath, the actual state of the site has moved away from what was certified, approved, or documented six months earlier.
What compliance drift actually looks like in practice
Drift isn’t a single event. It’s an accumulation of small, individually defensible changes that nobody re-checked against the compliance baseline.
A marketing team swaps the analytics tag manager container in March. A developer adds a new font-loading CDN in May because the design team wanted variable fonts. Someone migrates the contact form to a new SaaS provider in July to fix spam issues. Each change gets code review, maybe a QA pass, maybe a quick “does the page still look right” check. None of them get run through a compliance lens, because compliance isn’t in anyone’s definition of “done” for that ticket.
Six months later the site is loading four new third-party scripts that weren’t in the original cookie consent categorization, the CSP header hasn’t been updated to reflect the new script origins, and the privacy policy still lists a subprocessor that was dropped in April while omitting the one added in July. None of this was a deliberate decision. It’s the compounding effect of dozens of unrelated, reasonable changes.
Why drift is structurally different from a one-time gap
A compliance gap found during a launch audit is a known unknown – you go looking for it. Drift is an unknown unknown, because the last time anyone verified the site’s state was the audit date, and every deploy since then is unverified territory.
This matters for how organizations plan around it. A pre-launch compliance checklist catches the state of the site at time zero. It says nothing about the state of the site at day 220. GRC teams that treat the launch audit as the compliance milestone, rather than as the starting point of an ongoing obligation, are the ones most exposed to drift, because their assumption is that “we checked this” remains true indefinitely.
The mechanisms that cause drift
Drift accumulates through a handful of repeatable patterns:
Script sprawl – third-party tags get added by marketing, sales ops, or a growth team without a corresponding update to the cookie consent categorization or the CSP header allowlist. A Google Tag Manager container can silently pull in a new pixel with zero code review, because GTM changes don’t go through the same deploy pipeline as the codebase.
Subprocessor churn – vendors get swapped (a support widget moving from Intercom to Zendesk, an email provider migration from Mailchimp to Klaviyo) and the privacy policy’s subprocessor list isn’t updated in lockstep, sometimes for months.
Certificate and infrastructure changes – a CDN migration or a new load balancer configuration can quietly change TLS cipher suites or drop a security header like Strict-Transport-Security that was previously set at the edge.
CMS and plugin auto-updates – a WordPress plugin update changes how it injects cookies, or a theme update strips a custom accessibility statement widget from the footer template.
Regional expansion without policy updates – a site starts serving traffic to a new country (often just by ranking well in search, not by intent) and the existing privacy policy or consent flow never gets adapted for that jurisdiction’s rules.
The myth that a passed audit means ongoing compliance
The common misconception is that compliance is a state you achieve, like getting a certificate. In reality, under GDPR, CCPA, and most modern frameworks, compliance is a continuous obligation tied to the site’s current behavior, not its behavior on the day someone last checked. A GDPR audit from January 2025 provides zero legal protection for a data leak caused by a tracking pixel added in June 2025. Regulators and plaintiffs’ attorneys look at the state of the site at the time of the alleged violation, not at the state of your most recent audit report.
This is also why a single annual audit, however thorough, structurally cannot prevent drift – it can only measure how much has already accumulated since the last one. Organizations that rely solely on that cadence often discover the gap only when a user complaint, a data subject access request, or a regulator inquiry forces a fresh look.
How to detect drift before it becomes a finding
A seasoned GRC lead doesn’t wait for the annual audit to reveal drift; they build detection into the change process itself.
Start by establishing a baseline snapshot: what scripts load, what cookies get set before and after consent, what security headers are present, what the privacy policy’s subprocessor list says, and where the accessibility statement lives. Document this at a specific point in time – not “current state” as a vague concept, but a dated record you can diff against later.
From there, the practical approach is comparing that baseline against the live site on a recurring basis rather than a calendar-driven one, since drift doesn’t happen on a schedule – it happens on every deploy, every plugin update, every new vendor integration. Continuous monitoring that checks cookie behavior, header configuration, SSL certificate status, and document availability catches the individual changes as they happen, rather than the compounded mess six months later. This is the same principle behind catching compliance issues before customers do – the earlier a single script addition is flagged, the cheaper it is to fix, both in engineering time and in regulatory exposure.
Common mistakes that accelerate drift
A few patterns show up repeatedly in organizations that get burned by drift:
Treating the compliance audit as a project milestone rather than a recurring process – once the checkbox is ticked for a launch or a funding round’s due diligence, nobody schedules the next check.
Trusting that marketing and dev teams will “flag it if something changes” – they won’t, not because of negligence, but because compliance categorization isn’t part of their workflow or their tooling. A developer adding a CDN doesn’t think in terms of “does this affect our CSP compliance posture.”
Measuring the wrong signal – checking that the cookie banner visually appears, without verifying that declining consent actually blocks the scripts from firing. A banner that looks correct but doesn’t functionally block tracking is a common source of drift that survives visual QA indefinitely.
FAQ
How often should a site be re-checked for compliance drift?
There’s no single universal interval, but relying on an annual or even quarterly manual audit leaves months of unverified exposure. Sites with frequent deploys, multiple marketing teams adding tags, or active vendor changes benefit from continuous or near-daily automated checks rather than a fixed calendar cadence.
Is compliance drift only a GDPR issue?
No. It applies equally to CCPA, accessibility requirements like WCAG conformance referenced in an accessibility statement, and security-adjacent obligations tied to SSL and header configuration. Any regulatory framework that requires an ongoing state, rather than a one-time disclosure, is vulnerable to drift.
Can drift happen even without any code changes?
Yes. A vendor can change its own script behavior, a CDN can rotate certificates, or a regulation itself can be amended, shifting what “compliant” means for a site that hasn’t changed at all. Drift isn’t only caused by your own deploys.
Drift is rarely dramatic. It’s a subprocessor that changed in April, a script added in June, and a header dropped during a CDN migration in August, none of which triggered a review on their own. The fix isn’t a bigger annual audit – it’s shortening the gap between when something changes on the site and when someone, or something, notices.