GLI-CMP

CHANGE
MANAGEMENT
PROGRAM

GUIDE
FOR SYSTEMS WITHIN THE GAMBLING INDUSTRY

Version 1.0 – Published May 6th, 2020

Property of Gaming Laboratories International Version 1.0

1
 Contents

1. INTRODUCTION .................................................................................................................................................. 3
1.1. Scope ............................................................................................................................................................... 3
1.2. Standards Consulted ........................................................................................................................................ 3
1.3. Need ................................................................................................................................................................. 3
2. CERTIFICATION.................................................................................................................................................. 3
2.1. Initial Certification ............................................................................................................................................. 3
2.2. Annual Certification........................................................................................................................................... 3
2.3. Change Management Certification ................................................................................................................... 4
2.4. Quarterly Change Reports ................................................................................................................................ 4
2.5. Security Audits .................................................................................................................................................. 4
3. CHANGE MANAGEMENT POLICY AND PROCEDURES ................................................................................. 4
3.1. Guidelines ......................................................................................................................................................... 4
4. CRITICAL ASSET REGISTER (CAR) ................................................................................................................. 5
4.1. Classification of Components ........................................................................................................................... 5
4.1.1. Classification Criteria .............................................................................................................................................. 5
4.1.2. Relevance Code ..................................................................................................................................................... 5
4.2. Recording of Components in a CAR ................................................................................................................. 5
4.3. Control Program Verification Listing ................................................................................................................. 5
5. CHANGE MANAGEMENT LOG (CML) ............................................................................................................... 6
5.1. Classification of Changes ................................................................................................................................. 6
5.1.1. Level 1 – No Impact ................................................................................................................................................ 6
5.1.2. Level 2 – Low Impact .............................................................................................................................................. 6
5.1.3. Level 3 – High Impact ............................................................................................................................................. 6
5.2. Minimum Log Criteria........................................................................................................................................ 6
6. CHANGE HANDLING OF LEVEL 2 AND LEVEL 3 CHANGES ......................................................................... 7
6.1. Notification ........................................................................................................................................................ 7
6.1.1. Attestation ............................................................................................................................................................... 7
6.1.2. Control Program Verification Listing ........................................................................................................................ 7
6.2. Testing of Changes........................................................................................................................................... 7
6.2.1. Testing Before Deployment ..................................................................................................................................... 7
6.2.2. Testing After Deployment ........................................................................................................................................ 7
6.2.3. Hardship Waivers .................................................................................................................................................... 7
6.3. Emergency Rule ............................................................................................................................................... 7

Property of Gaming Laboratories International Version 1.0

2
1. INTRODUCTION
1.1. Scope

To provide best practice guidance on implementing a Change Management Program (CMP) to allow for Continuous
Delivery, Agile Development, or similar practices that are employed as industry-standard within technology
companies operating online or with wide diverse platforms. The CMP must extend enforcement of proper regulatory
oversight and governance while modernizing the approach to the regulatory compliance process to meet the
demands of new technology offerings. The goal of this document is to develop a framework of consistent and
uniform criteria for the industry with regard to implementation of a CMP to allow for growth, innovation, and cost-
efficiency in the development process rivaling non-gambling industries. At the same, the CMP process must be
constructed such that a focus remains on the protection of integrity of gaming and the trust in all good faith
institutions under the existing regulatory oversight architecture.

Guidance provided by this document is meant to clarify the following for licensed operators, their technology
providers, and independent test laboratories.
a. Minimum criteria for development of an official policy on Change Management at an organizational level;
b. Guidelines for the implementation and operation under the Change Management Program; and
c. Minimum uniform procedures, format, and archival requirements for all information to be captured by a
Change Management Program.

1.2. Standards Consulted

This guide has been developed by reviewing and using portions of the following documents:
a. Denmark - Spillemyndigheden’s Certification Programme Change Management Programme SCP.06.00
b. Sweden - Lottery Inspectorate's Regulation and General Guidelines on the technical requirements and
accreditation of bodies performing the inspection, testing, and certification of gaming activities (LIFS 2018_8)
c. Portugal - Regulation No. 903-B/2015 Regulation defining the Technical Requirements of the Online Gaming
Technical System
d. United Kingdom - Testing Strategy for Compliance with Remote Gambling and Software Technical Standards
November 2018 & Annual Games Testing Audit – Template June 2018
e. Indiana - Change Management Directive
f. Iowa - 491—13.6(99F) Testing. 13.6(2) Change Control

1.3. Need

Modern platforms require vigilance for vulnerability or bugs that originate from exposure to continuous threats by
way of attack, increased load, and/or interaction with hardware, network components, or operating systems and
complementary software that are constantly updating. This can be true whether operating online or a platform that
is used to manage one or more parts of an operation in a closed network environment. Both types of deployments
are exposed to these same threats. Modern systems counter these threats through techniques for developing code
in small efficient sprints to stay on top of the evolving environment. These techniques are designed to provide for
improved reliability, productivity, and overall quality, but obstacles to this approach exist in highly regulated
marketplaces such as gambling, where extensive testing is required prior to each release. The goal is not to remove
oversight and testing from the process, but to align in such a way that gambling operations can function as other
eCommerce operations to ensure a safe and stable environment with the latest features of operations in parallel
industries.

2. CERTIFICATION

2.1. Initial Certification

The licensed operator and technology supplier where separate are responsible for ensuring all products deployed
within gaming jurisdictions are certified in accordance to the rules and regulations of the jurisdictions and are
accompanied by formal certification documentation noting as such.

2.2. Annual Certification

Property of Gaming Laboratories International Version 1.0
3
Unless otherwise specified by the regulatory body, at least once annually, each product operating under a Change
Management Program must be fully certified to the rules and regulations of all jurisdictions operating therein and
accompanied by formal certification documentation from an independent test laboratory with knowledge of the
product. The licensed operator and technology supplier where separate shall be allowed to seek approval for
extension beyond the annual approval if hardship can be demonstrated. Granting of a hardship waiver is the sole
discretion of the regulatory body.

2.3. Change Management Certification

Unless otherwise specified by the regulatory body, the Change Management policies and procedures developed
in accordance with this guide shall be approved by the regulatory body prior to deployment of the CMP and audited
at an annual interval by the independent test laboratory.

2.4. Quarterly Change Reports

Unless otherwise specified by the regulatory body, quarterly reports are issued to an independent test laboratory
with knowledge of the product for review to ensure risk is being assessed according to the certified CMP and all
documentation for all changes are complete. A formal report shall be produced by the evaluating independent test
laboratory noting the review as complete.

2.5. Security Audits

Unless otherwise specified by the regulatory body, an annual security audit shall be performed to compliment the
testing and annual certification designated in req 2.2. The security audit covers the underlying operating system,
network component, and hardware changes not included in the evaluation of the gaming software re-baselined per
req 2.2.

3. CHANGE MANAGEMENT POLICY AND PROCEDURES

3.1. Guidelines
The licensed operator and/or technology supplier shall submit documentation outlining the change control
processes and procedures to be deployed within the organization and adhered to covering all steps of deployment
from initial development to build process and source code version controls to internal testing and signoff to
deployment. It is expected that the change control processes and procedures be written specifically to the approach
of the licensed operator and/or technology supplier to the development life cycle but include at a minimum coverage
of the following:
a. The acquisition and development of new software and/or hardware components;
b. An appropriate software version control or mechanism for all software components, source code, and binary
controls;
c. Coding standards and practices followed by the organization;
d. Internal testing standards and practices followed by the organization, including documented methods to:
i. Ensure that raw production data is not used in testing;
ii. Verify that test software is not deployed to the production environment;
e. Separation of the production environment from the development and test environments, both logically and
physically. When cloud platforms are used, no direct connection may exist between the production
environment and any other environments;
f. Separation of duties within the release process;
g. If applicable, establish the delegation of responsibilities between the licensed operator and/or technology
supplier;
h. Procedures for the migration of changes to ensure that only authorized components are implemented on the
production environment;
i. A strategy to cover the potential for an unsuccessful install or a field issue with one or more changes
implemented under the CMP:
i. Where an outside party such as an App store is a stakeholder in the release process, this strategy
must cover managing releases through the outside party. This strategy may take into account the
severity of the issue;

Property of Gaming Laboratories International Version 1.0

4
 ii. Otherwise, this strategy must cover reverting back to the last implementation (rollback plan), including
complete backups of previous versions of software and a test of the rollback plan prior to
implementation to the production environment;
j. A policy addressing emergency change procedures;
k. All documentation relating to software and application development, including procedures to ensure that
technical and user documentation is updated as a result of a change; and
l. Identification of licensed individuals for signoff prior to release.

4. CRITICAL ASSET REGISTER (CAR)

4.1. Classification of Components

4.1.1. Classification Criteria

The technology supplier shall classify all components of the platform or product operated under the CMP against
the following four criteria:
a. Confidentiality
• Confidential information relating to the platform’s players. For example, identification/personal
information of a player on the system or transactional information of players’ data.
b. Integrity
• The integrity of the platform, specifically any components that affect the functionality of the platform or
has an influence on how information is stored/handled by the platform.
c. Availability
• The availability of player information.
d. Accountability
• User activity, and how much influence the component in question has on the user’s activity.

4.1.2. Relevance Code

Each component shall be assigned a relevance code on the scale below based on the component’s role in
achieving or ensuring each of the above classification criteria:
a. 1 - No relevance (the component can have no negative impact on the criteria);
b. 2 - Some relevance (the component can have an impact on the criteria); and
c. 3 - Substantial relevance (the criteria are related to or dependent on the component).

4.2. Recording of Components in a CAR

All defined components shall be recorded in a Critical Asset Register (CAR). The structure of the component
register shall include hardware and software components and the inter-relationships and dependencies of the
components. The following minimum items shall be documented for each component:
a. The name/definition of each component;
b. A unique ID that is assigned to each individual component;
c. A version number of the component listed;
d. Identifying characteristics (Platform Component, DB, Virtual Machine, Hardware);
e. The Owner responsible for the component;
f. The geographical location of hardware components; and
g. Relevance codes on the classification criteria:
i. Confidentiality
ii. Integrity
iii. Availability
iv. Accountability

4.3. Control Program Verification Listing

The technology supplier shall maintain a report of all software files identified as critical control program components
along with the corresponding digital signatures of the critical control program component(s), as a minimum, the
digital signatures must employ a cryptographic algorithm which produces a message digest of at least 128 bits.

Property of Gaming Laboratories International Version 1.0

5
5. CHANGE MANAGEMENT LOG (CML)

5.1. Classification of Changes

5.1.1. Level 1 – No Impact

The change has no impact to regulated components of the platform.

Examples:
a. Installation or changes to backup software and/or hardware components;
b. Adding or removing users;
c. Database maintenance that modifies or deletes non‐critical data in the database.
d. Scheduled outages or maintenance to any network service provider infrastructure;
e. Scheduled outages or maintenance to any electrical infrastructure (generator, ATS, UPS, PDU, etc.); or
f. Installation of operating system security patches
g. Background images, color schemes, or similar ancillary front-end client updates.

5.1.2. Level 2 – Low Impact

The change has a low impact on the integrity of the platform. This may also include hardware component changes.
Examples:
a. Firewall rule changes;
b. Database maintenance;
c. Changes to the physical location of regulated primary backup data;
d. Any change or addition of physical hardware component; or
e. Changes to non-game logic components of the overall platform that are not of a benign nature as described
for Level 1 and with the exception of those representative of examples for Level 3 changes.

5.1.3. Level 3 – High Impact

The change has a high impact on regulated components or reporting of the platform.
Examples:
a. Implementation of a new gambling feature or a change to any logic impacting wagering or game logic;
b. A change impacting required regulatory reports or data used for financial reconciliation;
c. If applicable, a change implemented by the platform provider that substantially impacts geolocation services;
d. If applicable, a change impacting the handling or storage of personally identifiable information; or
e. A change to accommodate updated regulatory requirements.

5.2. Minimum Log Criteria

All changes must be documented in the CML. The technology supplier shall record installations and/or
modifications to the platform in the CML. It is the responsibility of the platform provider to create and maintain the
CML. The CML shall record at a minimum the following:
a. Date and time that a change is internally approved for release;
b. The component(s) to be changed including the unique identification number from the CAR, version
information;
c. Details of the reason or nature of the installation or change such as new software, server repair, significant
configuration modification. If the component being changed is a hardware component, the physical location
of this hardware component;
d. Identification of the person responsible for authorizing the change;
e. Identification of the person conducting the change;
f. Anticipated release date of the installation or modification; and
g. The level of the change (Level 1, 2, or 3).

Property of Gaming Laboratories International Version 1.0

6
6. CHANGE HANDLING OF LEVEL 2 AND LEVEL 3 CHANGES

6.1. Notification

For Level 2 or Level 3 changes, at least 3 business day advance notice prior to deployment must be provided to
the regulatory bodies and independent test laboratory who performed the prior certification. 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 whereby the licensed operator and/or technology
supplier are approved to introduce the change into production. Notification procedures are to be handled on a per
jurisdiction basis.

6.1.1. Attestation

Included in the notification of deployment of any change shall be an attestation of confirmation in good faith based
on internal development and testing practices and standards that the changes being introduced comply with all
laws, rules, and regulations within each jurisdiction.

6.1.2. Control Program Verification Listing

Included in the notification of deployment of any change to a critical control program component shall be a Control
Program Verification Listing report that details all control components of the platform and their latest digital
signature.

6.2. Testing of Changes

6.2.1. Testing Before Deployment

In cases where certification of the Level 2 and Level 3 changes are needed prior to deployment, laboratory testing
of these changes shall be certified to the rules and regulations of all jurisdictions operating therein and
accompanied by formal certification documentation from an independent test laboratory with knowledge of the
product.

6.2.2. Testing After Deployment

In cases where certification of the Level 2 and Level 3 changes are not needed prior to deployment, laboratory
testing of these changes shall be completed within 90 days of introduction into the production environment. The
testing process shall not preclude the licensed operator or technology supplier from continuing to develop and
introduce changes under the change management program. Establishment of the CMP shall allow for notification
of findings resulting from each testing cycle, which shall be reported via structures agreed to with each regulatory
body.

6.2.3. Hardship Waivers

The technology supplier shall be allowed to seek approval for extension beyond 90 days if hardship can be
demonstrated. Granting of a hardship waiver is the sole discretion of the regulatory body.

6.3. Emergency Rule

In emergency situations to deal with open threats or liabilities, a licensed operator or technology supplier may
execute Level 2 or Level 3 changes immediately without prior consent. Notice shall be provided to the regulatory
bodies as soon as possible and in accordance with any established emergency rule regulations. Notice shall
include the necessity for employing the emergency rule and all details known at the time concerning the needed
update. The regulatory bodies shall reserve the right to conduct analysis in each emergency instance to verify the
necessity of the actions taken.

Property of Gaming Laboratories International Version 1.0

7