GLI-GSF-3: Security Controls Non-Gaming Vendors Must Satisfy to Integrate with a Gaming Enterprise

GLI-GSF-3 v1.0, titled Gaming Information Security (GIS) Controls Audit, Vendor Controls, is the third module of Gaming Laboratories International’s Gaming Security Framework. Its purpose is narrow and deliberate: to define the security obligations that apply to vendors who integrate non-gaming business applications and ancillary solutions into a gaming enterprise’s production environment, where those integrations do not directly affect regulated gaming components or activities. Payment processors, CRM platforms, marketing automation tools, HR systems, and enterprise resource planning software that touch a live gaming environment all fall within its scope. Game engines, RNG systems, and wagering platforms do not, as those remain governed by the gaming-specific modules.

Where GLI-GSF-3 Sits Within the Gaming Security Framework

The GLI Gaming Security Framework is a modular architecture. GLI-GSF-1 v1.1 serves as the foundational document, establishing the Common Gaming Information Security (GIS) Controls that apply to all Gaming Enterprises regardless of operation type. GLI-GSF-3 is an additive module: it does not replace GLI-GSF-1’s obligations but layers a supplementary set of Vendor GIS (VGIS) controls on top of them for the specific context of non-gaming vendor integrations.

The other modules address distinct operational contexts. GLI-GSF-2 covers Gaming Technical Security Assessment methodology. GLI-GSF-4 addresses land-based gaming operations such as casinos, racetracks, and gaming halls. GLI-GSF-5 covers online gaming operations including iGaming and online sports wagering. GLI-GSF-3 occupies the gap that all of these modules share: the non-gaming software and services layer that supports every gaming environment but does not itself constitute gaming activity.

GLI acknowledges that the GLI-GSF is designed to replace the technical security tests previously established in GLI-27 for land-based gaming and, in the near future, the security controls in Appendix B of GLI-19 and GLI-33 for interactive gaming and event wagering. For compliance teams already managing certification pathways under GLI-19 or GLI-33, the emergence of the GSF modules represents a structural change in how security is assessed across the entire technology stack, not just at the game or wagering system level. The full GLI Certification hub maps where each module sits within the broader certification ecosystem.

What Makes a Vendor Subject to GLI-GSF-3?

GLI-GSF-3 defines Vendors specifically as “Service Providers who integrate business applications and other ancillary solutions into a Gaming Enterprise’s GPE which does not directly affect regulated gaming components or activities.” A vendor whose software calls the gaming platform to retrieve real-time balance data and feeds that into a CRM record is integrating with the GPE. A vendor whose tool sits entirely outside the gaming network perimeter and receives only periodic, anonymised exports is not.

The Gaming Production Environment itself is defined broadly. It encompasses the operational setting where gaming activities and related services are conducted, managed, and delivered to patrons in a live or real-time manner, including the physical and virtual infrastructure, gaming systems, software, and processes required to facilitate casino gaming, lottery, event wagering, and interactive gaming. Critically, it also includes backend systems, business applications, and infrastructure that interface with or support gaming activities. A CRM system that writes to the same backend database feeding player account records is inside the GPE perimeter even if it never touches a game outcome.

“For the purpose of this module, Vendors refer to Service Providers who integrate business applications and other ancillary solutions into a Gaming Enterprise’s GPE which does not directly affect regulated gaming components or activities.”, GLI-GSF-3 v1.0, Section 1.2

The standard contains an important role-inversion note that compliance teams must understand before implementing the framework. When a vendor reads and implements GLI-GSF-1’s GIS Controls as required by GLI-GSF-3, the vendor assumes the role of the “Gaming Enterprise” in GLI-GSF-1’s control text, while the Gaming Enterprise itself assumes the role of the “Regulatory Body.” A payment processor or CRM provider seeking to satisfy GLI-GSF-3 must therefore apply GLI-GSF-1’s Common GIS Controls to its own systems as if it were the operator under regulatory supervision, with the operator acting as its regulator.

How GLI-GSF-3 Differs from GLI-GSF-1

GLI-GSF-1 v1.1 establishes the foundational GIS control set for Gaming Enterprises, organised into Gaming Implementation Groups (GIGs). GIG1 defines essential gaming security hygiene, representing a minimum standard for all Gaming Enterprises. GIG2 adds more sophisticated controls for enterprises with greater security maturity. GIG3, the most demanding tier, applies to all Gaming Enterprises running online gaming operations unless a Regulatory Body specifies otherwise. Every online gaming operator is treated as a GIG3 enterprise by default.

GLI-GSF-3 does not replicate this tiered structure for vendors. Instead, it establishes a single supplementary control set, the VGIS Controls, that apply to vendor integrations without the GIG segmentation. The standard explicitly states that the VGIS Controls listed in its Appendix are not exhaustive: in addition to the Common GIS Controls from GLI-GSF-1, additional GIS Controls may be included based on regulatory requirements and the scope of the assessment. Regulatory Bodies that adopt GLI-GSF-3 retain discretion to impose more demanding requirements on specific vendor categories.

The key structural difference between GLI-GSF-1 and GLI-GSF-3 is the subject of obligation. GLI-GSF-1 regulates the Gaming Enterprise’s own security posture. GLI-GSF-3 regulates what a vendor must demonstrate before and during integration into someone else’s Gaming Production Environment. The Gaming Enterprise is the consuming party and the oversight authority, the vendor is the subject of assessment. This mirrors the relationship dynamic familiar from PCI-DSS merchant-acquirer assessments, where the acquiring bank’s security standards bind the merchant, but in GLI-GSF-3 the gaming operator takes the oversight role.

The VGIS Control Domains: What Vendors Must Implement

The VGIS control set in GLI-GSF-3’s Appendix covers six primary domains. Each carries specific obligations that vendors must satisfy as a condition of integration, and each is subject to verification during the VGIS Controls Audit.

VGIS-1: Incident Response. The vendor must maintain documented and tested processes for responding to security incidents that affect business applications or ancillary solutions integrated into the GPE. Under VGIS-1.3.2, the vendor must notify affected Gaming Enterprises without undue delay upon identification and confirmation of a security incident. That notification must include the nature and scope of the incident, systems or data impacted, the known or suspected cause, mitigation actions underway, and recommended patron actions. The vendor must then actively coordinate with the Gaming Enterprise to contain the incident, restore affected services, support forensic investigation if required, and prevent recurrence through corrective actions.

VGIS-2: Accounts and Privilege Management. All account-related activities, including creation, modification, and deletion, must be logged by the vendor, covering both standard and privileged accounts. Under VGIS-2.2.3, when requested, the vendor must maintain the technical capability to integrate with the Gaming Enterprise’s automated systems for real-time account activation and deactivation through industry-standard protocols. Elevated access to the Gaming Enterprise’s GPE requires a real-time approval process under VGIS-2.3.1, and under VGIS-2.3.2 the vendor must not access the GPE directly without prior authorisation. All access attempts and activities within the GPE must be logged in detail and made available upon request. For cloud-based SaaS solutions, contractual agreements must include provisions for third-party audits to verify compliance with industry best practices. For authentication, the vendor must be technically capable, when requested, of integrating with the Gaming Enterprise’s single sign-on systems through industry-standard SSO protocols and of enforcing MFA through push notification, TOTP, or hardware token. SMS-based MFA does not satisfy this control.

VGIS-3: Data and Logging Integrity. Log transfers between vendor systems and the Gaming Enterprise must be complete, unaltered, and in a structured format that preserves timestamp integrity, source system identifiers, and event details necessary for traceability and audit. Under VGIS-3.2.4, transferred logs must be reconcilable against a native system report to support integrity checks for sampling or full re-performance testing. This control has direct relevance for payment processors, where transaction log integrity is also a PCI-DSS obligation, and for CRM providers that aggregate player behavioural data relevant to responsible gambling monitoring.

VGIS-4: Supply Chain Management. The vendor must implement and maintain a current, comprehensive, and documented Supply Chain Risk Management (SCRM) Plan under VGIS-4.1.1. That plan must outline the policies, procedures, roles, responsibilities, and processes used to identify, assess, mitigate, and monitor supply chain risks throughout the lifecycle of the product or service. Under VGIS-4.1.3, the SCRM Plan and supporting policies must be made available to the Gaming Enterprise upon request for oversight and compliance verification. The vendor must also conduct regular supply chain risk assessments and reviews under VGIS-4.2, with particular focus on components and services that could introduce vulnerabilities or compromise the integrity of the GPE.

VGIS-5: Secure Software Development and Deployment. This is the domain most likely to create friction for SaaS vendors accustomed to autonomous release cycles. Under VGIS-5.1.2, the vendor must not perform any automated software deployments to the Gaming Enterprise’s GPE without prior scheduling, explicit approval, and logging by the Gaming Enterprise. All deployment events must be traceable and subject to the Gaming Enterprise’s change management program under VGIS-5.1.3. The vendor’s secure coding standards must follow recognised frameworks such as OWASP, applied consistently throughout the development process. CI/CD pipelines must be secured with access control and audit logging for code repositories, secure build environments and artifact management, deployment gating and change management policies, and protection against unauthorised modifications to pipeline logic.

VGIS-6: Gaming Technical Security Testing. The vendor must conduct Gaming Technical Security (GTS) Testing in accordance with the methodologies and requirements outlined in GLI-GSF-2. This testing must include the evaluation of business applications and ancillary services for vulnerabilities, misconfigurations, and unauthorised access paths. Under VGIS-6.2.1, scope may be adjusted based on the size, context, and nature of the applications being integrated. Under VGIS-6.2.3, any modifications to the scope of GTS Testing require prior review and approval by the Gaming Enterprise, and under VGIS-6.2.4 the vendor must document the justification for all scope adjustments and maintain a verifiable record of approvals.

What Does the VGIS Controls Audit Require?

The VGIS Controls Audit is performed with the intent of identifying actual or potential instances of non-compliance, vulnerabilities, or weaknesses, and assuring the confidentiality, integrity, availability, and accountability of the integrated environment. The standard specifies three assessment methods: interview (obtaining information through direct questioning), examine (checking, inspecting, reviewing, or analysing assessment objects), and test (exercising audit objects under specified conditions to compare actual with expected behaviour).

The audit must be carried out by an Independent Security Firm (ISF). Unless otherwise specified by the Gaming Enterprise or Regulatory Body, the ISF must meet the qualifications defined for that role in GLI-GSF-1. Where the audit report recommends remediation, the vendor must provide a remediation plan detailing actions and a schedule for implementation, including any interim risk mitigation measures.

GLI-GSF-3 does not prescribe audit frequency. The standard gives Gaming Enterprises and Regulatory Bodies flexibility in determining how often VGIS Controls Audits are conducted and whether recurring assessments are required during a multi-year integration agreement. The Gaming Enterprise’s own regulatory obligations will drive that cadence in practice. The UKGC’s Licence Conditions and Codes of Practice, MGA technical standards under the Gaming Act 2018 (Cap. 583), and the AGCO’s Registrar’s Standards for Internet Gaming all hold the Gaming Enterprise responsible for the security posture of its entire GPE, not just the components it directly operates, so vendor security re-assessment frequency is ultimately a function of those upstream obligations.

Practical Implications for Payment Processors and CRM Providers

Payment processors integrating directly with a gaming platform’s transaction layer face the most demanding intersection of standards. PCI-DSS v4.0.1 already requires rigorous patch management, secure development lifecycle controls, and third-party audit provisions. GLI-GSF-3 adds a gaming-specific layer on top: the SCRM Plan, the GPE-specific incident notification obligations under VGIS-1.3, and the prohibition on automated deployments without Gaming Enterprise approval under VGIS-5.1.2. A payment processor cannot present its PCI-DSS Report on Compliance as sufficient evidence of GLI-GSF-3 satisfaction, the VGIS controls are additive and gaming-context-specific.

CRM and marketing automation providers face a different risk profile. Their primary exposure under GLI-GSF-3 relates to VGIS-2 (privilege management over player data), VGIS-3 (log integrity for player behavioural records), and VGIS-5 (deployment controls that prevent unauthorised CRM updates from writing unexpected data to shared backend systems). For operators in Ontario, where the AGCO’s Registrar’s Standards for Internet Gaming impose player protection obligations that depend on accurate behavioural data, a CRM vendor that can manipulate or corrupt player records without Gaming Enterprise visibility represents a systemic compliance risk beyond the security dimension alone.

Vendors holding ISO/IEC 27001 certification will find that certification covers the foundational risk management and control framework but does not map directly to the VGIS control specifics. As explored in the context of ISO 27001 implementation in iGaming, certification scope frequently excludes the precise system boundaries that gaming regulators care about. Under GLI-GSF-3, the Gaming Enterprise effectively acts as the VGIS auditor’s client and will scrutinise whether the vendor’s ISO 27001 ISMS boundary actually encompasses the components integrated into the GPE or merely the vendor’s corporate IT perimeter.

The VGIS Controls listed in the Appendix are not exhaustive and in addition to the Common GIS Controls from the GLI-GSF-1, additional GIS Controls may be included based on regulatory requirements and scope of the assessment., GLI-GSF-3 v1.0, Section 2.3

Adoption and Regulatory Status

GLI-GSF-3 v1.0 may be adopted in whole or in part by any Regulatory Body and/or Gaming Enterprise that wishes to implement a comprehensive set of GIS Controls for vendor integrations in conjunction with the Common GIS Controls from GLI-GSF-1. The standard is not self-executing: adoption requires a Regulatory Body to mandate it or a Gaming Enterprise to incorporate it into its vendor management programme contractually.

No Regulatory Body had formally mandated GLI-GSF-3 adoption as a standalone licensing condition as of the time of publication, though adoption trajectories for GLI-GSF-1 suggest that jurisdictions requiring the broader Gaming Security Framework will progressively extend those requirements to the vendor-specific modules. The AGCO’s Registrar’s Standards for Internet Gaming in Ontario already impose obligations on operators regarding third-party vendor oversight, and the AGLC’s Standards and Requirements for Internet Gaming in Alberta follow a comparable architecture. GLI-GSF-3 provides a structured assessment methodology that maps closely to those regulatory expectations even before formal adoption. Operators and vendors should consult qualified legal counsel in the relevant jurisdiction to confirm whether Regulatory Body guidance in their market has incorporated GLI-GSF-3 or any equivalent standard as a condition of operation.

Operators in regulated markets overseen by the UKGC, MGA, and AGCO should treat GLI-GSF-3 as operational best practice for non-gaming vendor due diligence regardless of whether their specific Regulatory Body has mandated it. The underlying licensing obligations those bodies impose already require operators to manage third-party access to GPEs rigorously. GLI-GSF-3 provides a documented, auditable methodology for satisfying those obligations that an ISF can assess and a regulator can review. For a side-by-side view of how the UKGC and MGA approach operator obligations more broadly, the UKGC vs MGA licence comparison covers how each regulator frames third-party and technical security responsibilities within their respective licensing frameworks.

Operationalising GLI-GSF-3 in Vendor Contracts

Gaming Enterprises that wish to use GLI-GSF-3 as the basis for vendor due diligence should address several contractual mechanics before integration begins. The SCRM Plan requirement under VGIS-4.1.3 mandates that the plan be made available on request: the contract must specify that this right is perpetual, not limited to the onboarding phase. The prohibition on automated deployments under VGIS-5.1.2 requires the contract to establish a change notification and approval procedure, including defined lead times, approval authorities, and escalation paths for emergency patches.

Incident notification obligations under VGIS-1.3.2 mandate notification “without undue delay” upon identification and confirmation of a security incident. Gaming Enterprises should translate “undue delay” into a specific contractual SLA, regulators reviewing the Gaming Enterprise’s incident response will expect evidence that vendor notification timelines were contractually defined rather than left to the vendor’s discretion. A defensible baseline is four hours for confirmation of a significant incident and 24 hours for a full initial impact assessment, though the applicable Regulatory Body’s own incident reporting timelines should set the outer bound.

For SaaS vendors, VGIS-2.3.5 requires that contractual agreements include provisions for third-party audits to verify compliance with industry best practices. The Gaming Enterprise should specify that GLI-GSF-3 VGIS Controls Audit reports, or equivalent ISF assessments, are deliverable under that provision and that right-to-audit clauses cannot be waived by the vendor’s standard terms.

The risk-based scope adjustment mechanism in VGIS-6.2 deserves specific attention in vendor contracts. The Gaming Enterprise retains approval authority over any scope reduction in GTS Testing. Vendors that propose narrowing the test scope must receive Gaming Enterprise sign-off, and that approval must be documented with a verifiable justification record. Compliance teams should ensure their vendor management governance framework assigns a named approval authority for scope change decisions before the first assessment engagement begins.

Key Resources

GLI-GSF-3: Gaming Information Security Controls Audit, Vendor Controls, v1.0, Gaming Laboratories International. Available free of charge at gaminglabs.com. The primary document governing VGIS Controls and the VGIS Controls Audit process.

GLI-GSF-1: Gaming Information Security Controls Audit, v1.1, Gaming Laboratories International. The foundational module establishing Common GIS Controls and the Gaming Implementation Group (GIG) tiering framework that GLI-GSF-3 supplements.

GLI-GSF-2: Gaming Technical Security Assessment, v1.0, Gaming Laboratories International. Defines the GTS Testing methodology referenced in VGIS-6.1, which vendors must follow when conducting Gaming Technical Security Testing of their integrated applications.

GLI Gaming Security Framework Overview, Gaming Laboratories International. Available at gaminglabs.com, providing the module map and adoption guidance for the full GSF suite including GLI-GSF-1 through GLI-GSF-5.