Summarize this blog post with:
| Continuous control monitoring evaluates every transaction against live data, so control failures surface in days rather than in next quarter's audit sample. |
TL;DR
- Audit teams automated the write-up, not the test. The sampling method underneath is unchanged.
- Most GRC platforms hold control definitions. Far fewer compute them against live data.
- GRCPulse separates deterministic rules from AI foresight, routing both through a human gate.
- Continuous control monitoring is an assurance system. A control repository is a filing cabinet.
Gartner's August 2026 poll of 743 audit professionals found 93% of audit leaders report some AI use, while only 38% have an AI strategy. The revealing detail is in the use cases: fewer than a third apply AI to audit testing, at 30%, while 60% use it to draft audit issues, ratings or reports.
So, AI has made the report faster without changing the test. That test is still a sample, pulled after the quarter closes, from a population nobody has examined in full.
Spending follows the same pattern. PwC's 2026 Global Digital Trust Insights, a survey of 3,887 executives across 72 countries, found only 24% spend significantly more on proactive work such as monitoring, testing and controls than on reactive work.
Sampling answered a data-access problem that no longer exists. When evaluation data already sits in a governed platform, testing 5% of it is a choice, not a constraint.
Start with the problem it solves. Every organisation has policies, those policies carry risks, and each risk is meant to be mitigated by a control. What most lack is a single place to check whether those controls are holding.
Continuous control monitoring is that place. It connects to your data platform, pulls the data each control needs, calculates the KPI, and marks it in-bound or out-of-bound. It does this across every record, on a schedule you set, without waiting for a period to close.
Four words describe the loop, and keeping them distinct matters.
The control lifecycle
- Control. The mitigation created for a known policy risk.
- Test. Data pulled and evaluated against that control's threshold.
- Exception. An out-of-bound result. A KPI breach, not yet a finding.
- Remediation. A confirmed failure, owned, actioned, closed with evidence.
The gap between stage three and four is where most continuous control monitoring tools go wrong. They report every exception as a finding, and people stop opening the alerts.
Both are looking for the same thing: a control that has quietly stopped working. They differ in three practical ways.
- How much they check. An audit tests a sample and infers the rest. Continuous controls monitoring checks every transaction and reports what it found.
- When they tell you. A quarterly cycle can surface a breach up to 90 days late. Continuous compliance monitoring surfaces it on the next run.
- What they leave behind. An audit leaves a workpaper written after the event. GRC control monitoring leaves a running record of who approved what, when and why.
Audits keep one advantage: a person deciding whether a breach genuinely matters. That judgement is worth protecting, so the question is not how to remove people but where to place them.
Most GRC platforms store control definitions. SAP GRC, AuditBoard, Workiva, ServiceNow GRC and MetricStream do that well, along with ownership and workflow. What they do not do is calculate those controls against live data.
GRCPulse starts from the data platform instead, so it is not a record of your controls but a test of them.
Inside the engine: two rows and one gate
- Deterministic row. Coded rules that flag policy breaches with no AI involved. An auditor can read them line by line.
- Intelligence row. Six bounded AI agents surfacing emerging risks, coverage gaps and likely breaches. Everything they produce is a proposal.
- The gate. Both rows hand their output to the same reviewer before anything becomes a record.
The two rows run together and do different jobs. The deterministic row gives an auditor something inspectable. The AI row gives a reviewer something to weigh. Because every item is labelled with the row that produced it, one person can govern both.
Underneath, a knowledge graph links vendors, contracts, obligations, controls and assets. Polestar Analytics builds it with the client, and it answers two questions: what else breaks when this control does, and which clause created the obligation in the first place.
A purchase order is raised without a purchase requisition. The rule fires. The exposure looks real.
Except the PR genuinely was raised. It went over email and never made it into Ariba.
So, the reviewer annotates the exception, overrides it, and records why. Eighteen months later, when someone asks why this item was accepted and a similar one was not, that reason is the answer. A system that cannot be told it is wrong eventually produces findings nobody acts on.
The same gate produces two numbers worth publishing: AI confirmation rate and override rate. Track them and you can see whether the agents are earning their place.
A data foundation, not a platform programme. GRCPulse needs a cleansed gold layer. If that exists, the app lands on it. If not, Polestar Analytics' data engineering practice builds it, with the same governance-by-design thinking applied to AI risk controls.
Bring your own controls, or use the shipped library:
- Procurement: PO without PR, three-way match breaks, maverick spend, split POs. Lifted from the procurement analytics practice.
- Payments and finance: segregation of duties, duplicate payments, payments to changed bank accounts, unauthorised journals.
- Cyber: dormant privileged accounts, MFA gaps, undeprovisioned leaver access.
- Construction: unapproved change orders, subcontractor compliance lapses, milestone payments without sign-off.
It deploys natively on Databricks, Fabric, Snowflake and Azure, so there is no platform argument to have. That neutrality runs across 1Platform and the wider Pulse suite, and shapes how Polestar Analytics handles regulated Databricks workloads and governed migrations.
Proven where it counts: a Fortune 500 commercial real estate engagement, won against a Big Four incumbent on domain specificity in the first meeting.
An audit infers the whole from a sample, and sampling risk is the price. Continuous control monitoring removes that inference by testing everything. The question changes from what you missed in the 95% you never opened to whether your control definitions are good enough.
False negatives get checked by a person rather than assumed away, and agent quality is tracked through confirmation rate and override rate. If a vendor of continuous control monitoring tools cannot show you those two numbers, they are asking for trust they have not earned.
Usually not. Incumbent GRC control monitoring platforms hold control definitions, ownership and workflow well. What they generally do not do is compute those controls against live data. GRCPulse sits on the data platform and does that. The repository keeps its job.
A governed gold layer for the systems in scope, usually ERP, procurement and your risk and control systems, plus the policy documents. Gartner's March 2026 predictions point the same way, forecasting that by 2030 half of organisations will use AI agents to turn governance policies into machine-verifiable data contracts.
- AI in audit is a reporting upgrade so far. Only 30% of teams use it to test controls (Gartner).
- An exception is not a finding. Tools that conflate them lose their reviewers.
- Run coded rules and AI agents side by side. One reviewer can govern both when each item is labelled.
- The recorded reason is the audit trail, not the approval click.
- Measure the monitor through confirmation rate and override rate.