Most audit reports describe how a control performed months ago, tested on a sample, during a few weeks of fieldwork. By the time the report reaches the audit committee, the system has changed, the people have changed and the risk has moved on. The report is accurate, but it is a photograph of a moment that has already passed.
Continuous auditing is the attempt to turn that photograph into a live signal. Instead of testing a control once a year, internal audit tests it automatically and often, sometimes daily, and looks at the exceptions as they appear.
What it is, and what it is not
Continuous auditing means internal audit running automated tests over complete populations of transactions, logs or configurations at a high frequency, and following up the exceptions. It is an audit activity, owned and designed by the audit function.
It is often confused with continuous monitoring, which belongs to management. Monitoring is the first and second line watching their own controls day to day. Auditing is the third line checking, independently, that those controls and that monitoring actually work.
The two are strongest together. Where management already monitors a control well, audit can test the monitoring itself rather than repeat it. Where nobody watches a control at all, continuous auditing is often how that gap is found. Together they give what boards really want: continuous assurance.
Why now
The idea is decades old. What has changed is how easy it has become.
- The data is reachable. Cloud platforms, identity systems and business applications expose logs and records through standard interfaces that did not exist a few years ago.
- The tools are ordinary. A scheduled query, a script or a workflow automation tool can do work that once needed a specialist platform and a large budget.
- Expectations have moved. Audit committees increasingly ask not just "was this control effective last year?" but "is it working now?"
Where to start
The best first candidates are controls that are high volume, rule based and already produce data. A few examples that work in most organisations:
- Leaver access. Accounts still active after the person has left, matched against the HR leavers list.
- Privileged access. New administrator accounts or role assignments without an approved request.
- Segregation of duties. Users holding conflicting roles, such as creating and approving the same payment.
- Change management. Changes reaching production without an approved change record.
- Payments and vendors. Duplicate payments, and bank details changed on a supplier shortly before a payment.
- Configuration drift. Security settings that have moved away from the approved baseline.
- Resilience basics. Failed backups and overdue critical patches.
Controls that depend on judgement, such as whether a risk acceptance was reasonable, are poor candidates. They still need a person reading the evidence.
How to build it
- Pick a small set of tests. Three to five, chosen from the highest risks in your audit universe, not from whatever data happens to be easiest.
- Secure the data properly. Read only access, the minimum fields needed, and agreement from the data owner. Audit's access to production data is itself a risk to manage.
- Write each rule down. What is tested, against which source, at what threshold, how often, and what counts as an exception.
- Agree the exception workflow before going live. Who receives exceptions, how quickly they respond, and when audit escalates. Without this, the output is just a list.
- Report trends, not lists. The audit committee needs to see whether exceptions are rising or falling, and how fast they are closed, not five hundred rows.
- Review the rules regularly. Systems change and rules quietly stop matching reality. Schedule a review of every test at least twice a year.
The traps to avoid
Alert fatigue
A test that produces hundreds of false positives is worse than no test, because people learn to ignore it. Tune thresholds before scaling, and track how many exceptions turn out to be real.
Becoming management's monitoring
If audit's scripts become the only thing watching a control, audit has quietly taken over a management responsibility and weakened its own independence. The aim is to prompt management to own the monitoring, then audit to test it.
Unreviewed audit code
Audit scripts make decisions about what is and is not an exception. They deserve the same discipline auditors expect from others: version control, peer review and change records. Auditors should be able to pass their own change management audit.
Dependence on one person
Many programmes rest on a single analyst who wrote the queries. Document the tests, share the knowledge and make the programme repeatable by the whole team.
Where AI fits
AI can help with the heavy lifting: grouping similar exceptions, drafting first explanations and spotting patterns across tests. It does not remove the need for judgement. The rules, the thresholds and the conclusion about whether a control is working remain decisions an auditor must be able to explain and stand behind.
What changes for the audit function
Once a few tests run continuously, the annual plan starts to change shape. Risk assessment becomes rolling rather than yearly, because the signals show where risk is moving. Fieldwork shifts from finding exceptions to understanding them. Reporting to the audit committee gains a standing view of control health between full audits.
Continuous auditing does not replace the audit. It replaces the long silence between audits. That alone is a significant improvement in the assurance a board receives.