Control drift: what it is, why it happens, and how to catch it early

Control drift is the slow divergence between what a control is supposed to do and what it actually does. It is the reason most compliance findings feel like a surprise when they should not be. This article is a plain-language walk through what drift looks like, why it happens, and how to catch it before an auditor does.

Drift in one sentence

Control drift happens when the thing the control actually does stops matching the thing you wrote down it would do. The design and the implementation become two different things. Sometimes the design is out of date. Sometimes the implementation has quietly changed. Either way, the gap is what makes audits painful.

Five common causes

The first cause is operational change: a team changes the way it does something without updating the control document. The second is team turnover: the person who knew how the control worked leaves, and the person who takes over makes small, reasonable-looking changes that add up. The third is tooling change: the SaaS product the control depends on gets an update, a new default, or a renamed feature, and the control document no longer describes reality. The fourth is undocumented exceptions: a real, legitimate exception is made on a specific day, never written down, and then repeats. The fifth is scope creep: the control was designed for one system and then quietly started covering three, without anyone updating the design to reflect the expanded scope.

Detection strategies

Periodic walk-throughs are the oldest and still the most effective detection strategy. A structured quarterly walk-through with the control owner, comparing the written design against the current operation, catches most drift before it becomes a finding. Monitoring signals attached to the control catch drift in controls that are enforced in software — a control that says "MFA is required for production access" should have a monitoring signal that fires if MFA is disabled for any user. Automated diffs between prior and current configurations catch drift in configuration-backed controls. External testing — penetration tests, red teams, tabletop exercises — catch drift in controls whose effectiveness cannot be measured from inside the organization. And rejection feedback from auditors is unfortunately also a detection strategy, just an expensive one.

Writing a drift recovery runbook

When drift is detected, the response should not be a scramble. A drift recovery runbook is a short, structured document that tells the control owner what to do. It should cover: how to decide whether the design or the implementation is the one that needs to change; who approves the change; how to document it; how to backfill evidence for the period during which the drift existed; how to communicate the change to affected teams and auditors. A good runbook turns drift from a crisis into a process.

A worked example

An access review control says: "Every quarter, the system owner reviews all active access grants and removes unnecessary ones." Implementation reality: two quarters ago, the system owner's calendar invite for the review started being automatically declined because of a calendar permission change, nobody noticed, and the review has not happened since. Drift detected: a quarterly walk-through with the control owner in month nine reveals the gap. Recovery: the runbook says fix the calendar, run the missed reviews, document the gap and its cause, update the control description to require a backup calendar and an escalation if the primary review is missed, and brief the external auditor during the next engagement. The finding, if any, is a two-line note instead of a multi-page observation.

Tags