Control Drift: How a Passing Programme Quietly Stops Working

Direct answer: Control drift is the gap that opens between what your system description says you do and what your company actually does. It is almost always caused by ordinary change: someone leaves, a tool is replaced, a process is streamlined, a noisy alert gets muted. Drift is invisible while it is happening and expensive when it surfaces, because evidence is dated and you cannot retroactively operate a control. Catching it takes a monthly check against the description, not a tool.

What drift actually looks like

It is rarely a decision. Nobody sits in a meeting and agrees to stop doing access reviews. The person who ran them moves to a different team, their replacement never inherits the calendar entry, and two quarters pass before anyone asks.

The patterns repeat across almost every programme we see. The reviewer leaves and the review leaves with them. A vulnerability scanner gets migrated and the new one is not configured to cover the same estate. An alert becomes noisy, gets muted for a sprint, and stays muted. A new cloud account gets spun up for a project and is never brought into scope. The policy set hits its annual review date during a crunch and slides by four months. A subprocessor is added because a team needed a tool, and the vendor register does not hear about it.

None of these are security failures on their own. All of them break a control you told an auditor you operate.

Why it costs so much later

Compliance evidence is dated by nature. A Type II attests that controls operated across a period, so a control that stopped in month three cannot be repaired in month twelve by starting it again. The record for those months does not exist and cannot be created honestly.

What follows is a choice between two bad options. You disclose the gap, and it becomes an exception in the report, which your enterprise buyers will read. Or the observation window moves so the period covers only the time the control was operating, which pushes your report date, which is usually the thing the whole programme exists to protect.

For ISO 27001 the equivalent is a nonconformity at the surveillance visit, with a corrective action, a root cause and evidence of effectiveness required before it closes.

The three places drift starts

People. Controls attached to a person rather than a role die when that person changes jobs. The fix is naming roles in the description and keeping a mapping of role to person that gets checked when anyone leaves.

Tools. Every tool migration is a drift event. The old thing produced evidence in a shape somebody understood, the new one does not, and the gap is discovered during fieldwork. Any change to identity, cloud, endpoint, ticketing, or code hosting deserves a check against the controls that depend on it.

Growth. New environments, new products, new regions, new subprocessors. Each one is a scope question, and the answer takes ten minutes at the time and a week during an audit.

Catching it

The check that works is boring and monthly. Take the control list, and for each one ask whether it produced evidence this month, and whether that evidence is filed. Not whether the control exists. Whether it produced something dated.

Three signals are worth watching specifically. A control with no new evidence in two consecutive months, which almost always means it stopped. Evidence that arrives but is thinner than the previous period, which usually means it is being produced under duress rather than by process. And any change ticket touching identity, cloud accounts, or vendors, each of which should trigger a scope check.

Automated monitoring platforms catch a real subset of this, specifically the technical configuration controls they integrate with. They do not catch the organisational ones, which is where most drift lives: the review that did not run, the vendor nobody assessed, the training that half the company skipped, the policy nobody re-approved.

What to do when you find it

Record it honestly, including the dates. A gap you documented with a start date, a cause and a fix is a very different conversation with an auditor than a gap they found in your evidence.

Then fix the cause rather than the instance. Running the missing access review is the instance. Making sure the next one happens without anyone remembering is the cause, and that usually means the control needs an owner by role, a calendar entry that survives the person, and somewhere the artefact lands automatically.

If the gap is material to the period, talk to your auditor early. Auditors deal with this constantly, and the outcome is much better when they hear it from you in month four than when they find it in month twelve.

The structural fix

Drift is a function of attention, and attention is exactly what a growing company runs out of between audits. The programme is not hard while somebody is looking at it. It stops the moment nobody is.

That is the whole argument for treating the year between reports as the programme rather than the gap between programmes, whether the attention comes from a named internal owner or from a retainer that operates the cadence. The test is simple: if you cannot name the person who will notice that last month's access review did not happen, it will not be noticed.

A worked example: the identity migration that ate four months

A thirty-person SaaS company moved from Google Workspace groups to Okta in month five of a twelve-month Type II observation window. The migration itself was competent. Groups were mapped, MFA was enforced, the old admin accounts were disabled within a fortnight. Nothing about the security posture got worse.

What broke was the evidence. The quarterly access review had been run out of a Google Admin export, and the reviewer had a saved query that produced a tidy list of users by group with last login dates. That query stopped returning anything meaningful once the source of truth moved. The reviewer, who was the head of engineering rather than a compliance owner, did what a busy engineer does: ran the review anyway from a Notion page that listed the production systems, ticked the names he recognised, and filed it. Two quarters later the auditor asked for the population the review was drawn from, and the honest answer was that nobody could reconstruct it. The review had happened. The population it covered could not be demonstrated to be complete.

That is the shape most drift takes. Not an absent control, a control whose output no longer proves what the description claims. Fixing it cost the company roughly three weeks of engineering attention, a re-run of two reviews under a corrected method, and a written explanation to the auditor about why the earlier two quarters were performed differently. The report shipped, with a note. The buyer who read that note asked one follow-up question, which the company answered in a paragraph. It was survivable, and it was entirely avoidable by spending twenty minutes during the migration asking which controls depended on the system being replaced.

Population completeness is where drift actually gets caught

Most people picture an audit as the auditor asking for an artefact and you handing it over. In practice the harder question comes first: prove that the list you sampled from is the whole list. If the control is quarterly access review of production systems, the auditor wants the system inventory the review covered, and wants to see that it matches reality for that quarter. If three new services went live in April and the April review covers the same eleven systems it covered in January, the control did not fail, but its coverage did, and the finding lands in the same place.

The same applies to onboarding and offboarding. Auditors typically pull the HR joiner and leaver list for the period from a system you do not control, then sample against it. If your offboarding tickets cover nineteen of the twenty-two departures because three contractors were terminated outside the HR system, that is a drift finding even though every one of those three had their access removed. The control was operated inconsistently, and inconsistency is the thing being tested.

The practical implication is that your monthly check should look at inputs, not just outputs. For each control, ask what population it draws from, where that population lives, and whether anything changed about that source in the last month. New cloud account, new HR system, new contractor arrangement, new repository host: each one shifts a population under a control that is still dutifully producing evidence about the old one.

Evidence that ages badly

Some artefacts hold up years later and some do not. A system-generated export with a timestamp, a defined query and the name of who ran it survives scrutiny. A screenshot of a dashboard does not, because it carries no date you cannot fake, no scope, and no way to reproduce it. A Slack message saying the review is done is weaker still.

The ranking matters because drift usually degrades evidence quality before it stops evidence entirely. The first quarter after the owner changes, the artefact is a clean export. The next quarter it is a spreadsheet someone typed. The quarter after that it is a screenshot. Nobody notices, because a folder with something in it looks like a folder with the right thing in it. Watching evidence quality is a leading indicator of an owner who is going through the motions, and going through the motions is the stage just before stopping.

Two cheap habits help. Store the artefact with the command or query that produced it, so the next person can regenerate it without inventing a method. And keep the reviewer's decisions, not just the reviewer's conclusion: a list where four accounts were flagged for removal and two were kept with a reason is far more credible than a list where every row is approved, because real reviews find things.

The change events that deserve a scope check

Rather than checking everything constantly, tie the check to events that reliably move things. Any change to the identity provider, cloud account structure, HR system, ticketing system, code hosting or endpoint management touches the plumbing under multiple controls at once. So does any new production region, any new product line with its own datastore, and any acquisition, however small.

People events matter as much. When anyone with a named control responsibility leaves or changes role, the handover should include the control list they owned and the artefacts they produced, and the receiving person should run the next cycle with someone watching. A control handover that consists of adding a name to a policy document has failed roughly half the time in our experience.

Vendors are the third trigger. New subprocessors get added by whoever needed the tool, usually on a company card, usually without telling anyone whose job includes a vendor register. The check that works here is not a policy asking people to notify you. It is a monthly look at the card statement and the SSO application list, comparing what is actually connected against what is registered.

What it costs to rebuild versus maintain

The maintenance cost of a compliance programme is genuinely small: for a company under about a hundred people, a handful of hours a month if the calendar and the artefact destinations already exist. The rebuild cost is not small, and it is not mostly consulting fees. It is engineering time pulled off product during fieldwork, at the least convenient point of the quarter, to reconstruct things that would have taken minutes to capture at the time.

The second cost is deal timing. A report that slips six weeks because the observation window had to move is six weeks of enterprise contracts sitting in procurement. The programme exists to unblock those contracts, and drift converts a maintenance problem into a revenue problem. When we quantify this for clients the engineering hours are usually the smaller number.

The third cost is credibility with the auditor. An auditor who has found two undisclosed gaps in your evidence samples harder in every subsequent area, because their own quality review requires them to. Sampling harder means more requests, more back and forth, and a longer fieldwork period. Being the client who flags problems early genuinely buys you a lighter touch, not because auditors go easy, but because the risk assessment they run on you drives how much they test.

When you should not buy a retainer for this

If you have one framework, fewer than about forty people, a stable toolset and one person whose job description explicitly includes the compliance calendar, you do not need us to operate your cadence. You need a shared calendar with the review dates on it, a folder structure where each control has a destination, and a fifteen minute monthly look down the list. That is a genuinely sufficient answer and plenty of companies run it for years without help.

Equally, if your problem is purely technical configuration monitoring, a compliance automation platform on its own may be the right purchase and the cheaper one. Those tools do the integration work properly. Our argument is not that they fail, it is that they cover the controls that are easy to instrument and leave the organisational ones, which is where the drift we get called about actually lives. Buying both a platform and a retainer makes sense at a certain size and is overkill below it.

The point at which outside help earns its cost is usually one of three: you have two or more frameworks with overlapping but non-identical evidence, your headcount is growing faster than about fifty per cent a year so the environment keeps moving underneath you, or the person who held the whole programme in their head has left. If none of those is true, keep your money, put the reviews in the calendar, and read the rest of this as a checklist rather than a pitch. If one of them is true, a retainer that operates the cadence is the cheaper answer, and our free Workspace will hold the control list and the evidence destinations either way.

If you have already drifted and fieldwork is four weeks out

Triage rather than panic. First, list every control in the description and mark each one as operating, degraded or stopped, with dates you can defend. Do this before you fix anything, because the dates are the thing you will be asked for and they get harder to reconstruct once people start remediating.

Second, separate gaps that are recoverable from gaps that are not. A policy that missed its annual review can be reviewed and approved now, with an honest note that the cycle slipped. A quarterly access review that did not happen in Q2 cannot be performed retroactively, and pretending otherwise is the one move that turns a manageable exception into a serious problem for both you and your auditor.

Third, take the recoverable list and the unrecoverable list to your auditor in the same conversation, along with the cause and the fix for each. Ask them directly which items they would treat as exceptions and which they would treat as scope adjustments. Auditors will usually tell you, because a client who arrives with a clear picture makes their job easier. Then spend the remaining weeks making sure the controls that are still operating produce clean, well-formed evidence, because the strength of the rest of the file affects how much weight the exceptions carry.