From Periodic Sampling to Continuous Assurance

Ask most internal audit or controls teams how they know a key control is operating effectively, and the honest answer is usually some version of: it was tested last quarter, on a sample, and nothing came up. That answer has been good enough for a long time because it was the best a manual process could do. It was never actually good enough for the risk itself — a duplicate invoice paid in week three of the quarter sits unnoticed until the week-thirteen sample happens to catch it, if it catches it at all.

Continuous Controls Monitoring closes that gap by testing controls directly against transactional data, continuously, rather than through periodic manual sampling. It is not a new idea — the concept has existed in internal audit literature for over a decade. What has changed is what makes it practical to deploy: agentic AI can now read policies and prior audit findings, build the control logic, connect to source systems, investigate exceptions, and assemble audit-ready evidence, at a cost and speed that a purely manual or purely custom-built approach never reached.

This is the first article in a new Crest.Digital series on Crest Agentic Risk & Continuous Assurance — customized AI agents and continuous-control solutions built around a client's own systems, risks, and control environment. This piece focuses on Continuous Controls Monitoring itself, using procure-to-pay and vendor-master controls as the concrete illustration, since they're the fastest for most finance and audit teams to recognize.

Why Periodic Control Testing Misses What Matters

Sampling exists because testing every transaction by hand was never feasible. A controls team picks a statistically defensible sample, tests it, and extrapolates. That approach is defensible from a methodology standpoint and indefensible from a risk standpoint the moment you ask a simple question: what happens to the transactions outside the sample during the review period?

The answer, for most organizations, is nothing — until the next cycle. A vendor's bank account can be changed and a payment released against the new account before any control catches the change, because the control that would have flagged it only runs quarterly. A manual journal entry posted late on a Friday, outside the normal approval workflow, sits in the ledger for the better part of a quarter before a sample happens to select that period. None of this requires a sophisticated fraud scheme — it only requires a gap between when something happens and when someone looks.

What Continuous Controls Monitoring Actually Tests

Continuous Controls Monitoring connects directly to the systems that generate financial and operational transactions — ERP, procurement, payroll, CRM, banking, and other operational platforms — and runs automated tests against that data on an ongoing basis rather than at a scheduled interval. In procure-to-pay and vendor-master controls alone, the testable exception list is long and familiar to any controller or internal auditor:

• Duplicate payments and duplicate invoices
• Three-way match exceptions between purchase order, goods receipt, and invoice
• Purchase-order splitting used to bypass approval thresholds
• Payments released without the required approval chain
• Vendor-bank-account changes made shortly before a payment run
• Dormant or duplicate vendor master records
• Manual journal entries posted outside standard workflows
• Weekend or post-closing-period entries
• Segregation-of-duties conflicts across the procure-to-pay cycle
• Unusual credit notes and discounts

The same discipline extends beyond procure-to-pay: payroll anomalies and ghost-employee patterns, user-access and privileged-access exceptions, and control failures that recur across periods without being escalated as a systemic issue rather than a one-off finding. What makes each of these a CCM candidate, rather than a one-time analytics exercise, is that the underlying risk doesn't go away between review cycles — the control needs to run as often as the risk does.

An 8-Point Framework for Continuous Controls Monitoring

A defensible CCM programme is more than a set of alerts. It needs a structure that connects a tested control back to a documented risk, and every flagged exception forward to a decision and an evidence trail.

Points five and six are usually where a CCM initiative either earns its keep or quietly stalls. A system that generates exceptions faster than anyone can investigate them produces alert fatigue, not assurance — the investigation and escalation layer is what turns raw exceptions into decisions that actually close risk.

The Delivery Model: Discover, Design, Connect, Deploy, Validate, Transfer

Standing up a CCM capability doesn't need to start with a multi-quarter platform selection process. Crest.Digital runs a six-phase delivery model built to get a first, well-scoped use case live and validated quickly, then extend from there.

The validate phase is deliberately not optional. Running a new automated test in parallel with the existing manual process, before cutting over fully, is what gives a controls team the confidence to trust the automated result — and it's the step a purely improvised analytics project usually skips, at real cost to adoption later.

Where Agentic AI Fits in a Continuous Controls Programme

Running one control test continuously is a data-engineering problem. Running dozens of control tests continuously, across multiple systems, while investigating every exception with enough context for a human to make a fast, confident decision — that's an orchestration and reasoning problem, which is exactly where agentic AI earns its place in a CCM programme rather than being a marketing label attached to a rules engine.

AI-Assisted Evidence Collection and Correlation

When a control test flags an exception, an agentic workflow can immediately pull the related records — the vendor's change history, prior payment patterns, the relevant approval chain — into a single case file, rather than leaving a reviewer to hunt across four different systems before they can even begin assessing whether the exception is real.

AI-Led Investigation and Root-Cause Hypotheses

Beyond assembling evidence, an agent can propose an initial hypothesis for why an exception occurred — a process gap, a control override, a genuinely anomalous transaction — giving the human reviewer a starting point rather than a blank exception with no context. This is the same discipline behind AI's broader shift of audit from sampling to continuous assurance, applied specifically to the control-testing layer rather than the audit plan as a whole.

AI-Based Remediation Tracking

Once an exception is confirmed and a remediation action assigned, an agentic layer can track it to closure, send contextual reminders as deadlines approach, and — critically — flag whether a similar exception recurs afterward, which is often the clearest signal that a fix addressed a symptom rather than the underlying control gap.

Human-in-the-Loop on Every Determination

What the agents do not do is decide that an exception is immaterial, close a finding, or issue an audit opinion. Those calls stay with the control owner, the internal auditor, or the risk leader accountable for them — informed by evidence the agents assembled rather than replaced. Extending audit trail and accountability discipline to agents themselves is consistent with how Crest.Digital frames accountability for AI agents more broadly and who owns an agent's decision across the wider risk platform.

Why This Isn't Bespoke Software Development

A natural objection to "customized AI agents for your controls" is that it sounds like a euphemism for a long, expensive, one-off software build. It isn't, and the distinction matters commercially as much as technically. Crest.Digital retains a common underlying framework across every engagement — integration connectors, agent orchestration, a workflow and approval engine, a rules and risk-scoring engine, an evidence repository, an issues and remediation module, AI logs and explainability, role-based access, dashboards, and audit trails.

What is genuinely client-specific is narrower than the whole technology stack: the data mapping to a client's actual systems, the specific control logic for the risks that matter to that business, the workflow and approval chain, the prompts the agents use, and the dashboards presented to stakeholders. That split is what makes a first use case deployable in weeks rather than quarters, and it's also what makes a second and third use case faster still — the reusable layer doesn't get rebuilt each time. This connects naturally to Crest's broader end-to-end governance approach and to the same reusable infrastructure behind Crest's continuous vendor intelligence work — the underlying platform extends into internal controls and audit rather than being rebuilt from scratch for it.

Commercially, this also opens a structure beyond a single project fee: a discovery and solution-design fee, an implementation and customization fee, and an annual platform, agent, and maintenance fee, with optional managed services covering alert review, control testing, investigation, evidence validation, remediation follow-up, and reporting for organizations that would rather operate the programme as a service than staff it internally.

Frequently Asked Questions