Continuous Auditing: What It Actually Takes to Make It Work

I remember when IT audits felt like looking at a snapshot of the past. By the time we assessed the data, the risks had already evolved, and businesses had moved on. It always felt like playing catch-up: identifying issues only after they had caused disruption. That experience is what made continuous auditing compelling to me long before it became a regulatory expectation.

It is a regulatory expectation now. DORA Article 13 requires financial institutions to maintain continuous ICT monitoring as part of their ICT risk management framework. The obligation is not periodic monitoring with enhanced frequency. It is continuous: detecting anomalies, configuration drift, and availability issues in real time and feeding that signal into the ICT risk management process. For institutions that were already running mature continuous auditing programmes, this was confirmation. For those that were not, it created a gap that an annual audit plan cannot close.

What Continuous Auditing Actually Means

The definition that works in practice: continuous auditing is an always-on approach where automation, analytics, and scripted controls monitor systems and generate evidence on a rolling basis rather than at scheduled intervals.

I worked on an audit where a company had strong security controls on paper. In practice, misconfigurations left them vulnerable. A continuous monitoring setup would have flagged these within hours. The annual review found them fourteen months after they were introduced. The difference is not just speed. It changes the entire nature of the assurance. Point-in-time testing tells you what existed on a specific day. Continuous monitoring tells you what was operating across the period.

The mechanics: automation processes logs, transaction records, and system configurations continuously. Scripted controls check for compliance gaps on a scheduled or event-driven basis. Alerts are generated when thresholds are crossed. Evidence packages are built automatically, reducing the manual assembly work that consumes a disproportionate share of audit time.

The IIA Three Lines Model places continuous monitoring primarily in the second line, with internal audit consuming and challenging the outputs as part of its independent assurance role. In practice, the cleaner model for IT audit is to own the analytics layer directly: building and maintaining the monitoring queries, anomaly detection scripts, and exception reports that continuous auditing depends on, rather than relying on management's monitoring outputs alone.

Where It Delivers and Where It Breaks Down

The genuine advantages are real and I have seen them in practice. Faster anomaly detection: instead of discovering access misuse months later, it surfaces within the monitoring cycle. Continuous evidence collection: regulatory reporting becomes a matter of packaging evidence that already exists rather than conducting a retrospective review under time pressure. Better board and management visibility: near-real-time risk signals replace quarterly point-in-time summaries.

The failure modes are equally real. I once worked with a large mobile service provider that implemented a real-time fraud detection system. It flagged thousands of transactions incorrectly, frustrated operational risk teams, and missed simple process bypasses that led to unauthorised charges. The result was a reputational issue and a significant effort to recalibrate. The system was technically functional. The calibration was wrong.

Three failure modes appear consistently in continuous auditing implementations.

Alert fatigue. A monitoring system that generates more alerts than the team can review is not a control. It is noise. The alerts that matter get buried in the alerts that do not. Effective continuous auditing requires tiered alerting: immediate escalation for high-severity exceptions, daily review queues for medium-risk items, and weekly trend analysis for lower-priority signals. Without that structure, the volume defeats the purpose.

Model miscalibration. Anomaly detection depends on what the model considers normal. If the baseline reflects a period of unusual activity, or if the risk profile has changed, the model will produce persistent false positives in low-risk areas and miss exceptions in areas where normal behaviour was already problematic. Calibration is ongoing work, not a one-time setup task.

Monitoring pipeline integrity. If the system that generates the continuous audit evidence can itself be tampered with, the evidence is worthless. Access controls on the monitoring infrastructure, change management for monitoring scripts, and periodic independent verification of the pipeline's integrity are controls that most implementations overlook because they are not part of the original design. They need to be.

Making It Work in Practice

The implementation approach that works is incremental. Start with one high-risk domain where the data is accessible and the control questions are well-defined: privileged access, configuration management, or patch compliance are typical starting points. Build the monitoring queries, calibrate the thresholds against real exception data, and run a pilot for a quarter before expanding. The instinct to build a full monitoring programme immediately is where most implementations stall: the tooling gets deployed, the data pipelines are never fully reliable, and the programme never reaches operational maturity.

Training matters more than the tooling. Continuous auditing is a different way of working. Auditors who have spent their careers conducting point-in-time testing need to develop comfort with probabilistic signals, exception management, and the discipline of not investigating every alert. That shift requires deliberate development, not just a new dashboard.

The human judgment layer is not optional. Automation improves coverage and consistency. It does not replace the auditor's responsibility to interpret what the signals mean in context, to distinguish a genuine control failure from an expected operational exception, and to make the judgment call about what requires escalation. One of the most persistent mistakes in continuous auditing programmes is the assumption that if the system did not alert, there is no issue. The system finds what it is configured to find.

The Regulatory Direction

Beyond DORA, the direction is clear across jurisdictions. The FCA's operational resilience framework requires financial institutions to demonstrate continuous monitoring of their important business services and the technology that supports them. MAS TRM 2024 includes continuous monitoring of critical system performance as an explicit expectation. FFIEC guidance has long treated continuous monitoring as a component of mature ICT risk management for US financial institutions.

What regulators are converging on is the expectation that institutions know what is happening in their environment in something close to real time, and that their internal audit and risk management functions can demonstrate that coverage. Annual testing with quarterly exception reporting is no longer the standard for complex, technology-dependent institutions. Continuous monitoring is.

The question for IT audit functions is not whether to build continuous auditing capability. That decision has been made by the regulatory environment. The question is whether to build it deliberately, with proper design and calibration, or to deploy tooling quickly and discover the failure modes under examination pressure.