The Compliance Monitoring Programme

Monitoring is a different job from compliance

Most compliance teams spend their week on advisory work: answering questions from marketing, reviewing a new product, drafting a policy update, handling a regulator's letter. All of that is necessary, and none of it tells anyone whether the controls the business relies on are working. A compliance monitoring programme is the part of the second line that answers that question on a schedule, with evidence, and writes the answer down.

The distinction matters because the two activities fail in different ways. Advisory work fails visibly: a campaign goes out without sign-off and somebody notices. Monitoring fails silently. If nobody tests whether the self-exclusion check runs at the point of deposit, the first person to find out it stopped working after a platform release is usually a customer, a journalist or a regulator.

A useful working definition: compliance monitoring is the planned, risk-based testing of whether controls that address regulatory obligations are designed adequately and operating as described, with findings reported to people who can act on them and tracked until they are fixed. Every clause of that sentence is a design decision, and this lesson takes them in turn.

The international standard for compliance management systems, ISO 37301:2021, frames the same idea in management-system language. It replaced ISO 19600:2014 and, unlike its predecessor, specifies requirements for "establishing, developing, implementing, evaluating, maintaining and improving" a compliance management system, which means an organisation can be certified against it. Evaluation sits in that list alongside implementation: a compliance system that is never tested is, on the standard's own terms, incomplete. Few gambling licensees seek certification, but the structure is close to what regulators expect either way.

Some regulators now say so explicitly. Ontario's Registrar's Standards for Internet Gaming, last updated in May 2026, require operators to have their control activities "assessed by an independent oversight function for alignment with the Standards and Requirements", and place primary accountability for compliance with the board. The Dutch regulator, the Kansspelautoriteit, describes its own supervision as risk-based and data-driven. A licensee whose monitoring is less systematic than its regulator's is in a weak position.

Step one: the compliance universe

You cannot plan testing until you know what there is to test. The compliance universe is the list of testable units, usually built from the obligations register described in lesson 1, grouped into areas a reviewer can test in a single piece of work.

A workable unit is narrower than "responsible gambling" and wider than "the deposit limit field validation". Something like "self-exclusion: registration, enforcement at login and deposit, and marketing suppression" is the right grain: it maps to a cluster of obligations, it has an identifiable control owner, and it can be tested in a few days.

For each unit, record the obligations it covers, the controls that address them, the control owner in the first line, the date it was last tested and with what result, and any incidents, complaints or regulator interest since.

A mid-sized online operator licensed in three or four markets typically ends up with somewhere between forty and a hundred units. Fewer than that and the units are too broad to test meaningfully; many more and the programme turns into an inventory exercise.

Step two: scoring risk and setting frequency

Risk-based is the phrase everyone uses and few programmes operate. In practice it means scoring each unit and letting the score set how often, and how deeply, it is tested.

A simple scoring model uses four factors:

Score each one to three, add them up, and band the result. A common pattern, offered here as a starting point rather than a rule, is that the highest band is tested every year, the middle band every two years and the lowest band on a three-year cycle, with thematic reviews added where the external signal changes during the year.

Two disciplines make the scoring credible. First, write down the rationale for each score, because a reviewer or regulator will ask why a unit was rated low. Second, rescore after any event that should move it: a significant incident, a product launch, a platform migration, a published enforcement case against a competitor that describes a failure you could also have.

Step three: the annual plan

The plan converts the scored universe into work. It lists the reviews planned for the year, the quarter each falls in, the estimated days, and the reviewer.

Leave capacity unallocated. A plan that commits every available day in January will be abandoned by April, because regulators send information requests, incidents need investigation and the business launches things nobody mentioned. Holding back something like a fifth of capacity for unplanned work, and saying so in the plan, is more honest than a plan that is quietly missed.

The plan should be approved by whichever committee receives compliance reporting, and changes to it should be approved the same way. A plan that changes without approval is a plan that can be bent by whoever is most inconvenienced by a review.

Step four: designing a test

A review is only as good as its test script. The script is written before fieldwork, so the reviewer is not deciding what "pass" means after seeing the evidence.

A test script has eight parts:

1. Objective. What question the test answers, in one sentence.
2. Obligation reference. The licence condition, regulation or code provision, by number, so the finding can be traced back.
3. Control description. What the control is supposed to do, who performs it, how often, and with what system.
4. Population. The full set of events the control should have applied to in the period, and where that list comes from.
5. Sample. How many items, how selected.
6. Attributes. The specific things checked on each item.
7. Evidence. What record proves each attribute.
8. Pass criteria. What result counts as effective, decided in advance.

The review tests two things, and they are different. Design effectiveness asks whether the control, if it operated exactly as described, would meet the obligation. Operating effectiveness asks whether it actually operated that way throughout the period. A control can fail either test, and the remediation is different: a design failure needs the control rebuilt, an operating failure needs it enforced.

A worked example: testing self-exclusion

Take a hypothetical operator, licensed in Great Britain and two other markets, testing its self-exclusion controls. The relevant obligations include the social responsibility code provisions on self-exclusion and the requirement that marketing is not sent to excluded customers; the course on Responsible Gambling covers what the rules require. Here the question is how to prove the controls work.

Objective. Confirm that customers who self-exclude are prevented from gambling and from receiving marketing, across every brand on the platform, for the duration of the exclusion.

Population. Every self-exclusion registered in the review period, extracted from the platform database, plus every match against the national multi-operator scheme where one applies. The reviewer reconciles the count against an independent figure, such as the exclusion totals reported in management information or supplied to a regulator, because a population that does not reconcile to what the business has reported elsewhere is itself a finding.

Sample. Forty exclusions, selected randomly across the period, with five deliberately added from the week after a known platform release.

Attributes. For each sampled customer: the exclusion is recorded with the correct start date and duration; no successful login, deposit or bet after the start date; no marketing contact on any channel after the start date; the exclusion applied to every brand the customer held an account with; any attempt to open a new account was detected and blocked.

Evidence. System logs extracted by the reviewer, not screenshots provided by the control owner. CRM dispatch logs. Customer contact history.

Data analytics alongside the sample. Because the attributes are all system events, the reviewer can also run a full-population query: every excluded account, joined to every transaction and every marketing dispatch after the exclusion date. A sample tells you the control usually works. A full-population query tells you whether it ever failed, which is the question a regulator will ask.

Result. Suppose the sample passes, but the full-population query finds three customers who received a promotional push notification after excluding, all from one brand, all in the week after the release. That is a finding, and it is a better one than a clean sample would have produced, because it identifies a specific failure, a specific cause and a specific remediation.

Sampling without pretending to be a statistician

Most compliance testing uses judgemental or simple random sampling rather than formal statistical sampling, and that is acceptable if the method is written down and applied consistently.

Some practical rules:

• Prove the population is complete before sampling from it. Ask where the list came from, check its count against an independent source and check that it covers the whole period. A sample drawn from an incomplete population tests nothing.
• Scale the sample to the frequency of the control. A control performed once a year is tested once. A control performed thousands of times a day needs a sample large enough that a meaningful failure rate would show up, or, better, a full-population test.
• Target as well as randomise. Add items from periods of known stress: system releases, staff turnover, peak events, the weeks after a policy change.
• Do not extrapolate a precision you do not have. If two of forty items fail, report that, and the nature of the failures. Do not report a "95 per cent compliance rate" as if it were a statistical estimate of the population.
• Where the data allows a full-population test, run it. Many gambling controls produce complete system records. Testing all of them is often cheaper than sampling and always more persuasive.

Evidence that stands up

The weakest evidence is somebody telling you the control works. The strongest is the reviewer independently re-performing it from source data. Between the two, in roughly descending order of strength: reperformance, system-generated reports extracted by the reviewer, documents created at the time the control operated, observation of the control being performed, and inquiry.

The working papers should allow someone who was not present to understand what was tested, what was found and why the conclusion follows. That someone may be internal audit, an external auditor, or a regulator conducting a compliance assessment months later, and lesson 5 explains why the working papers are often the first thing they ask for.

Practical standards for evidence: date-stamped, showing the source system, held in a location the business cannot edit, and retained for a defined period aligned to the record-keeping obligations in each market.

Writing a finding

A finding that cannot be acted on has not done its job. Internal auditors write findings using a well-established structure, and compliance teams should borrow it, because it forces the analysis that makes a finding useful. The Institute of Internal Auditors' Global Internal Audit Standards, issued in January 2024 and effective from January 2025, expect working papers for each finding to set out "the criteria, condition, root cause (when possible), effect (risk or potential exposure), and recommendation(s) and/or action plans".

• Criteria. What should happen, with the obligation reference.
• Condition. What actually happened, with numbers.
• Cause. Why the gap exists. This is the part most often skipped and the part that determines whether the fix works.
• Effect. The consequence: consumer harm, regulatory exposure, financial impact.
• Action. What will be done, by whom, by when.

Applied to the worked example: the criteria are that excluded customers receive no marketing; the condition is that three of the excluded customers in the period received a push notification from one brand; the cause is that the release migrated push notifications to a new service which did not consume the exclusion flag; the effect is a breach of the marketing obligation for three customers and a reportable event to consider; the action is to connect the new service to the exclusion flag, add a release test, and run a lookback over the whole period since the release.

Notice that the cause leads somewhere the condition alone does not. "Three customers received marketing" invites a fix for three customers. "A release migrated a channel without the exclusion flag" invites a fix to the release process, which prevents the next one.

Rating findings

A rating scale gives the board a way to read many findings at once. Keep it to three or four levels, define each with criteria rather than adjectives, and calibrate it with examples.

The rating must be the reviewer's, not negotiated with the business. Control owners will push for lower ratings because ratings drive attention and, in many organisations, bonuses. A reviewer may change a rating in response to new facts, and should record when that happens and why.

Remediation tracking and closure

The programme does not end when the report is issued. Most of the value is in what happens next, and most of the published enforcement findings about governance describe what did not happen next.

A remediation tracker records, for each action: the finding it addresses, the owner, the agreed date, the current status, and any extensions with who approved them. Four rules keep it honest:

1. Owners are named individuals, not teams.
2. Dates are agreed, not imposed, but extensions need approval from someone more senior than the owner, and repeated extensions are reported.
3. Closure is validated by the second line, not declared by the owner. The validator re-tests the control, briefly, and records the evidence.
4. Overdue actions are reported upward, with ageing, to the committee that receives compliance reporting.

Where the business decides not to fix something, that is a risk acceptance, and it should be documented, approved at the right level, time-limited and reported. A finding that sits open for two years without a decision is a risk acceptance nobody signed.

What a programme looks like when it works

A reviewer arriving at a business with a working monitoring programme would find, in an afternoon:

• A compliance universe with scoring rationale and dates last tested.
• An approved annual plan with changes recorded and approved.
• Test scripts written before fieldwork, with pass criteria.
• Working papers that let a stranger follow the conclusion.
• Findings with a cause, not only a condition.
• A remediation tracker with named owners, validated closures and an ageing report.
• At least some full-population testing, not only samples.
• Evidence that findings changed something, such as a release process that now includes a compliance test because a review found it missing.

None of that requires specialist software or a large team. It requires the programme to be designed before it is run, and to be finished after it is reported. The next lesson turns from testing what the business does to the reporting that tells the regulator what it did.