Compliance monitoring software: testing controls between audits

Compliance monitoring software tests whether controls are still being operated in the long stretches between audits. An audit is a deep look once a year; monitoring is a shallow look every month, on a defined sample, by the team that owns the second line rather than by an independent auditor. Organisations that only audit discover a control stopped working eleven months ago. Organisations that monitor discover it in three weeks.

What compliance monitoring software should do

• A monitoring plan: which controls are tested, how often, by whom, with what sample size.
• Test scripts that state the evidence required, so two people testing the same control reach the same conclusion.
• Sampling that is recorded and reproducible, not whatever the tester happened to open.
• Exception logging with severity, owner and remediation date.
• Trend reporting per control, because a control failing 2 of 20 every month is a different problem from one that failed once.
• Automated checks where the data allows it — duplicate payments, dormant accounts, approvals below threshold.
• A route for escalating a control that fails repeatedly, rather than logging the same exception forever.

Monitoring is not auditing

Keep the two separate, because independence depends on it. Monitoring is management assurance: the compliance function checking its own organisation, frequently and narrowly. Auditing is independent assurance, including assurance that monitoring itself is being done properly. If the same person designs the control, operates the monitoring and signs off the audit, the organisation has one opinion dressed up as three, and an external reviewer will say so.

Set the sample size before testing, not after. A tester who examines items until they find a problem, or until they stop finding one, produces a number nobody can interpret and a conclusion nobody can defend.

Building a monitoring plan

1. List the controls that matter, ranked by the consequence of failure rather than by ease of testing.
2. Assign a frequency per control: monthly for high consequence, quarterly or annually below that.
3. Write a test script for each — population, sample, evidence, pass criteria.
4. Run the first cycle manually to see how long it actually takes before promising a schedule.
5. Log exceptions with owner and date, and report the ones still open at each governance meeting.
6. Review the plan annually and drop tests that have passed cleanly for years in favour of new risks.

Ettex Records holds the plan and its results: one row per control with frequency, owner and last test date, a result per cycle with sample size and evidence reference, and an exception log with remediation owners. Where a control fails repeatedly the same record feeds a deeper review in compliance audit management software, which is how monitoring is supposed to escalate.