GLI-GSF-2 v1.0: Penetration Testing Scope, Frequency, and Remediation Obligations for Gaming Production Environments

GLI-GSF-2: Gaming Technical Security (GTS) Assessment v1.0 is the dedicated penetration testing module within Gaming Laboratories International’s Gaming Security Framework. It establishes the minimum requirements that a Gaming Enterprise must satisfy when commissioning technical security assessments of its Gaming Production Environment, covering what must be tested, who may conduct those tests, how frequently assessments must occur, and what the Gaming Enterprise must do when vulnerabilities are found. Any compliance team operating in a jurisdiction that has adopted the GLI-GSF suite needs a precise understanding of GLI-GSF-2’s mechanics before commissioning its first assessment or responding to regulatory findings.

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

The GLI Gaming Security Framework (GLI-GSF) is a suite of interlocking modules, each addressing a distinct layer of gaming security. GLI-GSF-1 v1.1 establishes the foundational Gaming Information Security (GIS) Controls Audit applicable to all Gaming Enterprises regardless of operational type. GLI-GSF-2 v1.0 is the technical security assessment module: it governs the attack-simulation testing that validates whether the controls in GLI-GSF-1 are actually effective under adversarial conditions. Additional modules address vendor integrations (GLI-GSF-3), land-based operations (GLI-GSF-4), and online gaming (GLI-GSF-5).

GLI’s own framework documentation states that the GLI-GSF “effectively replaces the technical security tests previously established in GLI-27 for land-based gaming operations and, in the near future, will replace the technical security controls previously established in Appendix B of GLI-19 and GLI-33 for interactive gaming and event wagering.” Compliance professionals managing certifications under GLI’s product certification pathways should treat GLI-GSF-2 as the forward standard for all GTS testing, rather than relying on the legacy Appendix B provisions embedded in GLI-19 v3.0 or GLI-33 v1.1.

GLI-GSF-1 explicitly cross-references GLI-GSF-2 in its change management provisions. Under GLI-GSF-1 section GIS-9.3.12, changes to the GPE categorised as critical trigger “additional GIS Controls Audits and GTS Assessments performed by an ISF, as described within the ‘Additional GIS Controls Audits’ section of this document and the ‘Additional Assessments’ section within the GLI-GSF-2.” The two modules are operationally inseparable.

What Constitutes a Gaming Production Environment

GLI-GSF-2 defines the Gaming Production Environment (GPE) as “the operational setting where gaming activities and related services are conducted, managed, and delivered to patrons in a live or real-time manner. It encompasses the physical and virtual infrastructure, systems, software, and processes required to facilitate various forms of gaming and/or manage sensitive data, as well as the backend systems and infrastructure that interface and/or support gaming activities.”

The GPE boundary is deliberately broad. It is not limited to front-end player-facing systems. The standard’s glossary of Critical System Components captures the full perimeter that must fall within GTS Assessment scope:

Critical System Components include components which record, store, process, share, transmit, or retrieve sensitive data, components which generate, transmit, or process random numbers used to determine the outcome of games and events, components which store results or the current state of a patron’s game, wager, or available funds, points of entry to and exit from those components, communications technology and networks which transmit sensitive data including network communication equipment (NCE) and network security controls, components that provide security services, including authentication servers, access control servers, SIEM systems, physical security systems, surveillance systems, MFA systems, and anti-malware systems, components that facilitate segmentation, including internal network security controls, and virtualisation components such as virtual machines and virtual switches.

Practically, the GPE assessment perimeter encompasses RNG infrastructure, player account management systems, payment processing gateways, SIEM platforms, identity and access management infrastructure, network segmentation devices, cloud workloads, containerised services, and any third-party service provider connection that transmits sensitive data. Compliance teams that scope a penetration test to only public-facing web applications are in breach of the standard’s GPE definition.

Sensitive data under GLI-GSF-2 includes audit logs recording game outcome information, RNG seeds, encryption keys, authentication credentials, government identification numbers, personal financial information (card and bank account data), and any other data the Regulatory Body or Gaming Enterprise classifies as sensitive. The breadth of this definition links GLI-GSF-2 directly to AML and KYC obligations: patron financial records subject to FINTRAC reporting in Ontario or FIAU reporting in Malta are squarely within GPE scope.

The Three Core Assessment Methods and What They Test

A GTS Assessment deploys three distinct assessment methods. Interview involves structured discussions with personnel to gather context, clarify configurations, and locate evidence. Examine involves checking, inspecting, and reviewing documentation, configurations, and logs. Test involves exercising systems under specified conditions to compare actual versus expected behaviour. All three methods are used in combination, and a penetration test without documentary review and personnel interview does not satisfy the GLI-GSF-2 standard.

At the task level, the assessment is structured around three principal components: Vulnerability Assessments, Penetration Tests, and Risk Assessments. The Appendix to GLI-GSF-2 details minimum test requirements for each. The ISF is directed to the Appendix to ensure no required tests are overlooked during scope agreement.

Vulnerability Assessments use primarily automated scanning to identify weaknesses, complemented by manual validation. They do not require exploitation. Penetration Tests go further: they involve, in the standard’s words, “some form, of manual verification and/or exploitation.” The penetration test evaluates security from an attacker’s perspective by actually attempting to exploit identified vulnerabilities. Risk Assessments identify threats, vulnerabilities, and non-conformities that may not appear explicitly in the GTS test catalogue, scored using an appropriate system such as CVSS or ISO/IEC 31010.

Penetration Testing Scope: The Four Principal Test Domains

GLI-GSF-2 Appendix C defines the mandatory penetration testing domains. Each has a specific objective and a defined target set.

Internal Network Layer Penetration Test (C.1) simulates an attacker who has already gained a foothold within the internal network. The objective is to exploit vulnerabilities within the internal infrastructure of the GPE. Targets include servers within the DMZ or LAN, workstations and other network devices, and all Critical System Components accessible from the internal network. The test covers privilege escalation and lateral movement, VLAN effectiveness and segmentation testing, and access control validation to verify that lateral movement between network zones is genuinely restricted.

External Network Layer Penetration Test (C.2) simulates an attack by an external threat actor attempting to breach the GPE through external-facing systems. It covers system enumeration and service discovery, attack simulation including initial exploitation attempts and privilege escalation if access is obtained, and bypass testing against perimeter defences. The bypass testing element is significant: the ISF must assess whether Web Application Firewalls, Content Delivery Networks, Deep Packet Inspection services, and denial-of-service protection can be circumvented. GLI-GSF-2 states that the ISF “should have full visibility and the ability to bypass certain protection, including all Service Provider security-enhancing services” to allow accurate assessment, because those services can mask underlying vulnerabilities when in active operation.

Application Layer Penetration Test (C.3) covers all application types associated with the GPE: web applications, mobile applications, and desktop applications. For web applications, this includes passive information collection (Google dorking, DNS enumeration, technology fingerprinting), cross-site scripting and injection attack testing, file upload handling assessment, client-side validation bypass testing, error handling and information disclosure review, and session management testing. For mobile applications, the test extends to API security, insecure use of device features, and dependency management for third-party libraries.

Beyond these three core domains, GLI-GSF-2 Appendix D covers the Cloud and Container Security Assessment. For cloud components, the ISF must verify least-privilege access policies, MFA on critical accounts, logging and monitoring of all critical actions, and security configurations including encryption of data at rest and in transit. For containerised environments, the assessment extends to orchestration platform security (control plane, node security, workload isolation), RBAC settings, network segmentation within the container environment, runtime monitoring, patch management for container images, and supply chain security including CI/CD pipeline integrity.

Additional Assessments: Firewall, Database, Social Engineering, and Adversarial Simulation

GLI-GSF-2 Appendix E defines additional assessments and tests beyond the core penetration testing domains. These are not optional add-ons: they form part of the minimum GTS Assessment requirements described in the Appendix, and the standard directs users there to ensure no required tests are overlooked.

The Firewall Security Assessment (E.1) identifies weaknesses in firewall configurations, rule sets, and management practices. The cloud firewall sub-assessment extends to IAM integration, MFA for accessing cloud firewall consoles, and automated compliance checks to verify configurations remain aligned with GIS policies.

The Database Security Assessment (E.2) ensures that databases storing PII, financial transaction data, and gaming data are secure. It covers encryption at rest and in transit, access controls, password storage verification (hashed and salted), and data governance for sensitive fields including government identification numbers, card numbers, and bank account numbers. The ISF must conduct interviews with database administrators to verify configurations visually, not merely through documentation review.

The Social Engineering Security Assessment (E.3) tests the human element of GPE security, targeting vulnerabilities exploitable through manipulation rather than technical means. This directly counterparts the technical penetration tests and addresses the reality that credential theft via phishing or pretexting is frequently the initial access vector for attacks on gaming environments.

The Adversarial Simulation Test (E.6) is the most advanced assessment type in the standard. GLI-GSF-2 distinguishes it explicitly from traditional penetration tests: “Unlike traditional Penetration Tests, the Adversarial Simulation Test mimics a highly skilled, persistent adversary aiming to breach the GPE’s defenses using any means necessary.” The test deploys OSINT and information gathering, advanced persistence techniques, data exfiltration simulation, command-and-control (C2) communications testing, privilege escalation, and credential dumping. The test also includes an incident response evaluation: the ISF assesses the detection and alerting capabilities of the GPE’s monitoring infrastructure, the speed of the incident response team in containing threats, and the forensic capability for post-incident analysis.

Assessment Frequency: Annual, Quarterly, and Event-Triggered

GLI-GSF-2 section 2.4 establishes the frequency framework.

The initial full GTS Assessment must be completed before a Gaming Enterprise commences live operations within the GPE, or before any significant change that could materially affect the GPE’s security posture. The standard is unambiguous that pre-launch assessment is mandatory, not recommended.

Annual reassessment is the default cadence: the Gaming Enterprise must have a GTS Assessment performed at least annually unless the Regulatory Body specifies otherwise. The annual assessment covers the full scope of GTS tests in the Appendix.

Event-triggered assessments apply whenever there is a “critical change” within the GPE, including infrastructure or application upgrades and modifications, or the installation of new Critical System Components. The standard acknowledges that determining what constitutes a critical change depends on the Gaming Enterprise’s risk assessment process, the specific GPE configuration, and Regulatory Body requirements, but it provides a clear default: “any change that could affect the security of the GPE or allow access to sensitive data and/or Critical System Components may be deemed a ‘critical change’.” Platform migrations, third-party service provider integrations, and material infrastructure changes will almost always meet this threshold.

Vulnerability Scans operate on a separate, shorter cycle. Unless the Regulatory Body specifies otherwise, internal and external network Vulnerability Scans must be run at least quarterly and after any critical changes. Postponement requires Regulatory Body authorisation with an updated schedule. Multi-jurisdictional Gaming Enterprises may request consolidation of scans across jurisdictions to a common schedule, but that consolidation requires regulatory approval, not unilateral scheduling.

Findings Categorisation and Remediation Timelines

The ISF must apply a scoring system, the standard names CVSS and ISO/IEC 31010 as examples, to assign severity levels across four tiers: critical, high-risk, medium-risk, and low-risk. The scoring methodology used must be identified in the GTS Assessment report. This requirement prevents informal severity classifications that cannot be compared across assessment cycles or across jurisdictions.

Remediation steps to address each identified medium-risk or low-risk vulnerability must be documented and sent by the Gaming Enterprise to the Regulatory Body and the ISF, if required by the Regulatory Body, for review within thirty days, unless otherwise specified by the Regulatory Body. If the actions are deemed satisfactory, they must be followed up at the next scheduled assessment.

The remediation timetable for critical and high-risk findings is more demanding. Quarterly Vulnerability Scans “must not occur until each critical or high-risk vulnerability is resolved and/or accepted via a formal risk acceptance programme.” This is not a documentation obligation, it is a gate. The standard blocks further assessment cycles until the highest-severity findings are resolved or formally risk-accepted. A Gaming Enterprise that discovers a critical vulnerability and proceeds to the next quarterly scan without resolution or a documented risk acceptance decision is non-compliant.

For medium-risk and low-risk findings, the thirty-day documentation obligation applies. Once remediation is completed, the Gaming Enterprise must provide the Regulatory Body and the ISF with documentation evidencing completion. Remediation records, including objective evidence, must be retained for at least five years unless the Regulatory Body requires a longer period.

The GTS Assessment report itself must be submitted to the Regulatory Body no later than ninety days after the assessment has been completed, unless the Regulatory Body specifies otherwise. The report must include an executive summary with the Gaming Enterprise’s details and an overview of its business model, gaming activities, service providers, and infrastructure, the methodology section identifying which Vulnerability Assessment framework was applied, a record of all evidence collected including screenshots, logs, and commands used, and a findings section categorising every vulnerability by severity, explaining the potential impact, recommending remediation steps with priority levels and suggested timelines, and recording the Gaming Enterprise’s response.

Independent Security Firm Qualifications and the In-House Exception

The GTS Assessment must be carried out by an Independent Security Firm (ISF). The ISF’s personnel must hold relevant educational qualifications or equivalent experience in assessing GPEs, and must maintain certifications sufficient to demonstrate competency in the testing domains. GLI-GSF-2 section 2.7 references certifications sufficient to demonstrate competency, with OSCP, CEH, and GPEN-class credentials cited in practice as examples appropriate to penetration testing engagements, and cloud security certifications expected for personnel conducting cloud and container assessments.

The ISF does not need to be an external third party for all assessment types. For quarterly Vulnerability Scans, GLI-GSF-2 section 3.6 permits scans to be performed by a qualified employee of the Gaming Enterprise acting as an ISF, provided that employee “is separate, in organisational terms, from the function which implements changes to the GPE.” The segregation requirement is structural: the scanning function must sit outside the change management function. An in-house security operations analyst who also manages patch deployment does not satisfy this independence requirement. The full annual GTS Assessment and penetration testing programme requires ISF-level expertise that most Gaming Enterprises source externally.

The broader GTS Testing methodology is grounded in published frameworks. GLI-GSF-2 Appendix A states that testing must follow methodologies prescribed by OSSTMM, OWASP, the Penetration Testing Execution Standard (PTES), and NIST Special Publication 800-115 (Technical Guide to Information Security Testing and Assessment). The ISF’s testing approach must be consistent with at least one of these recognised frameworks, and the chosen framework must be identified in the assessment report.

Relationship to GLI-GSF-1, ISO 27001, and Broader Security Obligations

GLI-GSF-2 does not operate in isolation. It is the testing module for a controls framework anchored in GLI-GSF-1. GLI-GSF-1 v1.1 in turn draws on CIS Controls, NIST frameworks, and ISO/IEC 27001 as foundational references for its GIS control requirements. The relationship between ISO/IEC 27001 and gaming-specific regulatory requirements is a practical concern for operators building integrated compliance programmes: ISO 27001 certification does not satisfy GLI-GSF-2’s penetration testing mandate, and GLI-GSF-2 compliance does not substitute for ISO 27001 where regulators require it independently.

The UKGC’s Remote Gambling and Software Technical Standards (RTS) section 4.1 grounds its security requirements in ISO/IEC 27001:2022 Annex A controls, and RTS section 4.3 defines critical systems in terms that closely mirror GLI-GSF-2’s Critical System Components definition. The MGA’s technical infrastructure requirements reference ISO/IEC 27002 for cloud-hosted components. Neither jurisdiction has formally adopted GLI-GSF-2 as a mandated standard as of this writing, but the conceptual alignment is substantial: both demand assessment of RNG infrastructure, player account systems, and transaction processing environments as a minimum scope. Operators holding UKGC or MGA licences who also operate in GLI-GSF-2-adopting jurisdictions will find significant structural overlap between their security obligations, though the specific procedural requirements, report formats, and submission timelines differ and must be tracked separately.

The KSA in the Netherlands publishes its own Gaming System Assessment Scheme (v2.1, October 2024), which establishes conformity assessment requirements for remote gambling systems. Similarly, Spillemyndigheden in Denmark operates a Certification Programme (SCP.02.03.EN) with its own technical security expectations. GLI-GSF-2 represents GLI’s attempt to provide a single globally applicable GTS benchmark that regulators can adopt wholesale or in part, reducing the fragmentation that has historically required Gaming Enterprises to commission bespoke assessments for each jurisdiction. Whether a given Regulatory Body has formally adopted GLI-GSF-2 is a jurisdiction-specific question that must be confirmed with the relevant authority.

Key Resources

GLI-GSF-2: Gaming Technical Security (GTS) Assessment v1.0, Gaming Laboratories International. Available for free download at gaminglabs.com/gli-standards. The primary source for all GTS Assessment requirements, test methodologies, ISF qualifications, and remediation obligations discussed in this article.

GLI-GSF-1: Gaming Information Security (GIS) Controls Audit v1.1, Gaming Laboratories International. The foundational controls module that GLI-GSF-2 supplements. Establishes the GIS control baseline that the GTS Assessment validates.

GLI Gaming Security Framework Overview, Gaming Laboratories International, gaminglabs.com/gli-standards. Describes the full GLI-GSF suite, module scopes, and the transition roadmap from legacy standards GLI-27, GLI-19 Appendix B, and GLI-33 Appendix B.