GLI Change Management Program Guide v1.0: Updating Certified Games Without Full Re-Certification

Certified iGaming products do not exist in a static state. RTP adjustments, new bonus features, math model revisions, and platform infrastructure changes occur throughout a product’s commercial life. Without a structured change management framework, every material update would require a full re-certification engagement, which is commercially unworkable for suppliers operating across multiple jurisdictions simultaneously. The GLI Change Management Program Guide v1.0, published by Gaming Laboratories International on 6 May 2020, provides the operational architecture that makes ongoing product evolution possible within regulated markets while preserving the integrity assurance that certification delivers.

This article maps the CMP framework in full: the three-tier change classification system, the procedural requirements for each tier, the mandatory certification obligations that remain regardless of change classification, and the practical documentation a technology supplier or licensed operator must maintain to keep a CMP compliant. Operators and suppliers should confirm with qualified legal counsel how their applicable regulatory bodies have incorporated or supplemented the CMP framework, as jurisdictional overlay can alter specific procedural requirements.

Why the CMP Exists: The Regulatory Problem It Solves

Initial certification establishes that a product meets all applicable technical and regulatory requirements at a specific point in time. The licensed operator and technology supplier are responsible for ensuring all products deployed within gaming jurisdictions are certified in accordance with the rules and regulations of those jurisdictions and are accompanied by formal certification documentation. This obligation is clear and absolute at go-live.

The problem is that modern iGaming platforms are not static. A remote gaming server may host hundreds of game themes, each of which can receive RTP adjustments, new feature variants, or math model updates on a release cycle measured in weeks. A platform vendor may push infrastructure changes that affect firewall configurations, database structures, or backup hardware. Requiring full independent laboratory testing for every such change would make agile product development incompatible with regulated market participation.

The CMP resolves this tension by establishing a risk-tiered approach. Changes are classified by their impact on regulated components. Low-risk changes proceed under a notification regime. High-impact changes require advance notice with passive approval rights assigned to the regulatory body. The framework draws on existing change management programmes from Denmark’s Spillemyndigheden (SCP.06.00), Sweden’s Lottery Inspectorate (LIFS 2018_8), Portugal’s Regulation No. 903-B/2015, and the UK Gambling Commission’s Testing Strategy for Remote Gambling and Software Technical Standards, among others, making it a synthesis of mature regulatory approaches rather than a novel construct.

The Three-Tier Certification Structure

Before reaching change classification, the CMP establishes three certification types that co-exist and each carry distinct obligations.

Initial Certification is the full independent laboratory assessment required before any product enters a regulated jurisdiction. The licensed operator and technology supplier are jointly responsible for ensuring certification documentation is in place prior to deployment.

Annual Certification requires that every product operating under a Change Management Programme be fully certified at least once per year. This is a non-waivable obligation absent specific regulatory body direction to the contrary, and it applies across all jurisdictions in which the product operates. The certification must be accompanied by formal documentation from an independent test laboratory with knowledge of the product. A hardship waiver mechanism exists, but granting any extension is at the sole discretion of the applicable regulatory body.

Change Management Certification governs the approval of the CMP framework itself. The change management policies and procedures developed under the guide must be approved by the regulatory body before the CMP is deployed, and the programme must be audited at the regulatory body’s discretion thereafter. The CMP cannot operate as a self-authorising internal process: it requires formal regulatory acceptance before a technology supplier or operator can rely on it to manage post-certification changes.

Building the Critical Asset Register

The operational foundation of a functioning CMP is the Critical Asset Register (CAR). Every component of the platform or product must be identified and recorded before change classification can operate correctly. The CAR must include hardware and software components along with the inter-relationships and dependencies between them.

Each component is assessed against four classification criteria. Confidentiality covers information relating to the platform’s players, including identification data and transactional information. Integrity addresses whether the component affects the functionality of the platform or influences how information is stored or handled. Availability concerns the availability of player information. Accountability examines the degree to which the component influences user activity.

Each component receives a relevance code of 1 (no relevance to the criteria), 2 (some relevance), or 3 (substantial relevance, where the criteria are related to or dependent on the component). This scoring informs whether a change to that component will land at Level 1, 2, or 3 in the change classification matrix. A component rated 3 for integrity is not a candidate for Level 1 treatment when modified.

The Change Management Log (CML) records every new installation and modification and must capture, as minimum items: the date of the installation or modification, details of the reason or nature of the change, identification of the component being changed including its unique ID from the CAR and version information, the physical location of hardware components, the identity of the person responsible for authorising the change, the identity of the person conducting the change, the anticipated release date, and the level assigned to the change.

Change Classification: Level 1, Level 2, and Level 3

The Guide defines three change levels. The classification determines the procedural pathway before and after deployment.

Level	Label	Pre-Deployment Requirement	Post-Deployment Testing	Example Changes
Level 1	No Impact	None, deploy without notification	None required	Backup software/hardware, OS security patches, background images, colour schemes, user account additions/removals, non-critical database maintenance, scheduled infrastructure outages
Level 2	Low Impact	3 business days advance notice to regulator and ITL	Within 90 days if certification not required pre-deployment	Firewall rule changes, database maintenance, physical location changes for regulated backup data, physical hardware component additions
Level 3	High Impact	3 business days advance notice to regulator and ITL	Within 90 days if certification not required pre-deployment	Implementation of a new gambling feature, modifications to game logic components with high impact on regulated components or reporting

Level 1 changes have no impact on regulated components. The Guide’s illustrative examples include backup software or hardware changes, adding or removing user accounts, non-critical database maintenance, scheduled network or electrical infrastructure outages, OS security patches, and background images or colour scheme updates. These can be deployed without any notice obligation.

Level 2 changes carry low impact on platform integrity and may include hardware component changes. The examples in the Guide cover firewall rule changes, database maintenance, changes to the physical location of regulated primary backup data, additions of physical hardware components, and changes to non-game logic components that fall outside the benign scope of Level 1 but do not reach the high-impact threshold of Level 3.

Level 3 changes have high impact on regulated components or reporting. The Guide’s examples include the implementation of a new gambling feature and other changes that materially affect the regulated core of the platform. RTP adjustments, changes to game math models, addition of new bonus mechanics, and modifications to core game logic components sit at this level. Under GLI-19 v3.0’s requirements for RTP documentation, each change to a game’s theoretical RTP percentage results in that game being treated as new for all reports and records, signalling the significance regulators and independent test laboratories attach to these changes. A new paytable or math model revision submitted for certification under the GLI Composite Submission Requirements v2.0 requires new source code submission, identification of the previously certified software version, and a description of the change written in terms sufficient for test case scenario construction.

The Notification Procedure for Level 2 and Level 3 Changes

For Level 2 or Level 3 changes, at least 3 business days advance notice must be provided to the regulatory bodies and the independent test laboratory that performed the prior certification. This is a minimum threshold, not a guideline.

The regulatory body or the independent test laboratory, if delegated by the regulatory body, retains the right to request testing and potentially full certification of platform updates prior to implementation. If regulatory policy does not designate additional rules for handling Level 2 or Level 3 changes, and no requirement for additional testing is communicated within 3 business days of notice, passive approval is conveyed. Under passive approval, the licensed operator or technology supplier may proceed to introduce the change into production.

The regulatory bodies or the independent test laboratory, if delegated by the regulatory bodies, reserve the right to request testing and potentially certification of the platform updates prior to implementation. If regulatory policy does not designate additional rules for handling of Level 2 or Level 3 changes and notice is not provided of a requirement for additional testing within 3 business days, passive approval is conveyed.

The passive approval mechanism is commercially significant, but it carries a risk that compliance teams must communicate to product and engineering managers. Passive approval is not permanent regulatory clearance. The regulatory body retains all rights after deployment, including the right to conduct analysis of any change and to require retrospective certification or corrective action. A notification filed late, or not at all, removes the passive approval pathway and exposes a production change to challenge on the basis that it was deployed on a system that is no longer in the certified state.

Post-Deployment Testing: The 90-Day Rule

In cases where certification of Level 2 and Level 3 changes is not required prior to deployment, laboratory testing of those changes must be completed within 90 days of introduction into the production environment. This is a binding obligation, not an administrative aspiration.

The 90-day window is designed to ensure that post-deployment verification occurs before changes accumulate beyond the capacity of a single testing cycle. The testing cycle itself does not preclude the operator or technology supplier from continuing to develop and introduce further changes under the CMP during the 90-day period. Findings from each testing cycle are reported via structures agreed with each regulatory body.

A hardship waiver mechanism exists for the 90-day rule. A technology supplier may seek approval for an extension beyond 90 days where hardship can be demonstrated, but granting a waiver is at the sole discretion of the regulatory body. Compliance teams should not plan product release schedules that depend on waiver approval.

The Emergency Rule

In emergency situations involving open threats or liabilities, a licensed operator or technology supplier may execute Level 2 or Level 3 changes immediately without prior consent. Notice must be provided to the regulatory bodies as soon as possible and in accordance with any established emergency rule regulations.

The emergency notice must include the necessity for employing the emergency rule and all details known at the time concerning the needed update. The regulatory body retains the right to conduct analysis of each emergency instance. In practice, the emergency rule is designed for genuine security vulnerabilities and live operational threats, not for accelerated feature deployments or missed notification windows.

Internal CMP Policy Requirements

The Guide specifies minimum requirements for the internal change management policy that a technology supplier or licensed operator must document before the CMP can be submitted to a regulatory body for approval. The policy must cover the acquisition and development of new software and hardware components, together with an appropriate software version control mechanism for all software components, source code, and binary controls.

Coding standards and internal testing standards must be documented, including specific methods ensuring that raw production data is not used in testing and that test software is not deployed to the production environment. Environment separation is mandatory: the production environment must be logically and physically separate from both development and test environments. Where cloud platforms are used, no direct connection may exist between the production environment and any other environment.

Separation of duties within the release process is required. Where responsibilities are divided between a licensed operator and a technology supplier, the delegation of those responsibilities must be explicitly documented in the CMP policy. Procedures for the migration of changes must ensure that only authorised components are implemented in the production environment, covering the process from source code version controls through internal testing and sign-off to deployment.

A rollback strategy must address unsuccessful installations or field issues. Where an external party such as an app store is a stakeholder in the release process, the strategy must account for managing releases through that third party. The emergency change procedures policy must address approval, testing, documentation, and monitoring requirements for urgent changes.

The change control processes and procedures shall be written specifically to the approach of the licensed operator and/or technology supplier to the development life cycle, but shall include at a minimum coverage of: the acquisition and development of new software and/or hardware components, an appropriate software version control or mechanism, coding standards and practices, internal testing standards and practices, and separation of the production environment from development and test environments.

Common Change Types and Their Classification

Compliance teams regularly face classification decisions on recurring change types. The following analysis applies the CMP framework to the change types most commonly encountered in practice.

RTP adjustment. Any change to a game’s theoretical RTP percentage is a high-impact change to a regulated component. Under GLI-19’s record-keeping requirements, each RTP change causes the game to be treated as new for reporting purposes. This is a Level 3 change requiring 3 business days advance notice. If the regulatory body does not request certification within that window, passive approval applies, but post-deployment laboratory testing is required within 90 days. Operators submitting for formal certification under the GLI Composite Submission Requirements v2.0 must provide a full description of the change, the affected modules, and the new source code.

New bonus feature or mechanic. The implementation of a new gambling feature is explicitly cited in the Guide as a Level 3 example. A new free-spin round, pick-bonus game, multiplier mechanic, or tumbling-reel variant on an otherwise certified game base requires Level 3 treatment. The critical distinction is whether the feature modifies game logic that affects RTP, volatility, or outcome probabilities. Features that are purely presentational, such as a new animation for an existing symbol win, may be assessable at a lower level, but this determination must flow from the CAR and component classification analysis, not from an informal judgment about visual versus mechanical change.

Math model change. Revisions to the underlying probability engine, symbol weighting, or paytable structure are Level 3 changes. The GLI Composite Submission Requirements v2.0 explicitly require new source code for any modification to existing game software, along with paytable and calculation sheets (PAR sheets) demonstrating the revised theoretical RTP. A math model change that results in a different return distribution, even one where the headline RTP figure remains within the same published range, affects regulated components and requires advance notice.

Progressive jackpot parameter changes. GLI-19 v3.0 imposes specific constraints on modifying progressive jackpot parameters once player contributions are in the pool. Changes to increment rates that affect RTP may not take effect until the current jackpot is won. These constraints operate in parallel with the CMP’s Level 3 notification requirements.

Infrastructure changes. Firewall rule changes and hardware component additions are Level 2. OS security patches are Level 1. A significant configuration modification to a platform component with substantial relevance scores for integrity or accountability in the CAR will land at Level 2 or Level 3 depending on the component’s classification. The CAR scoring is the primary reference, not the colloquial description of the change.

Jurisdictional Overlay: How Regulators Supplement the CMP

The GLI CMP guide is a framework document rather than a binding regulatory instrument in itself. Individual regulatory bodies may adopt it wholesale, incorporate it by reference into technical standards, or require supplementary procedures on top of its minimum requirements. Spillemyndigheden in Denmark and Spelinspektionen in Sweden both informed the guide’s development through their own change management programmes, and both jurisdictions impose certification obligations that operate alongside CMP procedures.

In Ontario, the AGCO’s Registrar’s Standards for Internet Gaming specify system change requirements that operators and suppliers must satisfy when updating certified gaming systems, including notice and testing obligations that a CMP framework must address. In Alberta, the AGLC’s Standards and Requirements for Internet Gaming impose comparable obligations tied to the province’s certification pathway. The key differences between AGCO and AGLC technical standards are particularly relevant for suppliers who hold certifications in Ontario and are preparing to enter Alberta’s market from July 2026 onward: both jurisdictions require CMP-compliant change handling, but the procedural overlay differs between the two regimes.

The UKGC’s Testing Strategy for Compliance with Remote Gambling and Software Technical Standards is one of the documents from which the CMP guide was developed. The UKGC’s Annual Games Testing Audit template also informed the guide’s structure. Technology suppliers familiar with UKGC change management obligations will find the CMP architecture recognisable, though they must verify that their approved CMP documentation meets the specific requirements of each jurisdiction in which their products are deployed.

For suppliers seeking to understand how change management intersects with the initial certification decision, the choice between GLI-19 (interactive gaming) and GLI-33 (event wagering) as the governing standard for a given product type is a prerequisite question. The scope of GLI-19 versus GLI-33 determines which system components fall within certification scope and therefore which components must appear in the CAR and be subject to CMP classification. The GLI Certification hub provides the broader context for how individual standards, including the CMP guide, fit within GLI’s full suite of testing and certification services.

Maintaining Compliance After Certification

The CMP does not eliminate the ongoing compliance obligations that attach to a certified product. It creates a structured channel for managing change within those obligations. Several post-certification requirements operate independently of the CMP’s change-handling procedures.

The CAR must be accurate at all times. Under GLI-19’s asset management requirements, recorded accountability for assets must be compared with actual assets at least annually, or at intervals required by the regulatory body, with appropriate action taken to resolve discrepancies. A CAR that does not reflect the current production architecture is a compliance failure, not merely an administrative gap.

Version control must be maintained for all software components, source code, and binary controls. Every entry in the Change Management Log creates a version reference that must be traceable. Regulators and independent test laboratories expect to be able to reconstruct the certified state of a system at any point in time from the CML records. Gaps in the log, whether from undocumented changes or from changes incorrectly classified at Level 1 to avoid notice obligations, directly undermine that traceability.

RTP documentation must be kept current. GLI-19 requires operators to maintain accurate PAR sheets for each house-banked game, with records showing the initial theoretical RTP, all dates and types of changes affecting it, and the recalculated theoretical RTP following each change. Where changes are processed under the CMP without triggering a formal recertification, this RTP documentation must still be updated and made available to regulatory bodies on request.

In practice, compliance teams should treat the 90-day post-deployment testing cycle as a quality gate, not a backstop. Changes that reveal compliance issues during post-deployment testing create remediation obligations while the affected product is already live in regulated markets. Pre-deployment internal testing, the separation of production from test environments, and the sign-off procedures required by the CMP policy are the first line of defence against that outcome.

Key Resources

GLI Change Management Program Guide for Systems within the Gambling Industry, Version 1.0 (May 6, 2020), the primary reference for all CMP framework requirements, available from Gaming Laboratories International at gaminglabs.com.

GLI-19: Standards for Interactive Gaming Systems, Version 3.0 (July 17, 2020), the technical standard governing interactive gaming systems, including change management policy requirements under section B.8 and RTP documentation obligations under section A.6.

GLI Composite Submission Requirements v2.0, the document governing submission requirements for modifications to certified software and hardware, including the requirement to provide new source code and paytable documentation for any change to existing game functionality.

GLI-GSF-1: Gaming Information Security Controls Audit v1.1, covers change management programme requirements under GIS-9.3 in the context of the Gaming Production Environment, including emergency change procedures and critical change review obligations.