Policy is the claim, assurance is the proof
Every licensed gambling business has policies. It has an AML policy, a safer gambling policy, a complaints procedure, a marketing code, an information security policy, and usually a compliance manual that cross-refers to all of them. Regulators have read thousands of these documents, and they have learned that the documents tell them very little. A policy describes what a business intends to do. What a regulator wants to know is whether the business does it, every time, and whether anyone inside the business would notice if it stopped.
That gap, between what is written and what happens, is where most enforcement lives. Read the published outcomes in any mature market and the phrase that recurs is not "had no policy". It is some version of what the Gambling Commission said in its August 2026 public statement on QuinnBet (Gibraltar) Limited: the licensee "had not always ensured that its policies, procedures and controls had been effectively implemented". The policies existed. The proof that they worked did not.
This course is about that proof. The other compliance courses on the Learning Hub teach the rules: Law and Compliance, AML and Financial Crime, Responsible Gambling, Marketing Compliance and Market Entry and Licensing. This one teaches how a licensee demonstrates, day to day, that it is following them: monitoring and testing, regulatory reporting, audits and certification, regulator inspections, what happens when it goes wrong, and the governance that holds it together.
The word for all of that is assurance. Assurance is evidence, gathered by someone with enough independence to be believed, that a control is designed to meet an obligation and is operating as designed.
What regulators actually test
It helps to look at what a regulator says it is doing when it examines a licensee, because the answer shapes everything else.
The Gambling Commission's licensing, compliance and enforcement policy statement, last updated in March 2026, describes compliance work in its chapter on compliance. Assessments are there to check that licensees remain suitable, that activities are consistent with the licensing objectives, and that the Act and the licence conditions and codes of practice are being complied with. Remote assessments may request sight of documents and records, "including customer records and the audit trail in relation to customer accounts". The outcome is rated on a three-point scale: compliant, improvement required, or serious failings.
Notice what that implies. The assessor does not stop at the policy. They follow an obligation from the licence condition, to the procedure that is supposed to deliver it, to the records that show it was delivered, often for specific customers. If any link in that chain is missing, the rating reflects it.
Notice too how the Commission decides where to look. Its chapter on assessing risk says the likelihood of non-compliance is judged partly on staff and management integrity and competence, governance and compliance history, and that operators which "demonstrate good governance and a high level of compliance" will receive less regulatory oversight as a result. Assurance is not only a defence when something goes wrong. A business that can show its controls work earns a lighter touch.
Other regulators phrase it differently and test the same thing. Pennsylvania requires interactive gaming operators to submit their internal controls for approval at least 90 days before launch, and those controls then become the standard the operator is held to. The Malta Gaming Authority can require compliance audits, and its Approved Audit Service Provider Policy recognises only auditors it has approved. The principle is general: regulators regulate evidence, not intentions.
Obligations, controls and evidence
Assurance needs three things lined up: the obligation, the control that meets it, and the evidence that the control operated. The working tool that lines them up is the obligations register.
An obligation is a specific requirement the business must meet, drawn from legislation, licence conditions, codes of practice, regulator technical standards, directives and binding guidance, in every market where it holds a licence. "Comply with AML law" is not an obligation. "Conduct an assessment of the risks of the business being used for money laundering and terrorist financing, and review it at least annually" is. That is close to the wording of the Gambling Commission's licence condition 12.1.1, which also requires policies, procedures and controls to be "implemented effectively, kept under review, revised appropriately to ensure that they remain effective". The condition itself asks for assurance.
A control is the thing the business does to meet the obligation: a system rule, a manual check, an approval, a reconciliation, a report. Every control needs an owner, a frequency and a description precise enough to test.
Evidence is the record the control leaves behind when it operates. If a control leaves no record, it cannot be tested, and for assurance purposes it does not exist.
A register row joins them up. A hypothetical extract for a remote casino licensed in Great Britain might look like this:
| Obligation | Source | Control | Owner | Evidence |
|---|---|---|---|---|
| Notify key events within five working days of becoming aware | LCCP 15.2.1 | Key event log reviewed weekly by compliance; trigger list circulated to finance, legal, HR, IT | Head of compliance | Log with date aware, date reported, eServices reference |
| Submit regulatory returns within 28 days of quarter end | LCCP 15.3.1 | Return prepared by finance, reconciled to ledger, reviewed by compliance before submission | Head of finance | Reconciliation file, reviewer sign-off, submission receipt |
| Annual ML/TF risk assessment | LCCP 12.1.1 | Assessment refreshed annually and on trigger events, approved at board committee | MLRO | Dated assessment, committee minutes |
| Self-excluded customers cannot gamble or receive marketing | Social responsibility code | Exclusion flag checked at login, deposit and dispatch, across brands | Head of player safety | System logs, quarterly test results |
The register has a few properties worth insisting on. It is granular, one row per testable obligation, not one per policy. It is sourced, with the condition number and version, so that when the regulator changes a condition the affected rows can be found in minutes. It is owned, by a named individual in the business rather than by compliance. And it is multi-jurisdictional, with a column for each licence, because a control built for one market is frequently assumed to cover another that has a stricter version of the same rule.
Most licensees that run into trouble have something called a register. What they lack is the second half of each row: a control described precisely enough to test, and evidence that it was tested.
Design and operating effectiveness
A control can fail in two different ways, and the distinction runs through the whole of this course.
Design effectiveness asks: if this control operated exactly as described, would it meet the obligation? A self-exclusion check that runs at login but not on the app's push notification service is a design failure. It does what it says, and what it says is not enough.
Operating effectiveness asks: did the control actually operate as described, consistently, throughout the period? A deposit limit that is correctly designed but was bypassed for several weeks after a platform migration is an operating failure. The QuinnBet statement describes exactly this: a migration error allowed 194 customers to exceed their limits.
The language comes from internal control practice. The COSO internal control framework, originally issued in 1992 and refreshed in 2013, defines internal control in its executive summary as a process "designed to provide reasonable assurance regarding the achievement of objectives relating to operations, reporting, and compliance". Its sixteenth principle expects an organisation to perform "ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning". Present is design. Functioning is operation. A gambling compliance team does not need to adopt COSO wholesale, but borrowing its vocabulary helps, because auditors and many regulators already speak it.
The remediation differs. A design failure needs the control rebuilt. An operating failure needs it enforced, monitored, or protected from change. Teams that do not distinguish the two often respond to an operating failure by rewriting the policy, which changes nothing.
The three lines
The standard way to organise who does what is the three lines model, maintained by the Institute of Internal Auditors. The IIA published an updated Statement of Position on the Three Lines Model on 8 July 2026, replacing its 2020 position paper. The core structure is unchanged:
- First line: management. Owns and manages risks and is responsible for the design and operation of processes and controls. In a gambling business that means payments, customer operations, trading, CRM, product and technology, not compliance.
- Second line: specialist roles. Provide "specialized expertise, support, monitoring, and challenge". Compliance, the MLRO's function, information security and risk sit here.
- Third line: internal audit. Delivers "independent and objective assurance on the effectiveness of governance, risk management, compliance, and control processes".
Three points from the 2026 statement matter for gambling compliance.
First, it is candid about the limits of each line. The first line's objectivity is constrained by ownership and it "may under-recognize or rationalize control weaknesses". The second line is sometimes impaired by reporting through management and "may focus on procedural compliance and monitoring rather than full assurance depth". The third line's coverage is risk-based and periodic, so lower-risk areas are reviewed less often. No single line is enough.
Second, it sets a practical independence test. Assurance is not credible if the reviewer designs or operates the process, evaluates their own earlier decisions, or is influenced by management preferences. The statement suggests a period of at least 12 months between being responsible for a process and providing assurance over it is typically sufficient. A compliance analyst who wrote the self-exclusion procedure in March should not be the person testing it in June.
Third, it is explicit that outsourcing does not change accountability. Many gambling businesses buy their platform, their KYC, their payment processing and sometimes their customer support. The obligation stays with the licensee.
The model is a description of roles, not an org chart. A small operator may not have a separate internal audit team and may buy third-line assurance from an outside firm. What matters is that someone independent of the people running a control checks it, and that someone independent of the people checking it checks them.
The assurance map
Once the register exists and the lines are defined, the assurance map shows who is checking what. It takes the register and adds columns for each source of assurance: first-line self-checks, second-line monitoring, internal audit, external audits and certifications, and regulator reviews. The IIA statement names the assurance map as one of the tools that supports coordination across the lines, reducing duplication and making gaps visible.
Mapped honestly, most gambling businesses find a similar pattern. Payments and AML are tested from several directions at once, because they attract external audits, bank due diligence and regulator attention. Responsible gambling interaction is tested less than its enforcement history warrants. Regulatory reporting and key event notification, which are the subject of lesson 3, are often tested by nobody: finance prepares the return, compliance submits it, and no one checks the numbers against source data until the regulator does.
A map like that tells the board where its confidence is borrowed rather than earned, and it is the natural input to the monitoring plan covered in lesson 2.
Where it goes wrong
The failure patterns are consistent enough to list.
The register describes the law, not the business. It lists obligations but no controls, or controls described as "per policy". Nothing in it can be tested.
The control lives in a person. A check performed by one experienced analyst, never written down, stops when they go on leave. The register says the control exists. It does not, on those days.
Change outruns the register. A platform migration, a new brand, a new payment method or a new market changes how controls operate. Nobody updates the register, and nobody tests the control after the change. The published cases show how often a release or a migration sits at the root of a finding.
Compliance owns everything. When compliance is listed as owner of every control, the first line has handed over its accountability and the second line is marking its own homework. The IIA's independence test fails by design.
Group assumptions. A control built for the strictest market is assumed to cover the others, or one built for a lenient market is assumed to satisfy a stricter one. A per-licence column in the register catches both.
Evidence nobody can find. The control operated, but the evidence is in four systems with no reference linking them, so it takes three weeks to answer a question the regulator expected answered in three days.
A starting checklist
If you are building or inheriting an assurance framework, these questions will tell you where you stand:
- Is there an obligations register at the level of individual conditions and code provisions, for every licence held?
- Does each obligation map to at least one control, described precisely enough that a stranger could test it?
- Is each control owned by a named person in the first line?
- Does each control leave evidence, and do you know where it is kept?
- Is it clear which controls are tested, by whom, how often, and when they were last tested?
- Is the person testing each control independent of the person who designed or runs it?
- When a licence condition changes, how long does it take to find every affected control?
- When the business changes a system, does anyone check whether a control has changed with it?
- Could you produce the full evidence chain for one named customer, from obligation to record, in a day?
None of those questions asks whether a policy exists. That is the point. The remaining lessons take each part of the chain in turn, starting with the programme that tests whether controls work.
The regulatory map is a useful companion while you build a register, because it shows which regulators govern each market and links to their frameworks, and the glossary entries on the LCCP and key event reporting are worth reading alongside this lesson.