Compliance monitoring and assurance plans: designing testing that proves the controls work

What a monitoring and assurance plan is

A monitoring and assurance plan is a dated schedule of tests, each aimed at a specific control, with a defined method, sample, tester and reporting destination. Its output is evidence that the controls on the obligations register actually work — not evidence that they exist.

The distinction is the whole point. A control register says a control exists. A policy says what it should do. Only testing establishes that it operated as intended across a period. Regulators and auditors treat untested controls as unproven.

Written as an annual plan, it typically covers between twelve and forty tests for a mid-sized business, weighted toward the obligations carrying the highest residual risk on the risk register.

Design effectiveness versus operating effectiveness

Every test answers one of two questions, and conflating them is the most common design error.

Test design first. Testing whether a control operated is wasted effort if the control could never have satisfied the obligation.

A design test is also the correct response to a new or amended obligation. When a regime changes, the first question is whether the existing control still discharges the new duty — a question the obligations register change intake should raise automatically.

Choosing what to test and how often

Rank by residual risk, then apply four modifiers. The plan should be defensible on its face, so record the reasoning.

Base ranking: residual risk rating from the risk register.

Modifiers that increase frequency:

• The control is manual rather than system-enforced.
• The control failed, or an incident touched it, in the last twelve months.
• The obligation changed recently, or the underlying process changed.
• The control depends on a third party — see contractor and supplier compliance.
• Staff turnover in the operating role.

Modifiers that reduce frequency:

• The control is fully automated with change control over the configuration.
• It has passed testing without exception in consecutive periods.
• Independent assurance already covers it (certification audit, external audit, regulator inspection).

A workable default pattern:

Publish the plan at the start of the year and treat additions as amendments recorded with a reason. A plan quietly reshaped mid-year to avoid a difficult test is a governance failure in itself.

Sample sizes and evidence in a small business

Small populations defeat statistical sampling, and pretending otherwise produces indefensible conclusions. Practical approach:

• Small population (under 25 items): test all of them. It is usually faster than justifying a sample.
• Moderate population: test a judgemental sample weighted toward higher-value, higher-risk or period-end items, and say in the working paper that the sample was judgemental and why.
• Large, automated population: test the configuration plus a small validation sample, and rely on system controls for the rest.
• Event-driven controls (incident notification, breach reporting): test every event in the period. Populations are small and each one matters. The incident register is the population listing.

Evidence retained for each test should let a second person reach the same conclusion without asking questions: the obligation and control tested, the period, the population source and how it was extracted, the sample and how it was selected, the attribute tested, the results item by item, exceptions and their disposition, the conclusion, the tester and the date.

Never conclude "satisfactory" without recording the population source. A test over a list supplied by the person operating the control, with no independent extraction, is the finding most likely to be reversed on review.

Recording results and the issue that follows

A test with an exception generates an issue, and the issue is the artefact that gets tracked — not the test.

Each issue should carry a rating, a root cause, an owner who is senior enough to fix it, an agreed action, a target date, and a verification step confirming the fix worked. The verification step is the one most often skipped, and it is the one an auditor tests.

Where a test reveals that an obligation was actually breached, the issue crosses into the incident and breach register and starts any statutory clock — reportable situations under ASIC's RG 78, data breach assessment obligations, or sector-specific notification duties. The monitoring plan is a common discovery route for breaches, and the handoff between the two registers should be written into the procedure.

Independent evaluation and external assurance

Some assurance must come from outside the monitoring function.

• Regime-mandated independent evaluation. Reporting entities under the anti-money laundering regime must have the program independently evaluated at least once every three years under the reformed rules, with staggered first-evaluation deadlines under the Anti-Money Laundering and Counter-Terrorism Financing Transitional Rules 2026 (checked August 2026). AUSTRAC's guidance sets out what the evaluator must cover, including the risk assessment, policy design, and whether risk was actually identified, mitigated and managed in practice: AUSTRAC — conduct an independent evaluation.
• Assurance engagements over non-financial information. Where an assurance report is required or sought over sustainability, compliance or other non-financial subject matter, the engagement standard framework is covered in ASAE 3000 assurance engagements. Climate reporting brings phased assurance requirements — see the ASRS Group 1 disclosure walkthrough.
• Certification surveillance. Where certifications are held, surveillance audits provide independent coverage over the certified scope. Scope them deliberately; a narrow certified scope provides narrow assurance.
• Regulator inspections and external audit management letters. Both are assurance output. Track the findings in the same issues log as internal testing.

Reporting the plan and its results

The board should see the plan once and the results every cycle. A usable report has five elements:

1. Plan status. Tests completed against planned, with reasons for any deferral.
2. Results summary. Pass, pass with exceptions, fail — by obligation domain, not by test number.
3. Open issues. Ageing, by rating, with overdue items named and their owners.
4. Repeat findings. Issues raised previously and found again. This is the strongest single indicator of program health.
5. Coverage. Which high-risk obligations have not been tested in the last twenty-four months, and why.

The fifth element is the one boards ask for once and then always want. Reporting structure is covered further in board and committee compliance reporting.