Continuous controls monitoring you work with in conversation: the agents test every key control each night, cite the records and ask; owners decide and the SOX lead signs
Control failures found in a day, not at year-end, and every fix proved by a re-test.
See one case, screen by screen ↓Continuous controls monitoring is the always-on testing of key financial and IT controls on the whole population, instead of a sample a few times a year, with exceptions routed to the control owner. Continuous Controls Monitoring does it with seven agents that re-run every monitored test each night, check whether an access conflict was used, open one cited case per cause and prove each fix with a re-test, while the owner decides and the SOX Program Manager signs.
How to choose AI solutions for back-office and enterprise work →
Updated
Most key SOX controls are still tested by sampling a few times a year. A sample of 25 items for a daily control tests a fraction of a percent of the population, so a control can break in March and nobody knows until the interim test in September or the auditor's walkthrough in January. An access conflict granted one evening is found at the next quarterly user access review, weeks later, after any payment run it could have touched.
Where monitoring exists, it is usually rule-based: every theoretical SoD conflict raises an alert, owners learn to ignore them, and suppressions live in a spreadsheet with no expiry. Cases are closed on the owner's word without anyone re-running the test, and every year the evidence for the external auditor — run parameters, populations, who approved what — is rebuilt by hand.
Estimated split for one SoD exception at a large SOX filer, by hand and with the solution.
Seven agents test every control each night, check whether a conflict was used, ask the owner and prove every fix; a person decides and signs.
Kestrel & Vane Group runs 64 SAP company codes on one S/4HANA production system, with a shared service centre in Zagreb. At 21:47 on 13 October an accounts payable specialist who already maintains vendors is given payment release. Here is what happens next, screen by screen, in the working solution.
Elena's day starts with the agents reporting what they did overnight: 148 controls tested, 142 green, 6 open cases, 9 items suppressed with a reason, 3 that need her. Each agent writes in plain words, with a citation behind every figure and a button for the next step. On the side, “Waiting on you” lists the critical ITGC-12 case, the ITGC-04 escalation and a request to extend a known exception.
Usage checker: “ITGC-12, critical. User mkovac was given payment release at 21:47 while she already maintains vendors. I read the logs: the conflict was not used. Daniel Osei has the case and three options.”
The control pulse is one strip per monitored control: ninety nights of results as a line, and last night's exceptions as dots she can count — solid for open, hollow for suppressed. The six controls with exceptions sit at the top under their status: with owner, escalated, re-testing. Green controls are folded away, and the agents' conversation sits beside the list, ready to answer or take an instruction.
“Next: ITGC-12 is critical. The agents have the record, checked it was not used, and gave Daniel Osei three options.”
ITGC-12 — no user can both maintain vendors and release payments — tests rule SOD-P2P-04 across 18,406 dialog users in 64 company codes. Clean for 89 nights, it found one user: mkovac holds Z_AP_VENDOR_MAINT since 4 March 2025 and was given Z_FI_PAYMENT_RELEASE at 21:47, valid to 31.12.9999. The drawer shows the AGR_USERS rows, the user record and ServiceNow request RITM0048213, “Holiday cover for payment runs, 14–25 Oct”, filed as a standard catalog item, so the access check never ran.
Every record is read through a read-only account and stamped with who read it and when.
The usage checker read the change documents and the transaction log for the whole window, 21:47 to 02:14: 0 payment runs, 0 payment releases, 0 vendor creates or changes, 0 bank-detail changes. She displayed vendor lines three times, read only. When Elena asks in the case “Was the access used?”, the answer comes back with its source and a confidence of 0.98.
Its limit: below a confidence of 0.95 the usage checker never says “not used” — it says it could not tell, and asks a person.
The triage agent opened CASE-1047: one exception, one cause, severity Critical by rule, due 18:00 the same day. It checked the two active known exceptions, SUP-027 and SUP-029, and neither applies. The remediation agent then asked Daniel Osei, the control owner, with the records and three options: A, remove payment release (recommended, because Ivan Horvat already releases payments for company code 3100 without vendor maintenance); B, remove vendor maintenance until 25 Oct; C, keep both for at most 14 days under a daily review, which needs the SOX Program Manager's approval.
“You make the change in SAP; the agents never change access themselves.”
Daniel chooses option A with reason code RM-01 · Access removed and the note “Cover through Ivan Horvat, agreed with Petra Novak.” He ends the role in SAP (change document 0004417782). The re-test agent re-runs rule SOD-P2P-04 on live data for mkovac and for all 212 users of company code 3100: 0 conflicts, and the exception no longer reproduces. ITGC-12 is green from 09:53.
The re-test agent never closes a case on the owner's word. If its result disagrees, it says so and the case stays open.
Critical cases need a second person: the owner resolved, the SOX Program Manager signs. Elena confirms that she reviewed the records, the usage check and the re-test, and signs off. The case closes, and the remediation agent opens follow-up FUP-118 for Amira Haddad: run the access check on every temporary access request. From grant to proved fix took one night and one morning.
“I reviewed the records, the usage check and the re-test, and agree the case is closed.”
In CASE-1046, P2P-03 found two vendor bank-detail changes by one user, jbarros, with no call-back. The Fernhill Logistics request came by email from a domain registered on 9 Oct, marked urgent, with an unsigned letterhead, and Fernhill is due €48,760 in the 16 Oct payment run. The remediation agent proposes a payment block on the vendor; Marcus approves or declines it, and then chooses how to resolve the changes.
“Protective action proposed: a payment block on vendor 300418 Fernhill Logistics, holding €48,760 from the 16 Oct run until the change is verified. It runs only if the owner approves.”
ITGC-04 — firefighter sessions reviewed within 48 hours — failed in August, September and October, each time at period end, when the review rota had nobody assigned. Three failing months in 90 days is the repeat-failure rule, so the escalation agent brings it to Elena with the history and recommends raising it for deficiency evaluation with a rota fix by 31 Oct. She decides with a reason code; classification stays with her and the Internal Audit Director.
“Fixing the instance again will not stop it.”
Marcus asks to extend known exception SUP-027 — three-way-match tolerance overrides at the Ostrava plant during a warehouse migration — to 30 Nov. The triage agent shows the volume falling every week, from 41 a night on 18 Sep to 7 tonight, reaching zero around 8 Nov, and recommends 15 Nov. Elena approves to 15 Nov, approves to 30 Nov or rejects, with a reason code; she cannot be the requester.
“I recommend 15 Nov: a week of margin, without hiding new problems for three weeks.”
The same night, seen by the five people who carry it — what their year looked like, and what it looks like now.
Seven agents test every control each night, check whether a conflict was used, ask the owner and prove every fix; a person decides and signs.
Re-runs each monitored control's test on the whole population every night or on demand, through read-only accounts, and records the parameters, population counts and a fingerprint for every run.
For every access or SoD exception, reads the change documents and transaction logs for the exact window and says whether the conflicting access was used, listing the transactions.
Groups exceptions into one case per real cause, sets severity from the rule, applies only approved, unexpired known exceptions and re-checks every suppressed item each night.
Writes the owner's ask with the records, the cause, two or three options and a recommendation, and proposes protective actions such as a payment block or a role removal ticket.
Watches the clock on every case and repeat failures; reminds the owner, then escalates to the SOX Program Manager with the history.
After a fix, re-runs the control's test on live data for the exact exception and its population, compares it with the original evidence and returns the control to green only on a pass.
Assembles the evidence package for the external auditor, writes the trend notes and answers questions, with a citation behind every figure.
The owner resolves with a reason code; the SOX lead approves suppressions and signs off critical cases. The agents propose; a named person decides.
Every screen has the agents' conversation beside it. Ask about any control, case or user, or give an instruction; every answer links to the record behind it.
Was mkovac’s payment-release access used?
No. Between the grant at 13 Oct 21:47 and the test at 02:14 I found 0 payment runs, 0 payment releases and 0 vendor or bank-detail changes by mkovac. She displayed vendor lines three times, read only.
Who granted the role, and under which ticket?
ITADM_RSOLER at 21:47, under ServiceNow RITM0048213, “Holiday cover for payment runs, 14–25 Oct”, requested and approved by Petra Novak. It was filed as a standard catalog item, so no access check ran, and the end date of 25 Oct did not reach SAP.
Why 15 Nov and not 30 Nov?
The warehouse back-postings are falling every week, 41 a night on 18 Sep to 7 tonight. At this rate they reach zero around 8 Nov. 15 Nov leaves a week of margin; 30 Nov would hide three weeks of new problems.
Remind the owners whose cases are due tomorrow
Done. I reminded Marcus Okafor (CASE-1046) and Hannah Vos (CASE-1045) on Teams, each with the records and the options. Both reminders are in the audit trail.
13 screens from the working solution, on its sample data. Pick one to see it large.
Clocks, escalation, suppression policy and what the agents may do are settings. Every change is saved as a new version with a note.
| Setting | Default | Choose from |
|---|---|---|
| Clock for a critical case | 1 business day | 1 business day · Same day · 3 business days |
| Clock for a high case | 2 business days | 2 business days · Same day · 3 business days |
| Repeat failure escalates to the SOX Program Manager | 3 of 3 months | 3 of 3 months · 2 of 3 months |
| Known exception expiry | At most 90 days, reminder 7 days before | in 30 days · in 60 days · in 90 days |
| Re-test before a case closes | On | Locked on |
| Critical cases signed off by the SOX Program Manager | On | Locked on |
| Usage checker confidence floor | 0.95 | Below it, the checker says it could not tell and asks a person |
| New critical case notice | Email + Teams, at once | Email + Teams, at once · Email · In the app only · Off |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample data · “target” = the design goal, measured in the live solution · “estimated” = our estimate · “typical” = published figures (KPMG 2025 SOX Survey, FY24 data from about 150 SOX leaders — average program cost $2.3M, up 44% in two years; 16 hours to test one control's operating effectiveness, up from 12; automated controls 17% of the total while in-scope systems grew from 17 to 40). People, companies, vendors and user ids named on this page are fictional — characters and sample data in the working solution.
Continuous controls monitoring is the always-on testing of key financial and IT controls on the whole population, instead of a sample a few times a year, with exceptions routed to the control owner. Continuous Controls Monitoring does it with seven agents that re-run every monitored test each night, check whether an access conflict was used, open one cited case per cause and prove each fix with a re-test, while the owner decides and the SOX Program Manager signs.
A sample of 25 items tests a fraction of a percent of a daily control's population, a few times a year. Here the monitoring agent tests every record each night — in the sample data, 148 key controls and 3,184,522 records in 41 minutes — so a failure is found the next morning, not at interim testing.
The usage checker reads the change documents and transaction logs for the exact window and says whether the conflicting access was actually used, with the transactions. Below a confidence of 0.95 it says it could not tell and asks a person. The triage agent then groups exceptions into one case per real cause, so five failed bank files with one expired certificate are one case, not five.
No. The agents read your systems through read-only accounts. The remediation agent can propose a protective action, such as a payment block or a role removal ticket, and it runs only when the control owner approves. The owner makes the fix in the system.
Each known exception needs a written reason, a scope, a named approver who is not the requester and an expiry of at most 90 days. The triage agent re-checks every suppressed item each night, wakes a new case if an item falls outside the scope and tells the approver before expiry, with the volume trend and a recommendation.
The evidence writer assembles a package with every run's parameters and record counts, a SHA-256 fingerprint of each population, the control definitions with their versions, every exception, resolution, re-test and sign-off, and the audit trail. The preparer signs it and shares it read-only with the approved auditor list, and the auditor can re-perform any run from its parameters. How far they rely on it is the auditor's decision.
Yes. The control owner decides every case with a reason code and can say it is not an exception; the SOX Program Manager approves suppressions, decides escalations and signs off every critical case. No case closes without a passing re-test, and both rules are locked on.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your risk and control matrix, your rules and read-only access to your systems — and it goes live once every quality gate has passed. A guided first-time setup connects the systems, imports the matrix, lets the agents propose which controls can be monitored, confirms tests and owners, sets the schedule and runs the first night.
Every sample cited, re-performed and signed before your auditor asks.
1-min demoAudit Evidence CollectionEvidence checked before the auditor sees it, and the request list closed before fieldwork.
1-min demoJournal Entry TestingEvery entry tested for override, not a sample, with each conclusion cited to its support.
1-min demoWe'll run Continuous Controls Monitoring on a few of your own key controls, read-only, against your risk and control matrix.