ISO/IEC 27001 in iGaming: Why Most Compliance Teams Get It Wrong

Why ISO/IEC 27001 Is Not Optional in Licensed iGaming

ISO/IEC 27001 is often framed as a voluntary framework that demonstrates security maturity. In licensed iGaming, that framing is increasingly inaccurate. The UK Gambling Commission’s Remote Gambling and Software Technical Standards (RTS) state in section 4.1 that the Commission “has based the security requirements on the relevant sections of Annex A to the ISO/IEC 27001:2022 standard.” Section 4.2 confirms that the 2022 edition supersedes the 2013 version. For any UKGC remote gambling licence holder, the Annex A controls are not aspirational guidance : they define the minimum security architecture the Commission expects to find operating across critical systems.

The MGA positions the standard differently but no less firmly. The MGA’s Technical Infrastructure : Remote Gaming document (December 2015, v1) directs that cloud service providers “are to be guided by ISO/IEC 27002:2013 Information Technology : Security techniques : Code of Practice, for Information Security Management in implementing the Information Security Management System.” For cloud-hosted critical components, the MGA additionally requires that any hosting decision follow a risk assessment conducted within the framework of ISO 31000:2009. Two standards, one regulatory expectation: structured, documented risk management underpins every hosting and security architecture decision.

Understanding this regulatory embedding matters before examining where compliance teams go wrong. The mistakes below are not abstract audit observations. They translate directly into regulatory exposure across UKGC and MGA jurisdictions, and increasingly into the findings that surface during technical compliance assessments under other frameworks such as Spillemyndigheden’s Certification Programme for online casino (SCP.02.03.EN.2.0), which requires inspection personnel to hold CISSP or CISA credentials precisely because the depth of technical security review expected in licensed gambling is substantial.

Mistake One: Scoping the ISMS Around Convenience, Not Risk

ISO/IEC 27001 gives organisations latitude to define the boundary of their Information Security Management System. Compliance teams in iGaming frequently exploit that latitude by scoping the ISMS to the narrowest possible footprint: typically the corporate IT environment, a small cluster of internally hosted servers, or a single legal entity within a larger group. The result is a certified ISMS that does not encompass the systems regulators actually care about.

The UKGC RTS is explicit about which systems carry the highest security weight. Section 4.3 identifies the critical systems to which the security standards apply: electronic systems that record, store, process, share, transmit or retrieve sensitive customer information such as credit and debit card details, authentication information, and customer account balances; electronic systems that generate, transmit, or process random numbers used to determine the outcome of games or virtual events; electronic systems that store results or the current state of a customer’s gamble; points of entry to and exit from those systems; and communication networks that transmit sensitive customer information.

“The Commission has highlighted those systems that are most critical to achieving the Commission’s aims and the security standards apply to these critical systems.” : UKGC Remote Gambling and Software Technical Standards, Section 4.3

If an operator’s certified ISMS scope excludes the RNG infrastructure, player database servers, or financial transaction systems : all of which the MGA separately classifies as critical components in its Technical Infrastructure document : the certificate is functionally disconnected from the regulator’s expectations. Auditors reviewing a UKGC compliance file who find that the ISMS scope statement does not cover these systems will immediately question whether the security controls mapped to Annex A are actually operative on the infrastructure that matters.

In practice, operators should map the ISMS scope to the regulatory definition of critical systems first, then work outward to identify what supporting infrastructure and third-party relationships fall inside that boundary. Starting from convenience and working toward compliance is the pattern that creates persistent gaps.

Mistake Two: Treating Certification as an Endpoint

ISO/IEC 27001 is a management system standard. The word “management” carries functional meaning: the standard requires an ongoing cycle of planning, implementation, performance evaluation, and improvement. Clause 9 of the standard mandates internal audits and management reviews at planned intervals. Clause 10 mandates continual improvement. These are not decorative provisions. A certification body that issues a certificate is certifying the ISMS as it existed during the initial audit cycle. It is not certifying what the ISMS will look like eighteen months later when the operational environment has changed, new game verticals have been added, a third-party payment processor has been onboarded, or a cloud migration has occurred.

In iGaming, the operational environment changes at a pace that most other industries do not experience. Game content is added continuously. Player traffic spikes are frequent. Supplier relationships turn over. Regulatory requirements in multiple simultaneous jurisdictions evolve. An ISMS that was accurate at certification and has not been updated to reflect those changes is not a functioning ISMS. It is a historical document with a certificate attached.

Regulators are beginning to recognise this. The UKGC’s RTS section 5.35 lists “Independent review of information security” as a required organisational control drawn from Annex A, and section 5.22 requires “Monitoring, review and change management of supplier services.” Both provisions assume an active, living programme, not a frozen certification artefact. Compliance officers should ask whether their internal audit schedule is genuinely risk-driven and whether management review outputs are documented with action items that can be traced through to closure.

Mistake Three: Disconnecting the Risk Treatment Plan from Operational Reality

The risk assessment and risk treatment plan are the engine of an ISO/IEC 27001 ISMS. In iGaming compliance teams, they are also among the documents most likely to be produced at certification and subsequently neglected. A risk treatment plan that was completed in 2022 and has not been revisited does not reflect the threat landscape that operators face today, and it almost certainly does not reflect any changes in architecture, personnel, supplier relationships, or regulatory obligations that have occurred in the intervening period.

The MGA’s approach to cloud risk provides a useful reference point. The Technical Infrastructure : Remote Gaming document requires that any decision to host critical components in a cloud environment be preceded by a risk assessment conducted within the framework and process of risk management described in ISO 31000:2009. Critically, the MGA states that the risk assessment “should include the core elements of the risk management process as defined in this standard” and that the list of risks provided in Appendix A “should not be considered an exhaustive list.” The implication is that risk assessment is an iterative analytical exercise, not a template to be completed once.

Operators whose risk treatment plans are static documents that predate their current cloud architecture, their current supplier portfolio, or their current regulatory perimeter are operating with a material gap between their certified ISMS posture and their actual risk exposure. Auditors who probe risk treatment documentation will quickly identify risks that have no treatment assigned, treatments that have been accepted without documented rationale, or treatment actions that are listed as planned but were never implemented.

Mistake Four: Mishandling Supplier and Cloud Controls

A large proportion of the iGaming technology stack is delivered by third parties: platform providers, game studios, payment processors, KYC and identity verification services, and cloud infrastructure providers. The UKGC RTS Annex A controls address this directly. Section 5.19 requires information security in supplier relationships, section 5.20 requires addressing information security within supplier agreements, section 5.21 requires managing information security in the ICT supply chain, section 5.23 requires specific controls for cloud services, and section 5.22 requires ongoing monitoring, review, and change management of supplier services.

The UKGC’s security requirements explicitly extend to supplier agreements, ICT supply chain management, and cloud service governance : licence holders cannot treat third-party infrastructure as outside the scope of their security obligations.

In practice, operators frequently hold certifications that include a cursory reference to supplier management without any substantive controls programme behind it. Supplier security questionnaires sent annually and filed without analysis do not constitute a supplier information security programme. Contracts that reference security obligations in broad terms without specifying control requirements, audit rights, incident notification timelines, or data handling standards do not meet the intent of the Annex A controls the UKGC has adopted.

For MGA licensees, the PCI DSS Level 1 certification requirement for credit card data storage and processing adds a parallel obligation that intersects directly with the supplier landscape, since payment data often flows through third-party processors. The MGA’s Technical Infrastructure document notes that “hosting locations that are certified as per the above standards will facilitate the processing of an application,” but this should not be read as a complete transfer of responsibility. The licensee’s ISMS must address how it selects, monitors, and contractually governs those certified third parties.

Mistake Five: Failing to Document What Auditors Actually Test

ISO/IEC 27001 auditors, and by extension regulatory technical assessors, are not primarily testing whether policies exist. They are testing whether controls are operative and whether there is objective evidence to demonstrate it. The most common failure mode in iGaming ISMS audits is not the absence of policy documents. It is the absence of records proving that the processes described in those policies are actually running.

Section 5.35 of the UKGC RTS, which maps to Annex A control A.5.35 “Independent review of information security,” requires evidence that reviews are occurring, not simply that a policy authorising reviews has been written. Similarly, the incident management controls referenced in UKGC RTS sections 5.24 through 5.28, covering incident management planning, assessment of events, incident response, and collection of evidence, require documented records of actual incident handling, not simply a response procedure document.

Compliance teams should conduct a documentation readiness assessment before any surveillance audit or regulatory technical review. The critical question for each Annex A control included in scope is: what objective evidence exists that this control is operating, and how far back does the evidence trail go? Policies and procedures answer what the organisation intends to do. Logs, records, reports, minutes, and change tickets answer what it has actually done.

Integrating ISO/IEC 27001 with Regulatory Compliance Programmes

The structural mistake that underlies all of the operational errors described above is treating ISO/IEC 27001 as a parallel workstream rather than an integrated component of the regulatory compliance programme. A UKGC licence holder’s RTS obligations and its ISMS obligations are not two separate things. The RTS security requirements are explicitly anchored in the 2022 standard’s Annex A. Managing them separately produces duplication, gaps, and the chronic disconnect between what the certified ISMS covers and what the regulatory framework requires.

Effective integration means that the ISMS scope statement is written with reference to the regulatory definition of critical systems. It means that the risk assessment methodology accounts for regulatory risk, not only technical risk. It means that internal audit plans cover the Annex A controls that the UKGC has specifically flagged, including supplier management, cloud controls, incident management, and access management. And it means that management review discussions include the regulatory compliance status of the ISMS alongside the traditional ISMS performance metrics.

An ISMS that is genuinely integrated with the operator’s regulatory obligations will surface compliance gaps before regulators do, which is the only version of the system that provides real operational value.

For MGA licensees operating multi-jurisdictional platforms, the integration challenge is more complex. The MGA’s ISO/IEC 27002 guidance for CSPs, the ISO 31000 requirement for cloud risk assessments, and the UKGC’s ISO/IEC 27001:2022 Annex A mapping do not conflict, but they create a layered set of obligations that must be mapped coherently in a single ISMS rather than managed as separate jurisdiction-specific compliance exercises. Operators should consult qualified legal and technical advisory counsel to ensure that the ISMS scope, risk assessment methodology, and control selection adequately address the intersection of these regulatory frameworks in their specific operational context.

What Auditors Are Looking For in iGaming ISMS Reviews

Auditors conducting ISO/IEC 27001 surveillance audits or regulatory technical assessments in iGaming environments consistently focus on a small number of high-signal indicators. The ISMS scope statement is the first document reviewed: does it encompass the systems that carry regulatory weight, or does it carve out the most technically complex and risk-relevant infrastructure? The risk treatment plan is the second: is it current, is it granular, and do treatment actions have owners, timelines, and evidence of completion? The internal audit records are the third: are they dated after certification, do they cover the full scope, and do they produce findings that are tracked through to closure?

Beyond those three foundational documents, auditors in iGaming contexts will typically probe the supplier security programme, looking for evidence that contractual security requirements exist and that supplier performance is monitored rather than assumed. They will test the incident management process by asking for records of security events handled since the last audit cycle, not hypothetical incident scenarios. And they will examine access control records, looking for evidence that access rights are reviewed, that privileged access is managed, and that joiner, mover, and leaver processes are documented and followed, all of which correspond to Annex A controls explicitly cited in the UKGC RTS at sections 5.15 through 5.18.

The pattern that distinguishes operators who pass these reviews from those who do not is not the sophistication of their security technology. It is the discipline of their documentation and the consistency of their process execution. Certification earned on a narrow scope and never revisited is not a compliance asset; it is a liability waiting to surface in the next regulatory review.

Key Resources

UKGC Remote Gambling and Software Technical Standards : available at gamblingcommission.gov.uk. Section 4 sets out the security requirements anchored in ISO/IEC 27001:2022 Annex A and defines the critical systems to which they apply.

MGA Technical Infrastructure : Remote Gaming (December 2015, v1) : published by the Malta Gaming Authority. Establishes ISO/IEC 27002:2013 guidance for CSPs and the ISO 31000:2009 requirement for cloud risk assessments covering critical components including RNG servers, player database servers, jackpot servers, financial database servers, and gaming database servers.

ISO/IEC 27001:2022 Information Security Management Systems : Requirements : published by the International Organization for Standardization. The current version of the standard, referenced directly in the UKGC RTS. Annex A provides the control set from which UKGC security requirements are drawn.

MGA Player Protection Directive (Directive 2 of 2018, v3 January 2023) : published by the Malta Gaming Authority. Provides the broader regulatory context for B2C licensee obligations within which ISMS requirements operate.

Note: Application of ISO/IEC 27001 requirements to specific operational architectures, multi-jurisdictional licence portfolios, and regulatory technical assessments involves jurisdiction-specific legal and technical considerations. Operators should engage qualified legal counsel and certified information security professionals for advice specific to their circumstances.