ISO 27001 A.5.31: Aligning Gambling Compliance With Regulator Demands

The new compliance crunch in regulated gambling

Annex A.5.31 is the bridge between your gambling obligations and your ISO 27001 ISMS. It expects you to keep a single, governed view of every legal, regulatory and contractual duty that affects information security, and to show how each duty flows into named controls, owners and evidence that stand up to regulator scrutiny. Regulated gambling is also shifting from point‑in‑time audits to continuous proof, and Annex A.5.31 is where that expectation is anchored inside your ISO 27001 ISMS, so you are now expected to maintain a single, governed view of every legal, regulatory and contractual obligation touching information security, and to show how those obligations flow into concrete controls, owners and evidence instead of being buried in scattered documents.

ISO 27001 does not replace gambling law or legal advice; it provides a management‑system structure to implement what those laws require. This guidance is informational and cannot cover jurisdiction‑specific nuances, so you should always seek qualified legal and regulatory advice when interpreting obligations in particular markets.

Regulators increasingly behave more like financial supervisors. Licencing conditions, technical standards, anti‑money laundering (AML) rules, data‑protection law and safer‑gambling expectations have become more prescriptive and data‑driven. Supervisors want to see evidence that you understand your obligations, have translated them into specific controls, and can demonstrate over time that those controls are working.

For many operators that exposes a familiar pattern. You pass an ISO 27001 audit, you have documents from your last licence application, and you can find a handful of risk assessments and change approvals – but none of it is joined up. When a regulator asks “show me how this licence condition is implemented”, you have to reconstruct a storey from scratch. That is precisely the gap A.5.31 exists to close.

When obligations are fragmented, you end up defending your governance, not just your controls.

This is also a high‑stakes domain. Weaknesses in AML, game integrity or player‑data protection are no longer treated as isolated technical problems. They are framed as failures of governance and culture. Regulators now routinely ask whether boards and senior management have effective oversight of information‑security and compliance risks. If you treat Annex A.5.31 as an IT formality instead of a governance backbone, those questions become much harder to answer.

At the same time, your commercial reality is increasingly cross‑border. A single group may hold dozens of licences across Europe and beyond, each with slightly different conditions, incident‑reporting rules and security expectations. Trying to track all of that in country‑by‑country spreadsheets inevitably leads to stale information, inconsistent interpretations and missed dependencies.

A practical way forward is to treat ISO 27001:2022 – and A.5.31 in particular – as the organising framework for this complexity. Rather than building one “compliance system” for licencing and another for ISO, you can use A.5.31 to bring gambling rules, AML obligations, data‑protection law and contracts into one obligations spine inside your ISMS. In practice, your ISMS might be implemented on a platform such as ISMS.online, but the principles below apply regardless of tooling.

Why regulators now expect continuous evidence, not point‑in‑time files

Gambling regulators now expect a living evidence trail that shows how obligations are identified, owned and tested over time, rather than a static pack assembled for each inspection. That moves you away from one‑off licencing files towards an obligation‑centred ISMS where Annex A.5.31 joins regulatory requirements directly to controls, owners and records that evolve with your business.

Under a point‑in‑time model, you build a licencing pack, complete a technical audit, pass the assessment, and then move on. Under a continuous‑assurance model, regulators and auditors want to see how you keep track of obligations, how changes are identified and assessed, how responsibilities are allocated, and how decisions are recorded over time. They may also revisit past incidents and ask how lessons learned were embedded into governance, not just into a single technical fix.

For online gambling this is especially important because your risk profile changes quickly. You launch new games and features, enter and exit markets, adjust know‑your‑customer (KYC) thresholds, onboard new payment providers, and evolve your technology stack. Annex A.5.31 gives you the lever to show that regulatory and contractual requirements move alongside those changes rather than lagging behind them.

Book a demo

What ISO 27001 A.5.31 really asks you to do

Annex A.5.31 requires you to maintain a current, structured view of all legal, statutory, regulatory and contractual requirements that affect information security, and to show how they are reflected in your controls and everyday practice. For a gambling operator, that means upgrading a legal‑obligations list into a governed process that links duties to owners, risks, controls and evidence, including gambling licences and conditions, AML and counter‑terrorist‑financing obligations, data‑protection law, technical standards, and security‑relevant contract clauses with suppliers and partners.

Seen that way, there is a clear difference between “we have a legal‑obligations spreadsheet somewhere” and “we run A.5.31 as a governed process”. A spreadsheet might contain a list of laws and licences; A.5.31 expects you to have responsibilities, interpretations, mappings to controls and a review cycle. The control is less about the document itself and more about the way you manage and evidence your compliance.

A useful way to think about A.5.31 is as a pipeline: discover, interpret, record, implement, monitor and review. Each step needs defined roles, inputs and outputs. If any part of that pipeline is missing or informal, auditors and regulators will quickly find the weak spots.

The objective and scope of A.5.31 in plain language

The simplest way to describe A.5.31 is that it joins the outside world of laws and licences to the inside world of your ISMS in a disciplined, auditable way. It forces you to decide which obligations apply, what they mean in practice, and how they shape your information‑security controls and evidence for auditors and regulators.

In gambling, the objective of A.5.31 is to ensure that your ISMS is aligned with all relevant external and contractual requirements, and that you can prove it. This typically covers:

Gambling and gaming legislation and associated regulations
Licence conditions and codes of practice issued by regulators
Remote technical standards and security requirements
AML/CTF laws and guidance, including KYC and transaction‑monitoring obligations
Data‑protection and privacy law affecting player, staff and partner information
Consumer‑protection and responsible‑gambling rules where they drive information‑related controls
Contractual commitments with operators, platforms, content providers, payment‑service providers and other partners that include security or compliance clauses

Under A.5.31, you are expected to know which of these apply to your scope, document them in a structured way, and make sure they influence the design and operation of your ISMS. That includes both central group obligations and those that apply only in specific jurisdictions or to specific products.

From obligations list to governed process

Turning A.5.31 from a static document into a governed process means building a repeatable lifecycle for discovery, interpretation, recording, implementation and review. When each step has named roles, clear inputs and visible outputs, regulators can see that your compliance position keeps pace with your markets, portfolio and technology, rather than being rebuilt for each audit.

Instead of one long numbered list, it often helps to treat this as a series of simple steps.

Step 1 – Systematically identify obligations

Define explicit activities and sources for discovering obligations: regulator websites and circulars, legislation updates, legal opinions, licence conditions, contract reviews and industry guidance. This discovery work is planned and assigned, not left to informal email forwarding.

Step 2 – Interpret and classify requirements

Translate legal or regulatory text into what it means for information security. An incident‑reporting rule, for example, becomes a requirement for specific logging, classification and communication controls. Classify each item by type and theme so you can philtre it later.

Step 3 – Record obligations in a controlled register

Record obligations in a version‑controlled register with identifiers, owners, affected entities and links to controls, policies and evidence. The register is part of your ISMS documentation set, not a private file held by a single team.

Step 4 – Map obligations to controls and policies

Decide which existing controls address each obligation or whether new ones are required. Map obligations to Annex A controls, internal policies, procedures and technical measures. This mapping later supports your Statement of Applicability and risk‑treatment plans.

Step 5 – Monitor and review

Define how often obligations and their mappings are reviewed, who signs them off, and how changes are triggered – for example, when a regulator updates a guideline or when you enter a new market. Internal audit and management review use this information as part of their assurance work.

In a mature implementation, these steps form a loop that runs throughout the year rather than a project you revisit only before audits and licence renewals.

ISMS.online gives you an 81% Headstart from the moment you log on

ISO 27001 made easy

We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.

Get started

The gambling obligations universe: laws, licences, AML, data, technical

Your obligation universe is broader than a single gambling act in each country, and A.5.31 only works if you can see that full picture clearly enough to assign owners and link rules to real controls. Grouping requirements into a small set of recurring themes makes it easier to understand where information security really sits and to build a register that reflects how your business operates. For A.5.31 to be effective in gambling, you therefore need a clear view of the obligation universe you are dealing with – a universe that is always bigger than the headline gambling act in each market, spanning licencing conditions, AML and counter‑terrorist‑financing regimes, data‑protection law, technical standards, consumer‑protection rules and more, and looking different for each operator depending on the markets and products you offer.

Rather than trying to capture every nuance at once, it is helpful to think in categories. You systematically list and group obligations into a handful of recurring themes, then refine from there. This makes it easier to assign owners, assess impact and link to controls.

Visual: simple obligations‑universe map with categories, examples and tiering.

Core categories of gambling obligations

Most regulated online operators can understand their regulatory world faster by sorting obligations into a few clear categories. These categories become the spine of your A.5.31 register and the language you use when discussing risks, controls and evidence with senior stakeholders, and most operators will face at least the following categories of external obligations, which you can use as organising headings in your register:

Core gambling and gaming legislation. Primary acts and regulations that define what gambling is, what is permitted, and what licences you must hold, often with high‑level governance and control requirements.

Licence conditions and codes of practice. Detailed conditions attached to each licence, including requirements for information security, incident reporting, changes to key equipment, outsourcing, reporting of key events and record‑keeping.

Remote technical standards and security requirements. Technical specifications that set rules for random‑number generators, game fairness, logging, segregation of environments, encryption, penetration testing and change management.

AML/CTF and financial‑crime obligations. Laws and guidance on KYC, customer due diligence, ongoing monitoring, suspicious‑activity reporting, sanctions, source‑of‑funds checks and record retention.

Data‑protection and privacy law. Requirements governing collection, storage, use, transfer and deletion of personal data, including players, staff and partners, often with breach‑notification expectations.

Consumer‑protection and responsible‑gambling rules. Obligations around marketing, self‑exclusion, affordability, monitoring for signs of harm and interactions with at‑risk customers, many of which rely heavily on data quality and security.

Contracts and third‑party requirements. Security and compliance obligations embedded in contracts with operators, platforms, content providers, payment processors, hosting providers and other suppliers.

Not every detail in these sources will fall under A.5.31, but anything with an information‑related angle – confidentiality, integrity, availability, logging, reporting, decision‑making or record‑keeping – is a strong candidate.

Prioritising what matters most for information security

To avoid drowning in detail, you should sort obligations by criticality for information security and regulatory risk, so A.5.31 effort lands where it counts most. Simple tiers and tags help you signal which items demand tight mapping and which mainly shape good practice, without pretending that everything is equal.

Trying to treat all obligations as equal is a recipe for overload. A more practical approach is to tier and tag them by their relevance to information security and regulatory risk. For example:

Tier 1 – High impact.: Breach could cause licence loss, major fines, serious player harm or large‑scale data compromise.
Tier 2 – Medium impact.: Breach would likely lead to remediation requirements, increased scrutiny or moderate sanctions.
Tier 3 – Lower impact.: Advisory guidance and soft‑law expectations that inform good practice but may not all need direct control mappings.

Within your register, you can record both the category (for example, AML or data protection) and the tier. That helps you focus A.5.31 implementation effort where it matters most and design your control set proportionately. It also produces a clearer picture for senior management and the board when they review compliance and risk reports.

Before you design your register, it helps to capture this obligations universe in a simple visual format so colleagues can see how external rules cluster and where A.5.31 will concentrate your effort.

A simple example of obligation categories and their A.5.31 focus is shown below.

Category	Typical examples	A.5.31 focus
Licencing & corporate	Licence conditions, fit‑and‑proper criteria	Map security‑relevant clauses to named control owners
Technical & platform	RTS, game integrity, incident rules	Align regulator themes with technical and operational controls
AML / financial crime	KYC, monitoring, reporting, retention	Link AML requirements to data and system controls
Data protection & privacy	Lawful basis, rights, breach notification	Align ISMS controls with privacy obligations
Consumer protection & RG	Self‑exclusion, marketing, affordability	Ensure systems support safer‑gambling obligations
Contracts & third‑party risk	SLAs, security addenda, supplier obligations	Capture contractual duties and assign oversight

You can expand or refine these rows to reflect your specific portfolio, but even a simple structure like this is a strong starting point for A.5.31.

Designing a multi‑jurisdiction regulatory obligations register

A multi‑jurisdiction obligations register is the backbone that lets you prove to regulators and auditors that every licence condition and legal duty has a clear owner, interpretation and mapping to controls. For a Group Head of Compliance or CISO, it also becomes the primary lens for understanding where regulatory risk really sits across markets, products and brands. Once you understand the obligation universe, you then need a place to put it: the obligations register that Annex A.5.31 expects you to maintain, which for a gambling group operating across multiple jurisdictions must be rich enough to capture nuance but structured enough to be searchable, reportable and auditable.

You can think of the register as the authoritative spine that connects regulators’ words to your internal controls and records. It is not just for the ISO auditor; it is the same spine you will lean on when preparing licence applications, answering regulator questions or structuring board reports.

Visual: lifecycle loop showing discovery, interpretation, recording, implementation and review.

Designing the data model for your obligations register

A strong obligations register starts with a clear data model that captures what a regulator cares about – who is responsible, what the rule means, how it is implemented – in a way your teams can actually maintain. The right fields make it easy to philtre by regulator, market, licence or theme, and to show both coverage and gaps under pressure, and in practice a robust multi‑jurisdiction obligations register usually includes at least the following fields:

Unique obligation ID and short label
Source type and reference such as section or condition number
Jurisdiction, regulator and affected licences or entities
High‑level category such as AML, data protection, technical standard or responsible gambling
Tier or criticality rating for information‑security and regulatory impact
Plain‑language summary and information‑security relevance note
Linked ISO 27001/27002 controls, including A.5.31
Linked internal policies, standards and procedures
Linked operational controls, systems or platforms
Key evidence sources such as logs, reports, tickets or approvals
Control owner(s), accountable executive, dates and review cycle
Status such as implemented, partially implemented, planned or retired

On paper this seems detailed, but with a sensible user interface and philtres it becomes a powerful tool. Compliance directors can philtre by regulator and see everything relevant to a particular licence. Security teams can philtre by ISO control to understand which obligations a given measure supports. Internal audit can philtre by tier and status to plan assurance work.

A specialised ISMS platform such as ISMS.online can simplify this by providing configurable registers, relationships between entries and workflow, but the same principles apply if you build your own structure using more basic tools.

Processes to keep the register current and trustworthy

To answer the inevitable “how do you keep this up to date?” question, you need a visible lifecycle that shows how regulatory changes enter the register, get interpreted, drive control changes and are signed off. When that lifecycle is clear, the register becomes a trusted source of truth rather than just another spreadsheet, and a good data model is only valuable if the information it contains is current and trusted, which means building processes around the register that mirror the lifecycle of regulatory change. Typical steps include:

Step 1 – Monitor external sources

Assign responsibility for watching regulatory sources, legal updates and industry communications. In gambling, that might include regulator websites, newsletters, legal briefings, trade bodies and horizon‑scanning tools.

Step 2 – Capture proposed changes

Log new or changed obligations as draught entries with initial classification and references. Make it clear which markets and licences might be affected.

Step 3 – Analyse and interpret impact

Ask legal and compliance specialists to interpret what the change means for your operations and information security. Where needed, they consult product, security, AML or data‑protection teams to test practical implications.

Step 4 – Decide and approve responses

Decide what adjustments are needed to controls, policies, systems or processes and record those decisions. Capture approvals and rationale alongside the obligation entry so they can be revisited later.

Step 5 – Implement and link evidence

Implement changes through your change‑management, risk‑treatment and project processes. Update the register with links to new or amended controls and to the evidence sources that will show those controls working.

Step 6 – Review and refine

Update the obligation record to reflect its status once changes are embedded. Periodic reviews ensure that interpretations remain correct and that obligations still reflect your current portfolio and technology.

When regulators ask how you stay up to date with their rules, walking them through this lifecycle – supported by a live register – is far more convincing than pointing to ad‑hoc email chains or unstructured shared folders.

Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.

Book your demo

Mapping gambling regulator rules into A.5.31 and the wider ISO 27001 ISMS

Mapping obligations into your ISMS turns A.5.31 from a compliance catalogue into a practical navigation tool for audits, licences and change decisions. When each key rule is linked to Annex A controls, policies, procedures, systems and evidence, you can answer regulator questions in minutes rather than days and spot duplication or gaps before they cause trouble, and having a register is necessary but not sufficient, because A.5.31 also expects you to connect each obligation to your controls and operations, which for a gambling operator means mapping regulator rules and licence conditions to ISO controls, internal policies, procedures and supporting systems.

This mapping work has practical benefits far beyond ISO certification. It allows you to answer questions such as “which controls support this licence condition?” or “if we change this KYC rule, which systems and jurisdictions are affected?”. It also helps you avoid duplication and conflicting measures arising from independent interpretations of similar requirements.

Building a regulator‑to‑control mapping matrix

A regulator‑to‑control mapping matrix makes your obligations register usable under pressure by starting with each rule and fanning out to the controls, processes, systems and evidence that support it. That matrix becomes your default response engine for regulators, auditors and internal stakeholders who need to see how specific requirements are met in practice, and a useful technique is to build this mapping directly into your obligations register so that, for each record, you include:

The specific obligation and its short summary
The Annex A control or controls it relates to, such as A.5.31 plus relevant technical or organisational controls
The internal policy or standard that explains how you meet the obligation
The procedures or playbooks that describe detailed steps
The systems, tools or configurations that implement the control
The primary evidence types you rely on, such as logs, reports, tickets or test results

When a regulator asks about a particular theme – for example, incident reporting or game integrity – you can philtre the matrix to show all relevant obligations, the associated controls and the evidence. That is far easier than constructing bespoke answers each time.

From an ISO 27001 perspective, this mapping also feeds into your Statement of Applicability. The SoA is where you document which Annex A controls are in place, why, and how they are implemented. When you can show that control selection and justification are influenced by specific regulatory obligations from your A.5.31 register, auditors usually see that as a sign of maturity.

Avoiding duplication and gaps across frameworks

To keep your control set manageable, you need to reuse controls across frameworks wherever possible and only create new ones when genuinely different requirements arise. Tagging controls with the frameworks and obligations they support avoids a sprawl of near‑duplicate measures that waste effort and confuse owners.

One risk when mapping multiple frameworks – ISO 27001, gambling regulation, AML, data protection, local standards – is ending up with parallel control sets that overlap but are named or managed differently. That can lead to duplicated work, inconsistent implementation and confusing evidence.

To avoid that, it helps to design your control framework with reuse in mind:

Start from a reasonably complete internal control library aligned to ISO 27001 and related standards.
Map external obligations to those internal controls wherever possible, instead of adding “new” controls for each framework.
Use tags and attributes on controls to show which frameworks and obligations they support.
When truly distinct new requirements arise, extend the control set deliberately and update mappings accordingly.

This approach lets you explain to a regulator that the same access‑control measures protecting player data under data‑protection law also support technical‑standards requirements and AML transaction‑monitoring systems. You can then show how those controls are tested and what evidence you retain.

A structured ISMS platform can make these relationships more visible and maintainable, but the principle holds even in a simple environment: one coherent control set serving many masters, anchored and explained by A.5.31.

Turning A.5.31 into audit‑ready evidence for licences and renewals

If A.5.31 is the spine, your evidence is the muscle that proves you can actually move, and regulators judge you on how quickly and coherently you can produce it. By designing your ISMS artefacts for reuse, you can serve ISO audits, licence applications and thematic reviews from the same well‑organised library instead of reinventing the wheel each time, because regulators and ISO auditors ultimately judge you on evidence and Annex A.5.31 gives you the structure to know which evidence you should have, while your implementation decides whether that evidence is easy to retrieve, coherent and credible.

A strength of using ISO 27001 as your management‑system spine is that many of its artefacts are exactly what gambling regulators like to see: clear policies, risk assessments, control descriptions, incident logs, change records, audit reports and management‑review minutes. When those are explicitly linked to your obligations register, you can use them for both ISO audits and licencing events.

What evidence regulators typically expect to see

Across markets, regulators tend to ask for similar categories of information that all connect back to the way you manage obligations under A.5.31. If you design your ISMS documentation with these categories in mind, you reduce surprises and can answer detailed questions with existing, well‑understood artefacts.

Common evidence types that intersect with A.5.31 include:

Obligations and responsibilities. A central register of applicable laws, regulations, licence conditions and contractual requirements, together with clear allocation of responsibilities and escalation routes.

Policies and standards. Documents that translate obligations into organisational rules: information‑security, AML, data‑protection, change‑management and incident‑management policies and standards.

Risk assessments and treatments. Records showing how you assess and treat risks associated with obligations, especially in high‑impact areas such as player data, financial crime, game integrity and third‑party services.

Control‑operation evidence. Logs, reports and tickets showing that controls are working: access‑reviews, monitoring alerts, vulnerability assessments, change‑approvals, investigation records, KYC checks and transaction‑monitoring cases.

Incident and key‑event handling. Registers of security and compliance incidents, key events reported to regulators, investigations, root‑cause analyses and remediation actions.

Governance and review. Minutes and packs from risk committees, compliance forums, internal‑audit reviews, ISO management‑review meetings and board updates where obligations and control performance are discussed.

When you have implemented A.5.31 well, each of these evidence items can be connected back to specific obligations in your register. That gives regulators confidence that you are not just generating documents for their benefit; you are running a system that you rely on yourself.

Reusing ISO 27001 artefacts for licence applications and reviews

By planning for reuse, you can answer regulator questions with existing ISO 27001 artefacts instead of building new packs for every application, renewal or thematic review. The more often you lean on the same obligations register, mappings and reports, the more confident your teams become in using them under scrutiny.

To make evidence work hard for you, you can design your ISMS documentation with reuse in mind:

Obligations register. Drives both A.5.31 compliance and the list of laws and conditions you include in licence applications or responses to regulator questionnaires.

Control mappings and Statement of Applicability. Provide a ready‑made explanation of how you meet security‑related licence conditions and technical standards, which can be adapted into application narratives.

Risk‑treatment plans and change logs. Form part of your explanation when regulators ask about how you assessed and mitigated specific risks, particularly after incidents or thematic findings.

Internal‑audit and management‑review outputs. Demonstrate a culture of continuous improvement and oversight, which most regulators explicitly look for when judging suitability.

Before major licence events – new applications, renewals, significant corporate changes – you can run focused internal reviews that walk through likely regulator questions using these artefacts. That process not only surfaces gaps early; it also trains your subject‑matter experts to use A.5.31 records as their primary reference when answering questions, leading to more consistent and confident responses.

ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.

Book your demo

Operating model: governance, KPIs and a culture of compliance

A.5.31 is only convincing if your operating model shows that obligations are actively governed, measured and discussed, not just documented. Regulators pay close attention to who owns which decisions, how issues are escalated, and whether your committees and leaders use obligation data to steer behaviour rather than simply file reports, and technology and documentation cannot sustain A.5.31 on their own, which is why regulators increasingly examine how your organisation is governed: which committees see what information, how issues are escalated, how decisions are made and how culture is reinforced, in practice assessing whether your operating model supports the obligations you have recorded.

A strong A.5.31 implementation therefore needs to sit inside a wider governance and assurance framework. That framework connects obligations to risks, controls, performance measures and behaviour. It also defines how you learn from incidents and findings.

Governance that makes A.5.31 sustainable

To make A.5.31 sustainable, you need governance structures that give obligations a regular place on the agenda and make it clear who is accountable for keeping the register accurate and the controls effective. When that structure is visible, regulators are more likely to trust that compliance is embedded rather than bolted on.

A typical governance setup that supports A.5.31 in a gambling operator includes:

Clear accountability at the top, usually with a named executive accountable for regulatory obligations and a senior security leader accountable for the ISMS
A cross‑functional compliance forum where legal, compliance, AML, responsible‑gambling, security, product and operations teams review obligations, incidents and control issues
Integration with risk and audit committees, including summaries of new obligations, key risks, remediation progress and external developments
Documented roles and RACI so it is clear who monitors regulators, who maintains the register, who interprets changes, who owns controls and who assures effectiveness
A single mechanism for logging and tracking issues related to obligations, including near‑misses, with root‑cause analysis and aggregated reporting

When regulators or auditors ask about “culture of compliance”, these structures – and the records they generate – are often what they have in mind. They want to see that obligations are not just documented but actively discussed, challenged and improved.

KPIs and culture signals regulators look for

A small set of well‑chosen metrics can show both your board and your regulators that A.5.31 is being managed deliberately rather than left to chance. Those metrics also help you spot drift early and direct attention to obligation categories or markets where control design or execution is weak.

To demonstrate that A.5.31 is working as intended, you can define a concise set of indicators that reflect both process health and cultural adoption. Examples include:

Percentage of obligations with an assigned owner, mapped controls and defined evidence sources
Proportion of obligations reviewed on schedule in the last twelve months
Number and severity of findings related to obligations in internal or external audits
Time taken to assess and implement responses to new or changed obligations
Training‑completion rates for staff whose roles are directly affected by specific obligation categories

These metrics are useful internally and, in summarised form, can also reassure regulators and boards that you are measuring and managing obligations in a disciplined way.

Culture is harder to quantify, but regulators will draw inferences from how consistently staff can explain their role in meeting obligations, how collaboratively teams respond to issues and whether difficult truths are surfaced or buried. A strong A.5.31 process, well communicated, helps create a shared language for these conversations and signals that compliance is part of how you run the business, not just a project.

Book a Demo With ISMS.online Today

ISMS.online helps you turn Annex A.5.31 from a static obligations list into a practical governance backbone for gambling‑sector compliance, so you can connect multi‑jurisdiction licence conditions, AML scrutiny and data‑driven supervision to the controls, owners and evidence that keep your business safe.

With ISMS.online, you can maintain a single obligations register that maps each entry to ISO 27001 controls and internal policies, and link those mappings to live evidence drawn from your everyday work. That makes it much simpler to show how specific licence conditions, AML expectations or data‑protection rules are implemented in your systems and processes.

You can also move beyond fragile spreadsheets and document silos. Compliance, legal, AML, product, security and internal‑audit teams can all work from the same governed source of truth, each seeing the views and reports they need. When regulators ask how a particular licence condition is implemented across markets, you can trace from the obligation to the control, owner and records quickly, instead of assembling explanations under pressure.

If you are preparing for an ISO 27001:2022 transition, planning a new licence application, facing a thematic review or simply want to replace ad‑hoc processes with a coherent A.5.31 backbone, it is worth seeing how this can look in practice. A short demonstration tailored to your markets and licences will show how your current obligations registers, policies and evidence can be brought together into a living ISMS that satisfies both auditors and gambling regulators.

Choosing the right tooling will not replace the need for clear thinking, good governance and legal advice. It will, however, make it far easier for you to prove that those elements exist and are working. If you value fewer last‑minute scrambles, more predictable licence interactions and a stronger storey for your board, booking a demo with ISMS.online is a practical next step you can take in your own time.

Frequently Asked Questions

How does ISO 27001 A.5.31 actually shift your licencing conversations with gambling regulators?

ISO 27001 A.5.31 changes licencing conversations by letting you prove that every security‑relevant obligation is identified, interpreted, controlled and evidenced in a single, governed process. Instead of explaining isolated policies, you can show regulators a live chain from licence clause to control to operating proof across brands and markets.

How A.5.31 reframes you from “explaining documents” to “demonstrating control”

Regulators such as the UKGC, MGA or state authorities increasingly assess how you manage obligations over time, not whether you own a set of one‑off policy PDFs. With A.5.31 built into your ISMS you can:

Start at a specific licence condition, technical standard or safer‑gambling rule and show how it’s interpreted for information security and operations.
Move directly into mapped ISO 27001 controls and internal standards that enforce that interpretation.
Drill into concrete records – change tickets, game release sign‑offs, transaction‑monitoring alerts, incident reviews – that show controls running in real life, not just on audit day.
Evidence reviews where you re‑assessed the obligation after a new market launch, product change or regulator update.

In a licencing interview, that looks very different from walking through a folder of documents. You are effectively telling a clean storey: “Here is the duty, here is the control library that fulfils it, and here is how we know it’s working across all our gambling platforms.”

Why this matters for licence applications, reviews and enforcement cases

When regulators are deciding whether to grant, extend or restrict a licence, they are weighing the risk that your organisation will miss or mishandle important duties. An active, A.5.31‑driven obligations process:

Reduces the chance that an obligation is completely overlooked when you add a new brand or enter a new jurisdiction.
Makes it easier to show that similar obligations across UKGC, MGA and other regulators are treated consistently.
Gives your senior team a better early‑warning view: you see where obligations have no mapped control, stale evidence or unclear ownership before an inspector points it out.

If you keep that chain inside an ISMS such as ISMS.online, you can demonstrate this live: navigate from a clause to the obligation record, open the linked controls, and show supporting evidence on screen. That level of traceability usually carries more weight than narrative explanations alone and can put you in a stronger position when regulators are deciding on licence conditions or sanctions.

Which gambling‑specific obligations are most important to include under ISO 27001 A.5.31?

For A.5.31, you should focus on any obligation that changes how you collect, process, protect, monitor or retain information in your gambling environment – whether that obligation comes from gambling law, technical standards, AML regimes, privacy rules or key contracts. The test is simple: if failing it could weaken game integrity, platform availability, customer protection or reporting to authorities, it belongs in your register.

Priority obligation groups for online and land‑based gambling operators

While every operator’s mix is different, most find it useful to prioritise:

Licence conditions and codes of practice: – especially clauses on security of remote gambling systems, outsourcing, key events, reporting timelines and incident disclosure.
Remote technical standards and testing rules: – requirements for RNG security, change management, environment segregation, access control, logging and independent verification.
Financial‑crime and AML regimes: – obligations on customer due diligence, ongoing monitoring, transaction analytics, reporting thresholds and record‑keeping durations.
Safer‑gambling and customer‑interaction rules: – triggers for financial checks, interaction workflows and account restrictions that depend on accurate, timely data.
Data‑protection and privacy laws: – GDPR and local equivalents for player and staff data, including lawful basis, consent, retention and data‑subject rights.
Critical supplier and platform contracts: – information‑security, availability, DR, audit, data‑processing and notification clauses in agreements with platforms, PSPs, game studios and hosting providers.

Treat these as the backbone of your obligations register, then add local market nuances (for example, separate AML statutes or safer‑gambling codes) as structured entries. Recording them in a common format – source, jurisdiction, category, impact, interpretation – keeps the picture coherent even as your portfolio grows.

How this helps you avoid blind spots in new markets or products

Once those high‑impact obligation groups are consistently captured under A.5.31, you can:

Run quick checks before launching a new brand or product: “Which AML and technical‑standard obligations apply here and how are they already controlled?”
Spot conflicts where two regulators expect different behaviours from the same system, and escalate those for design decisions early.
Show regulators that you know which obligations drive your game integrity, wallet, KYC or safer‑gambling systems, rather than treating security as a generic background concern.

Using a structured ISMS such as ISMS.online to hold this register means legal, compliance, information security and operations can all work from the same governed view, instead of juggling separate, partially overlapping spreadsheets that nobody entirely trusts.

How should a gambling operator design an A.5.31 obligations register that still works at 10+ licences?

A register that survives 10+ licences and multiple regulators needs enough structure to philtre, slice and maintain entries without collapsing under its own weight. The practical goal is that anyone – from compliance analyst to CISO – can answer a focused question such as “show me all high‑impact AML obligations for Brand B under Regulator X” in a couple of clicks.

Core data fields that make A.5.31 work at scale

An A.5.31 entry that can support that level of questioning typically includes:

Identifier and short label: – a code and brief title people can use verbally (“LC‑UKGC‑17 – Remote gambling system security”).
Source and citation: – licence condition, code of practice, technical standard, AML law, guidance note or contract clause with specific references.
Jurisdiction and regulator: – country or state, and which authority issued or enforces the obligation.
In‑scope entities and assets: – brands, licences, game servers, wallets, data centres or vendors affected.
Category and impact rating: – for example, “Remote technical standard – high”, “AML monitoring – high”, “Marketing consent – medium”.
Plain‑language interpretation: – what this really means for systems, data and processes; for example, “all game code changes must be authorised, tested and logged before going live”.
Mapped controls and policies: – Annex A controls, internal standards and specific run books that enforce the interpretation.
Evidence sources: – where someone can find proof: ticket queues, test reports, audit logs, incident files, monitoring dashboards.
Owner and accountable sponsor: – who maintains the entry and which executive owns the risk; review dates and status (current, in review, at risk).

Once those fields exist, you can scale horizontally – new regulators, brands or platforms become more rows that share categories, impact ratings and mappings, rather than demanding a fresh spreadsheet each time.

Why moving from spreadsheets to an ISMS becomes unavoidable over time

Spreadsheets are a good sketchpad for a first obligations register, but they struggle when you:

Need audit‑quality change tracking, approvals and review history.
Want to trigger tasks when impact ratings change or deadlines approach.
Have to present filtered views live to regulators or ISO 27001 auditors.

An ISMS such as ISMS.online lets you keep the same data model but adds workflow, reminders, access control and dashboards. You can, for example, philtre to “all high‑impact safer‑gambling obligations touching this new casino brand”, open an entry, and immediately jump into the linked controls and evidence. That kind of agility tends to calm inspections and reduces the overnight scramble many operators recognise all too well.

How can we connect gambling regulator requirements to ISO 27001 controls without creating three versions of every control?

The most efficient pattern is to treat ISO 27001 and your internal standards as the shared library of “how you run security”, and treat licence conditions, technical standards, AML rules and privacy laws as “why you run security this way”. You then map many “whys” onto each “how”, instead of building duplicate control sets for each regulator.

A practical three‑step mapping approach for gambling environments

You can apply a simple, repeatable pattern:

Rewrite each requirement into operational security language
Take the legal or technical wording and express it in terms your teams act on: “who” must “do what” to “which system/data”, “how often” and with “what evidence”. For example, “all production wallet changes must be peer‑reviewed, tested and logged before deployment”.
Tag the existing controls that deliver that behaviour
Map that operational statement to one or more Annex A controls (for example, change management, access control, logging, supplier management) and to specific internal standards, workflows or playbooks that enforce it. Tag the control with all relevant regulators and regimes – UKGC technical standards, MGA, AML law, GDPR, contract clauses – instead of building parallel versions.
Link through to proof so the map is testable
Attach links or references from the control to real records: change tickets, sign‑off emails, test results, monitoring outputs. That way, the path from obligation to evidence is navigable by anyone with access, not just the one person who remembers where things live.

By keeping the mapping in an ISMS like ISMS.online, you avoid the drift that comes from maintaining the same mapping logic in five different diagrams. You can update the control once (for example, to add extra logging for a new regulator), and that change is automatically reflected in every obligation record that references it.

How this reduces maintenance and improves your storey to boards and regulators

Over time, this mapping pattern:

Cuts down the number of unique controls you have to maintain for each new licence or regime.
Supports a stronger narrative: “We run a single, well‑designed control set that supports UKGC rules, AML expectations and GDPR principles together.”
Helps internal audit and risk teams focus on control effectiveness rather than hunting for where requirements are duplicated or contradicted.

When you can show a regulator that the same hardened control protects game integrity, AML monitoring and player data under several legal regimes, you are demonstrating maturity and efficiency, not just compliance volume.

What types of A.5.31 evidence should a gambling operator be ready to produce at short notice?

Regulators and ISO 27001 auditors are looking for two things: that you know which obligations apply to you, and that you can show – without weeks of preparation – how those obligations are enforced day‑to‑day. A.5.31 provides the structure for this, but the weight comes from the evidence you attach and how quickly you can surface it.

Evidence families that typically satisfy both ISO 27001 and licencing reviews

You should expect to provide, often on tight deadlines:

A current obligations register: – covering laws, licence conditions, technical standards, AML and safer‑gambling rules, privacy laws and key contractual duties, with owners, impact ratings and review dates.
Policies and standards derived from those duties: – information security, access control, logging and monitoring, change control, supplier management, AML and data‑protection standards that clearly reference the obligations they support.
Mappings and a Statement of Applicability (SoA): – showing which Annex A controls are in place for different obligation categories and why any controls are excluded or adapted.
Risk assessments and treatment plans: – especially for high‑impact areas such as game integrity, payment systems, KYC/AML processes and player‑protection mechanisms.
Operational records over time: – change tickets, deployment logs, test reports, fraud and safer‑gambling cases, incident files, escalation records and monitoring outputs that demonstrate consistent control operation.
Governance artefacts: – minutes, packs and actions from boards, risk committees, compliance forums and ISO management reviews where you considered obligations, incidents, findings and remediation.

Designing these artefacts with re‑use in mind is critical. When they are all referenced from the same ISMS environment, you can serve both ISO surveillance audits and a regulator’s thematic review from the same library, rather than building separate evidence piles from scratch.

Making evidence retrieval quick enough for real regulatory timelines

It is common for regulators to set response windows measured in days, not months. If your A.5.31 implementation lives inside an ISMS such as ISMS.online, you can:

Philtre the obligations register by regulator, brand, product type or impact level.
Open a specific obligation record and jump directly into the mapped controls and linked records.
Export focused bundles – for example, “all evidence for remote technical standards on game servers in Jurisdiction X over the last 12 months”.

That responsiveness not only reduces internal stress; it also signals to regulators that you are in control of your obligations process, not scrambling to piece things together only when someone asks difficult questions.

How can we turn ISO 27001 A.5.31 from a static list into something our gambling teams actually use?

A.5.31 only convinces regulators and auditors if it is visibly alive: new obligations are captured, interpretations are challenged, mappings are updated, and real decisions change because of what the register shows. The difference between a static list and a living obligation process is governance – who meets, what they review, and how those decisions are recorded.

Governance habits that bring A.5.31 into everyday gambling operations

Operators that earn positive remarks from regulators usually adopt a few shared patterns:

Cross‑functional obligations forum:

A regular meeting where legal, compliance, AML, safer‑gambling, information security, product and operations review new or changing obligations, incident themes, audit findings and upcoming regulatory changes. Decisions – new entries, re‑ratings, mapping changes – are recorded immediately in the A.5.31 register.

Clear accountability and ownership:

A senior executive with overall accountability for regulatory obligations, a security leader responsible for the ISMS, and defined roles for who discovers new obligations, who maintains entries, who decides interpretations and who checks effectiveness. A simple RACI makes this visible to teams and auditors.

Built‑in touchpoints with change and risk processes:

Rules that every major change – new market, new platform, significant product feature – triggers an obligations check before approval. Outputs from obligations reviews feed into risk assessments, internal‑audit planning, incident post‑mortems and ISO 27001 management reviews, keeping A.5.31 stitched into your wider governance cycles.

A small, meaningful set of indicators:

Measures such as the proportion of high‑impact obligations with current mapped controls and evidence, time taken to update the register after a regulatory change, or how many audit findings tie back to obligation gaps. These metrics can be graphed and discussed at leadership meetings, turning A.5.31 into something leaders watch, not just sign off.

Running those habits through an ISMS like ISMS.online makes it much easier to sustain them. Workflows, reminders, dashboards and audit trails reduce the effort of running the forum, maintaining ownership and tracking indicators across brands and jurisdictions.

When your teams are comfortable navigating the obligations register, adjusting entries as markets change, and using it to guide decisions on systems, game development and vendor selection, A.5.31 stops being “extra compliance paperwork”. It becomes a visible part of how you protect licences, reputation and player trust – and that is exactly the storey modern gambling regulators want to hear when they decide who can operate, and on what terms.

ISO 27001 A.5.31 – Meeting Gambling Regulator & Licensing Requirements