Internal Audit and Continuous Assurance

Internal audit has more freedom with AI than external audit. It is not bound by ISA, it can test continuously rather than annually, and its remit extends past the financial statements into operational and compliance risk. That freedom is real, and it creates a specific hazard: internal audit functions that build genuinely useful monitoring and, in doing so, stop being independent of the thing they monitor.

Continuous Monitoring Versus Continuous Auditing

These terms are used interchangeably in practice and should not be.

Continuous monitoring is a management activity. Management owns the control environment and monitors it continuously — flagging duplicate payments, detecting policy breaches, checking transactions against limits. Automated monitoring is a control.

Continuous auditing is an internal audit activity providing independent assurance that controls, including the monitoring ones, are operating effectively.

The distinction matters because of what happens when it blurs. An internal audit function that builds a duplicate payment detection routine, runs it monthly, and passes results to accounts payable for correction has built and is operating a control. Next year it cannot provide independent assurance over duplicate payment controls, because it is one of them. This happens frequently and rarely by decision. It happens because internal audit had the data skills, management did not, and the routine was useful.

Two rules keep the line visible. Internal audit may build, but should hand over. Where internal audit develops a monitoring routine because it has the capability, transition ownership and operation to the relevant business function on a defined timetable, then audit it. Internal audit tests, it does not correct. If internal audit identifies exceptions and routes them for correction as routine business process, it has entered the control. Reporting findings to management for action is assurance; operating the exception queue is not.

Designing the Response Protocol First

The most common failure in continuous assurance is not technical. It is that alerts are generated and nothing happens.

A routine that runs weekly and produces forty exceptions requires someone to act on forty exceptions weekly. If that capacity does not exist, the exceptions accumulate, the backlog becomes an accepted feature, and the function is worse off than before — because it now has documented evidence of unaddressed exceptions. That is a materially worse position than not having run the routine, both for the organisation and for the individuals who knew.

The response protocol therefore has to be designed before the routine goes live, and it must specify: who receives an alert, the timeframe for initial assessment, the escalation path where the assessment identifies a genuine issue, who tracks resolution, and what happens when the alert volume exceeds the response capacity.

That last element is the one omitted. Volume varies, and it varies most during exactly the periods when something is going wrong. The protocol needs a defined behaviour for overload — a documented prioritisation rule, or a trigger to escalate resourcing — rather than an implicit expectation that everything will be reviewed.

The practical consequence is that alert design should be calibrated to response capacity. A narrower, higher-precision routine that generates five investigable alerts a week is more valuable than a broad one that generates two hundred, because the five will actually be worked. Coverage that nobody responds to is not coverage.

Frequency Should Follow the Risk

Continuous does not mean constant, and running everything in real time is a common and expensive mistake. Frequency should follow the risk cycle of what is being tested.

• Real time or daily where the exposure accrues quickly and reversal is time-sensitive: payment fraud, unauthorised access, limit breaches.
• Monthly for most transactional control testing, aligned to the accounting cycle so exceptions can be traced to a closed period.
• Quarterly or annually for structural matters — segregation of duties matrices, policy compliance, master data integrity — which change slowly and generate mostly repeat findings when run more often.

Running a monthly-cadence test daily produces the same exceptions thirty times, trains the recipients to ignore the alert, and consumes the response capacity that a genuine daily risk would need.

Where the Three Lines Model Strains

The three lines model puts operational management first, risk and compliance functions second, and internal audit third, independent. AI-driven assurance strains it in a predictable way: the data science capability usually sits in one place, and all three lines want to use it.

If a central analytics team builds monitoring routines for operations, risk models for the second line, and testing routines for internal audit, the independence of the third line depends on a team that also serves the first two. That is not automatically fatal, but it must be managed explicitly: separate development environments, internal audit control over its own routine logic and thresholds, and clear documentation that internal audit determined what to test and how, whoever wrote the code.

The failure mode to avoid is internal audit accepting a routine built by the analytics team, running it, and reporting the results as independent assurance without ever having reviewed the logic. The independence question is not who typed the code. It is who decided what the test does and who can change it.

External Audit Reliance Under ISA 610

Where internal audit performs AI-driven testing, external audit may be able to use that work under ISA 610, which requires evaluating the internal audit function's objectivity, competence, and systematic and disciplined approach, and then evaluating the specific work used.

For AI-driven work the practical questions map onto earlier lessons. Objectivity: has the function retained independence, or has it drifted into operating the controls it tests? Competence: does the function understand the routines well enough to explain what they test and their limitations, or is it running something the analytics team built? Systematic and disciplined approach: is there documented methodology covering how criteria are set, how exceptions are evaluated, and how routines are validated?

Then the work itself must meet the same standards from lesson five: population completeness reconciled, criteria documented and appropriate, output retained, unflagged items addressed. Internal audit work is not held to a lower documentation bar merely because it was not performed under ISA — if it is to be used as audit evidence, the evidence must be sufficient and appropriate.