GLI-GSF-5: What the Online Gaming Security Audit Standard Actually Tests

GLI-GSF-5 v1.0 is the online gaming-specific module of Gaming Laboratories International’s Gaming Security Framework (GLI-GSF). Published in 2025, it does not operate independently: every Gaming Enterprise subject to GLI-GSF-5 must simultaneously satisfy the full Common GIS Controls set out in GLI-GSF-1 v1.1. Understanding what GLI-GSF-5 actually tests requires reading both documents together, because the Online Gaming Information Security (OGIS) controls in GLI-GSF-5 are explicitly additive to that baseline.

The standard covers online gaming operations delivered via gaming websites, mobile applications, and other digital platforms, encompassing interactive gaming (iGaming) and online sports wagering. Any Gaming Enterprise that also operates land-based gaming, vendor integrations, or non-gaming business applications may face concurrent requirements under GLI-GSF-4 (land-based), GLI-GSF-3 (vendors), or GLI-GSF-2 (non-gaming business applications). GLI-GSF-5 does not displace those modules, it adds the online-platform layer on top of the common foundation.

The GIG3 Baseline: Why Online Operators Face the Highest Tier

The GLI-GSF-1 divides Gaming Enterprises into three Gaming Implementation Groups (GIG1, GIG2, GIG3) based on the sensitivity of the assets they manage and the threat profile they face. GIG3 represents the most demanding tier, and the standard removes any discretion about how online operators are classified.

“All Gaming Enterprises running online gaming operations (e.g. interactive gaming, online event wagering, etc.) are to be treated as GIG3 Gaming Enterprises, unless otherwise specified by the Regulatory Body.”

GIG3 status means the Gaming Enterprise’s controls programme must address all CIS Critical Security Controls (Version 8.1) up to and including the GIG3-designated items, plus the additional GLI gaming-specific GIS controls applicable at that tier. The practical implication is that CIS controls that are optional for GIG1 or GIG2 enterprises become mandatory for online operators. Penetration testing under CIS-18 is illustrative: GIG2 enterprises must establish a penetration testing programme and perform periodic external penetration tests (CIS-18.1, 18.2, 18.3), while GIG3 enterprises must additionally validate security measures and perform periodic internal penetration tests (CIS-18.4, 18.5). The GLI-GSF-1 sets the floor, GLI-GSF-5 builds the online-specific walls above it.

What Makes GLI-GSF-5 Different from GLI-GSF-1

GLI-GSF-1 contains GIS Controls applicable to all forms of gaming: the Common GIS Controls. These cover asset inventory, secure configuration, account management, access control, vulnerability management, audit logging, data protection, incident response, and penetration testing, among others. GLI-GSF-5 appends a separate OGIS Controls set that addresses security risks unique to online gaming environments. The OGIS controls are organised into four main categories.

OGIS Category	Control Group	Key Obligations
OGIS-1	Critical Control Program Verification	Signature verification of critical control programs, verification audit log accessible to Regulatory Body, notification and reporting on verification failure
OGIS-2	Back Office Administration	MFA enforcement on all privileged accounts, vendor access management, RBAC with least privilege, network access restrictions including IP whitelisting, VPN, or zero trust, segregation of duties on financial transactions
OGIS-3	Online Gaming Infrastructure	Server architecture segmentation, execution control and whitelisting, policy enforcement on mobile devices and external media, MDM for devices connecting to critical servers
OGIS-4	Application Protection Mechanisms	SSL/TLS certificate pinning for mobile apps, bot mitigation with behavioural analysis and device fingerprinting, password stuffing detection, API security against OWASP API Top 10

OGIS-1: Critical Control Program Integrity

The signature verification obligation under OGIS-1 applies to all Critical Control Programs within the Gaming Production Environment (GPE). Under OGIS-1.2.2, the verification audit log must record for each signature check: the date and time, identification of each verified Critical Control Program, the expected and generated signature results including any mismatch, and the user account ID of whoever initiated an on-demand verification. Under OGIS-1.2.3, that log must be accessible to the Regulatory Body in a format that permits analysis of each individual verification.

Failure carries a mandatory notification obligation: OGIS-1.3.1 requires that any signature verification failure be communicated to the Gaming Enterprise. Where the Regulatory Body requires it, OGIS-1.3.2 obligates the Gaming Enterprise to report the failure and corrective actions taken without undue delay. This is not a passive logging obligation. An auditor will test whether the notification chain functions as specified, not merely whether logs exist.

The GLI-GSF-5 definition of Critical System Component is broad and directly relevant to online platforms. Components that record, store, process, share, transmit, or retrieve sensitive data, components that generate or process random numbers used to determine game outcomes, components that store the current state of a patron’s game or available funds, authentication servers, MFA systems, SIEM systems, and virtualisation components (including virtual machines, virtual switches, and virtual appliances) all fall within the Critical System Component definition. This scope is consequential for cloud-hosted operations, as discussed below.

OGIS-2: Back Office Administration Controls

The back office administration controls under OGIS-2 address the privileged access surface that online operators face and land-based venues largely do not. OGIS-2.1.1 requires MFA enforcement for all privileged accounts used to access Back Office Administration Applications, covering administrative, operational, and supervisory accounts. This is not aspirational guidance. The audit will test whether MFA is actually enforced at the application layer for those account types.

Vendor access management is governed under OGIS-2.2, which requires the Gaming Enterprise to maintain a documented inventory of third-party vendor access, define access scope, and have the capability to immediately revoke vendor access in the event of a GIS incident (OGIS-2.2.5). The ability to terminate access promptly is tested, not just the existence of a policy.

The network access restriction requirements under OGIS-2.4 require that Back Office Administration Applications be restricted to trusted and authorised networks, with the Gaming Enterprise implementing at least one of IP whitelisting, firewalls, network segmentation, or secure VPN. Public networks and untrusted devices must be explicitly denied access. Notably, OGIS-2.4.1 provides that zero trust solutions must be continuously evaluated as an alternative or supplementary enforcement mechanism. The standard acknowledges that perimeter-based controls alone may not be sufficient for modern distributed architectures, a direct acknowledgement of cloud-native deployment patterns.

Role-Based Access Controls (RBAC) under OGIS-2.3 must assign permissions based on job responsibilities, with all changes documented and recorded (OGIS-2.3.1). The segregation of duties requirement at OGIS-2.3.3 is explicit: Back Office Administration Applications must prevent the same individual from both initiating and approving transactions.

OGIS-3: Online Gaming Infrastructure Architecture

The infrastructure controls in OGIS-3 address architecture patterns specific to online platforms. OGIS-3.5.1 requires that server roles be functionally separated at the architectural level: for example, a database server may not also host web or application services. This is not a recommendation. The audit will examine the actual infrastructure to verify logical separation is in place.

OGIS-3.5.2 extends this to technical and administrative controls enforcing role separation between server instances, requiring distinct virtual machines, containers, or services for each function (database, application, web server), each with workload-specific configurations, access controls, and monitoring. For Gaming Enterprises running containerised workloads or microservices architectures on cloud infrastructure, this control requires documented evidence that the separation exists and is enforced.

The execution control requirements at OGIS-3.2 mandate application whitelisting on critical servers: only pre-approved software is permitted to run, and all other code is blocked (OGIS-3.2.2). Mobile Device Management (MDM) under OGIS-3.3.1 is required to govern which devices can connect to the network, with USB drives explicitly blocked on critical servers. These controls often create friction in operations teams accustomed to flexible access patterns, and ISF auditors regularly identify gaps here.

OGIS-4: Application-Layer Security

OGIS-4 addresses the attack surface that is unique to online gaming platforms: the patron-facing application layer.

Mobile application security under OGIS-4.1.1 requires SSL/TLS certificate pinning or equivalent measures, such as certificate transparency monitoring or dynamic pinning frameworks, to protect against man-in-the-middle attacks. OGIS-4.1.2 requires that mobile applications terminate network connections immediately if the pinned certificate or encryption key does not match the expected value. Certificate pinning is straightforward to test, and its absence is a common finding in first-time assessments.

Bot mitigation under OGIS-4.5 requires the GPE to integrate a bot mitigation solution detecting and blocking automated traffic. The solution must include behavioural analysis, device fingerprinting, and challenge-response mechanisms (OGIS-4.5.2). This is not satisfied by a standard CAPTCHA deployment alone. The auditor will examine whether the solution differentiates between human users and automated scripts with sufficient sophistication.

Password stuffing protection under OGIS-4.4 requires mechanisms to detect high-volume login attempts using varied credentials from a single IP address or device (OGIS-4.4.1), with preventive measures enforced on authentication endpoints, including rate limiting, account lockout policies, and credential stuffing detection logic (OGIS-4.4.2). Given the volume of credential stuffing activity targeting online gaming accounts, regulators adopting GLI-GSF-5 will pay particular attention to whether detection is operational rather than merely configured.

What Does GLI-GSF-5 Actually Test for API Security?

OGIS-4.6 is among the most operationally significant controls in the standard for modern online gaming platforms. Online gaming operations depend heavily on APIs connecting the operator platform to game providers, payment processors, KYC and identity verification services, responsible gambling tools (including self-exclusion checks against registers such as GAMSTOP, Spelpaus, or ROFUS), and data analytics services.

“All APIs supporting the gaming website, mobile application, or other digital platform must adhere to the OWASP API Security Top 10 Best Practices, including authentication, rate limiting, data validation, and error handling.”

OGIS-4.6.2 requires that API security testing, including penetration tests and static/dynamic analysis, be performed regularly and in the development phase, with API gateways deployed to enforce authentication and access policies. The phrase “including in the development phase” is deliberate: the standard positions API security testing as a development lifecycle obligation, not only a pre-deployment gate. An audit finding that API security tests are only run immediately before submission for certification, rather than throughout the development process, will typically attract a recommendation for remediation.

In practice, compliance teams should map every API integration in the platform’s production environment before an audit engagement begins. Third-party game content providers, payment service providers, geolocation services, and AML/KYC data feeds all represent API connections. Each must be assessed against the OWASP API Security Top 10. The responsibility for agreeing which entity within the Gaming Enterprise is responsible for meeting each GIS Control rests with the Gaming Enterprise itself, the standard explicitly states that GLI-GSF-5 does not define that allocation.

Cloud Infrastructure: Where GLI-GSF-1 and GLI-GSF-5 Intersect

Online gaming operators overwhelmingly run on cloud or virtualised infrastructure. Neither GLI-GSF-5 nor GLI-GSF-1 prohibits cloud deployment, but GIS-3.8.1 of the GLI-GSF-1 makes the security obligation explicit: if sensitive data is stored, processed, or transmitted in a cloud or virtualised environment, appropriate GIS Controls must apply to that environment, typically involving validation of both the cloud infrastructure itself and the usage of server instances within it. This is a GIG2 baseline control, meaning it applies to all online operators by virtue of their GIG3 classification.

The practical challenge is evidence. Cloud providers operate a shared responsibility model, and ISF auditors assessing cloud-hosted Gaming Production Environments will require the Gaming Enterprise to demonstrate which security controls are cloud-provider responsibilities and which are operator responsibilities, with evidence that the operator-side obligations are met. Architecture diagrams (CIS-12.4, a GIG2 control under the GLI-GSF-1) become audit-critical documents in cloud environments because they are the primary mechanism by which the auditor maps the scope of the GPE against the controls that apply to it.

The Critical System Component definition in GLI-GSF-5 explicitly includes virtualisation components such as virtual machines, virtual switches, routers, and virtual appliances. This means cloud-native components are within scope for the OGIS Controls Audit, not merely the applications running on top of them.

The Audit Process: Three Methods, One Structured Report

GLI-GSF-5 specifies three assessment methods used to determine OGIS Control effectiveness. Interviews involve discussions with individuals or groups within the Gaming Enterprise to achieve clarification or locate evidence. Examination involves checking, inspecting, reviewing, or analysing assessment objects. Testing involves exercising one or more audit objects under specified conditions to compare actual with expected behaviour. An audit engagement will apply all three methods across the OGIS control set.

The OGIS Controls Audit must be performed by an Independent Security Firm (ISF). Under section 2.7 of GLI-GSF-5, the ISF must employ sufficiently qualified, competent, and experienced individuals meeting the qualifications specified in GLI-GSF-1. Unless the Regulatory Body specifies otherwise, the ISF qualification requirements from the GLI-GSF-1 apply. The audit report produced by the ISF must satisfy the “Audit Reports” requirements in the GLI-GSF-1, which are detailed and include an executive summary, GIS controls audit details, scope definition, methodology description, and findings with evidence.

Where the report recommends remediation, section 2.6 of GLI-GSF-5 requires the Gaming Enterprise to provide the Regulatory Body, and the ISF if the Regulatory Body requires it, with a remediation plan and any risk mitigation plans. The remediation plan must detail the Gaming Enterprise’s specific actions and schedule to implement each remediation step. This is a direct regulatory deliverable, not an internal document. Gaming Enterprises that treat remediation plans as bilateral arrangements between operator and auditor, rather than as documents submitted to the Regulatory Body, misunderstand their obligation under the standard.

Regulatory Adoption and the Transition from Legacy Standards

GLI-GSF-5 may be adopted in whole or in part by any Regulatory Body. The standard notes that the Regulatory Body retains authority to specify additional GIS Controls beyond those listed in the OGIS Controls Appendix, and may adjust certain default parameters such as GIG tier assignment or ISF qualification thresholds. This means that the OGIS Controls set in GLI-GSF-5 represents a minimum, and jurisdictions may layer additional requirements on top of it.

The GLI-GSF framework was explicitly developed in response to widespread industry demand for a comprehensive gaming security standard covering online operations. Its stated design goal is to align gaming information security with eCommerce security practices, ensuring that online gaming platforms operate with the same security rigour as other internet commerce environments. The AGCO’s Registrar’s Standards for Internet Gaming in Ontario and the AGLC’s Standards and Requirements for Internet Gaming in Alberta both contain security-related obligations that will increasingly reference or align with the GLI-GSF series as regulatory adoption broadens, a detailed comparison of how those two regimes currently diverge on security and technical standards is available in the AGCO vs AGLC standards analysis.

The relationship between GLI-GSF-5 and the existing security appendices in GLI-19 (Standards for Interactive Gaming Systems) and GLI-33 (Standards for Event Wagering Systems) is important for operators holding certifications under those standards. GLI has stated that GLI-GSF modules are intended to replace the technical security controls in Appendix B of GLI-19 and GLI-33 as those modules are released. Jurisdictions that currently require Appendix B compliance may migrate to requiring GLI-GSF-1 plus GLI-GSF-5 compliance, but that migration is a regulatory decision in each jurisdiction, not an automatic consequence of GLI-GSF publication. Operators should verify the current position with their regulator before assuming that a GLI-GSF-5 audit satisfies their Appendix B obligations, or vice versa.

For operators seeking to understand how GLI-GSF-5’s OGIS controls compare with the security architecture obligations under the UKGC’s Remote Technical Standards or the MGA’s technical infrastructure directives, the frameworks share underlying philosophies: confidentiality, integrity, availability, and accountability of the Gaming Production Environment are the consistent anchors across all three. The alignment with ISO/IEC 27001 controls and CIS Critical Security Controls Version 8.1 as GLI-GSF-1’s baseline ensures that operators with mature existing ISMS programmes will recognise the control families, even if the gaming-specific articulation differs.

Qualified legal counsel and a testing laboratory with GLI-GSF experience should be engaged before scoping any GLI-GSF-5 audit engagement. The interaction between jurisdiction-specific regulatory requirements and the standard’s flexible adoption model means that the precise control set applicable to a given operator depends on which Regulatory Body has adopted the standard and how.

For compliance teams preparing for a GLI-GSF-5 assessment, the comparison of GLI-19 and GLI-33 certification paths provides useful context on how legacy product-level certification interacts with the security framework, and the analysis of ISO/IEC 27001 implementation failures in iGaming identifies the ISMS scoping and cloud-coverage gaps that surface most frequently in security audits across the sector.

Key Resources

GLI-GSF-5: Gaming Information Security Online Audit v1.0, Gaming Laboratories International, LLC, 2025. Available free of charge at www.gaminglabs.com.

GLI-GSF-1: Gaming Information Security Controls Audit v1.1, Gaming Laboratories International, LLC, 2025. Required reading alongside GLI-GSF-5, defines Common GIS Controls, GIG tiers, audit report requirements, and ISF qualification standards. Available at www.gaminglabs.com.

CIS Critical Security Controls Version 8.1, Center for Internet Security. Incorporated by reference into GLI-GSF-1 as the baseline for all GIS Controls. Available free of charge at www.cisecurity.org.

OWASP API Security Top 10, Open Web Application Security Project. Mandated by OGIS-4.6.1 as the adherence standard for all APIs supporting the gaming platform. Available at owasp.org.