Compliance drift: how a program that passed last year fails this year

A compliance program that was in good shape twelve months ago can quietly fail this year. Nothing dramatic has to happen. Ownership rotates. Systems migrate. A framework publishes a revision. A vendor changes its SOC 2 scope. A sister team launches a product in a new jurisdiction. Compliance programs rot quietly, at a rate that is almost imperceptible week-to-week and painfully obvious at the next audit. This article is a working model of compliance drift, the six forces that drive it at the program level (not just individual controls), and how to build an operating model that slows drift without freezing an organization that needs to keep moving.

Control drift vs. compliance drift

Control drift is what happens to a single control when its environment changes underneath it. A control for weekly access reviews drifts when the review owner leaves and nobody takes over. Compliance drift is what happens to a whole program when the forces acting on it accumulate. Compliance drift is not the sum of control drift; it is the delta between what your program says it is doing and what an external observer would conclude from the state of the world. You can have a program where every individual control is still operating and the program as a whole is drifting — because scope has quietly changed, or a framework revision has quietly raised the bar, or a new regulator has started caring about an area that used to be ignored. Compliance drift is structural.

The six forces behind compliance drift

First: framework revision. SOC 2 criteria are updated. ISO 27001 Annex A changes. PCI v4.0 future-dated requirements come into force. A program calibrated against the old version is quietly out of compliance the day the new version applies. Second: scope expansion. A new product, a new region, a new customer segment adds systems or data to the in-scope perimeter — and the program owner is not always told. Third: ownership turnover. A control owner leaves. The control is re-assigned to someone who inherited a title but not the context. Fourth: vendor change. A critical vendor changes its SOC 2 scope, issues a qualified report, or discontinues a service you were relying on. Fifth: regulatory mood. A regulator starts caring about an area — for example, third-party risk — that used to be tolerated at a lower level. Sixth: organizational change. A reorg breaks the chain of accountability that held the program together. No single force is catastrophic. In combination, they are.

Detecting drift before the auditor does

The detection strategy has to match the failure mode. For framework revision, subscribe to the standards body's publication channels and run a diff against your current control library every time a revision is published. For scope expansion, reconcile your in-scope inventory against your product taxonomy on a published cadence — monthly is tight, quarterly is minimum. For ownership turnover, tie control ownership to a role, not a person, and run a monthly check that every role has a current occupant. For vendor change, run a quarterly vendor-report review that reads every significant vendor's latest attestation for changes in scope, qualifications, or CUEC (complementary user entity controls). For regulatory mood, maintain a register of enforcement actions and regulatory guidance notes in your jurisdictions and review it quarterly. For organizational change, treat every reorg as a compliance event and walk the control library against the new org chart within two weeks of the change taking effect.

The operating model that slows drift

Programs that resist drift share a small number of operating features. Controls are versioned. When a control changes — definition, owner, cadence, evidence pattern — the change is recorded with a reason and the old version is preserved. Populations are reconciled on cadence. The in-scope systems, accounts, and vendors are checked against the source of truth at a published frequency, not inferred from whoever remembers. Ownership is role-based, not person-based. Cross-framework mapping is maintained as data, not as a static spreadsheet. And — most important — the program runs a light quarterly review of its own state as if it were a first-party audit, with findings and remediation plans written to the same standard as an external audit. The first time you do this, you will find things. That is the point.

The quarterly drift review, in one page

Every quarter, answer four questions. Has the scope of our program changed in any way we did not plan? Has any framework we are certified against published a revision we have not digested? Has any critical vendor changed its posture in a way that affects our own? Have any of our control owners changed, and has the new owner been walked through the control? The answers to these four questions take four hours if you are disciplined. If any of them surface a finding, remediate it in-quarter. If you cannot, log it as a program risk and raise it at the next steering committee. The goal is not to be drift-free. The goal is to make drift visible before it becomes a finding.

Tags