The Risk Hiding Between Audit Cycles

Then the environment around the control changes. A key system is upgraded. A process is redesigned or streamlined. A new product launches. Responsibilities shift to another team. A regulation changes. Increasingly, AI is being introduced into business processes. Even a workaround that was intended to be temporary can eventually become part of the regular process.

The control may still exist. It may even look the same in the policy or procedure. But the environment around it is no longer the same. That is where control drift can begin.

Control drift does not necessarily mean a control suddenly fails. In many cases, it happens gradually. The control continues to operate, but the business process around it changes. Over time, the control may no longer address the underlying risk in quite the same way it did when it was originally designed and tested.

Consider a payment process. During the audit, everything lines up: walkthroughs, documentation, sample testing, discussions with management, and reporting. The conclusion is that the control is designed and operating effectively. A few months later, the payment system is enhanced to improve efficiency or the process is optimized. The change doesn’t look like a major control redesign. But one step in the workflow is now handled differently. The documented control is still there. The control owner still believes it’s functioning as intended. Nothing is flagged as a failure. But the process has changed — and that matters.

The original audit conclusion wasn’t necessarily wrong. It reflected the process and control environment that existed when the audit was performed. The real question is what happened after the auditors left.

This is the space between audit cycles — the part internal audit doesn’t always see. Internal audit can’t continuously test every control. That’s not practical, and it wouldn’t necessarily provide the most value. But some controls are more sensitive to change than others. Controls tied to technology, manual steps, key personnel, regulatory requirements, or complex workflows tend to drift faster because the conditions around them shift more often.

The conditions that can contribute to control drift are becoming more common, as businesses evolve to keep pace with changing markets, technologies, customer expectations, regulatory demands, and cost pressures. The increasing use of AI in business processes is another example. As organizations introduce new technologies, automate activities, redesign processes, or look for efficiencies, the environment in which controls operate can change quickly.

Change-management activity can be a helpful early signal. Taking note of new systems, redesigned processes, new products, reorganizations, and regulatory updates can help auditors understand where the control environment may have changed. Data monitoring can help too. Targeted analytics can highlight unusual patterns or changes in control performance that suggest something has moved since the last audit.

Management plays a role as well. When a significant system or process change occurs, reassessing the related controls should be part of the change itself — not something deferred until the next audit.

The point isn’t to question every audit conclusion. An audit is a snapshot. It captures what was true at the time. But the business does not stop evolving when the audit ends.

Auditors should ask a second question — not just “Did the control work when we tested it?” but also “What has changed since then?”

A control can be well designed. It can operate effectively. The audit conclusion can be completely reasonable. And months later, the environment around that control can shift just enough to create a new risk.

That’s control drift.

For internal auditors, recognizing drift means paying attention to what happens between audit cycles. Sometimes the risk isn’t in a control that’s obviously broken. It’s in a control that still looks correct on paper but no longer fits the way the business operates today.