This is the presentation that BMM testlab gave in March 2019 in Stockholm to an audience of gaming operators. It explains the process of having a gaming platform certified by by an accredited laboratory. It also looks at the paragraphs from the new regulations that specify requirements for risk assessment and change management. It also answers some frequently asked questions.

1. company confidential
CERTIFICATION PROCESS
THE SWEDISH LICENSE DAY
March 2019

2. company confidential
The Role of the Laboratory

3. company confidential
Certification Process
SWEEP OF TESTING
Submission
Testing
Results
SubmissionTesting
Results
…
Sweep 1
Sweep 2
• Submission: Provision to BMM of the
Object of Testing
• Testing: activities performed by BMM to
evaluate the Object of Testing for
compliance
• Results: BMM’s recap of testing results
A sequence of submission, testing and results
is referred to as Sweep of testing

4. company confidential
Certification Process
SUBMISSION – SUBMISSION MATERIAL
The Submission represents the action, by the Operator (B2C/B2B), of providing BMM with the Object of Testing, meaning all the material
needed in order to kick off the Testing phase.
Depending on scope, technology used and Jurisdiction, the submission material may correspond to the following:
• Complete Source Code and Binaries;
• Access to the system (links, credentials);
• Creation of accounts on the back office application/s to be used for tests purposes;
• Test accounts with money available that can be used for testing purposes;
• Documents/internal procedures based on Jurisdictional specific requirements;
• Math documents (par-sheets);
• Results forcing tool (if any).

5. company confidential
Certification Process
SUBMISSION – SUPERVISED BUILD AND INSTALL
The Supervised Build and Install (SBI) is a process aiming to allow BMM to “take a picture” of the Object of Testing. The goal is to identify
and track the direct relationship between:
• The Object of Testing
• The Results
The need for a Supervised Build and Install is not related to a specific Jurisdictional Requirement. The Supervised Build and Install is
necessary to satisfy BMM’s accreditation requirements derived from the ISO standards 17020/17025
The process consists of 2 subsequent steps:
1. The Supervised Compilation (Build) process;
2. The Supervised Deployment (install) process.
Depending on the Technology used, The Supervised build and process is performed using different tools, i.e.:
• Remote Desktop connection/sharing (VNC, Skype, TeamViewer etc.)
• BMM Signatures tool (BMM digital signatures calculation tool, provided by BMM)
• Secure transfer protocol (SFTP or other)

6. company confidential
Certification Process
SUBMISSION – SUPERVISED BUILD
The Supervised Build is the process during which the Source code is located, hashed, built and provided.
Through a recorded Remote Desktop Sharing session, a member of the BMM’s delivery team will observe the compilation (build) process performed by the
Operator’s technical team. The source code object of the Supervised Build will be the one implementing the system modules responsible to fulfil the
Jurisdictional Requirements in scope.
For each part of the source code, the following steps will be performed:
1. Locate the source code root directory. Locate the destination folder, where the compilation output files (binaries) will be generated;
2. Hash the source code using one of the following algorithms: SHA-1, MD5;
3. Build (compile) the source code. The compilation process need to be run only on the source code files, not on any pre-compiled class or object
files. Additionally, the compilation command need to be run in a verbose mode and the output need to be redirected to a .txt file (where
applicable);
4. Hash the binaries output of the build (compilation) process;
5. Provide the source code, binaries and hashes to BMM (through SFTP, etc.).
The above is a generic process. Alternative approaches can be discussed in order to accommodate needs deriving from specific technologies used or
implementation.

7. company confidential
Certification Process
SUBMISSION – SUPERVISED INSTALL
The Supervised Install is the process during which the Binaries, generated during the Supervised Build process, are
deployed (installed) on the testing environment for BMM to access and commence the Testing phase.
The Supervised Install process is performed during a recorded Remote Desktop Sharing session. A member of the BMM’s
delivery team will observe the deployment (install) process performed by the Operator’s technical team.
In case the Supervised Install process is performed through a different supervised session from the one used to perform
the Supervised build, an additional step will occur. An additional “signatures check” will be performed on the deployed
packages, to ensure the Binaries installed on the test environment match the ones produced during the Supervised build
process.
The above is a generic process. Alternative approaches can be discussed in order to accommodate needs deriving from
specific technologies used or implementation.

8. company confidential
Certification Process
SUBMISSION – TO REMEMBER
When it comes to a Certification Process based on Sweep of Tests, it’s important to remember:
• the first step of the certification process is always the Supervised Build and Install. Beside few exceptions (i.e.
documental reviews) the Testing phase cannot commence before the Supervised Build and Install is completed.
• during the Testing phase, time between the Submission and Results phases, no changes are allowed to the
supervised system. However, If urgent updates have to be applied to the supervised system during the sweep of tests,
they have to be announced and agreed with BMM in advance;
In case Non Compliances (DIRTS/ISSUES) have been discovered during a sweep of tests, the Operator has the right to
modify the supervised platform in order to fix them, as long as the current Sweep of tests has been completed

9. company confidential
Certification Process
TESTING PHASE
The Testing phase defines the activities performed between the Submission and Results phases.
During the Testing phase, BMM Engineers commence the actual evaluation (functional and security) of the Object of Testing provided during the Submission
phase. During this process, a specific set of testing activities are ran on the Object of Testing in order to verify the compliance against the Jurisdictional
Requirements in scope.
Depending on the product submitted and the overall scope, the activities could vary among:
• Source code review
• Artwork review
• Combination testing (Emulation)
• Math evaluation (RTP% calculation)
• Random Number Generator (RNG) mathematical evaluation
• Registration/Transactions
• Games deactivation/interruption
• Generation of data reports (account related, gaming related, finance related, etc.)
• Documentation review
• Security audits (on-site / remote)
• Security assessments
During the Testing phase, no changes are allowed to the supervised system (except pre-agreed monitored exceptions). Applying uncontrolled and
unsupervised changes on the Object of Testing during the Testing phase might result on the invalidation of the related results, with the consequent need of
repeating the testing already performed.

10. company confidential
Certification Process
RESULTS PHASE
The Results phase is the last phase of the Sweep of Tests and consists of a combined analysis, between BMM and the Operator, on the
non-conformities (DIRTS/ISSUE) eventually discovered during the Testing phase.
Non-conformities could be of different kind:
• DIRTs (issue): this type of non-conformity defines aspects of the system that does not comply with a specific Jurisdictional
Requirement in scope. The Operator is forced to fix these non-conformities in order to obtain the final Certification Report (except
particular scenarios for specific Jurisdictions).
• Observations: This type of non-conformity defines aspects of the system that:
• Either partially comply with a specific Jurisdictional Requirement in scope
• Either are not clear or do not properly function but do not affect any of the Jurisdictional Requirements in scope
The Operator is not forced to fix these non-conformities in order to obtain the final Certification Report.
During the Sweep of Tests the Non-conformities are communicated to the Operator in two different moments:
• Regularly (monthly weekly, every other day, etc.) during the Sweep of tests
• Through a non-conformity Report at the end of the Sweep of Test
The Operator is not allowed to deploy the fixes on the testing environment until the current Sweep of Tests is completed.

11. company confidential
Certification Process
SECURITY – INFORMATION SECURITY MANAGEMENT SYSTEM
The Information Security Management System (ISMS) audit is an activity, usually performed on-site, performed to verify that the
Operator’s Information Security framework complies with a combination of the ISO 27001 standard and, eventually, additional specific
Jurisdictional Requirements.
The ISMS audit is not a technical audit. It is conducted through a combination of policies/procedures/samples review and face to face
interviews with relevant Operator’s staff responsible for Information Security.
The audit spread across the following areas:
• Protection of information
• Personnel administration
• Access restrictions
• Authentication
• Communication and operation
• Storage of registered inforamtion, events and logs
• Time reference
According to the Swedish Regulation, an organization holding a valid ISO/IEC 27001:2013, covers all the areas above, will be considered
compliant, as long as the certificate, associated risk assessment and Scope of Applicability are evaluated by an accredited laboratory.

12. company confidential
Certification Process
SECURITY – VULNERABILITY AND RISK ASSESSMENT
The Vulnerability and risk assessment process consists in the Operator evaluating and rating the criticality of the Components baseline
according to best industry practices. The Swedish regulator suggests the use of the technique described in the ISO 31000:2009 standard.
BMM will review two aspects:
• the documents framework describing the technique used for vulnerability and risk assessment;
• the Components baseline according to Chapter 5 of the LIFS 2018:8, to verify the following information is provided for each
component included in the baseline:
 a definition of the information asset;
 a unique identification number;
 a version number;
 identifying features of the information asset;
 decision maker entitled to make decisions regarding changes in the information asset;
 internal risk evaluation;
 checksum for information assets classified as some relevance or high relevance.
 the geographical location of physical information assets.
According to the Swedish Regulation, an organization holding a valid ISO/IEC 27001:2013, covers all the areas above, will be considered
compliant, as long as the certificate, associated risk assessment and Scope of Applicability are evaluated by an accredited laboratory.

13. company confidential
Certification Process
SECURITY – VULNERABILITY AND RISK ASSESSMENT – COMPONENTS CRITICALITY
According to ISO 31000:2009 and the Swedish standard, when rating the criticality of a component, 4 attributes need to be taken into
account:
• Integrity - the integrity of the gambling system, it’s functionality and the information stored in the gambling system.
• Availability - the availability of information concerning the customer.
• Confidentiality - confidential information concerning the customer (e.g. identification and transaction information).
• Accountability - user activity (including customers, personnel and third parties) in relation to the component.
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 criteria:
• 1: no relevance - the component can have no negative impact on the criteria,
• 2: some relevance - the component can have an impact on the criteria,
• 3: substantial relevance - the criteria is related to or dependent on the component.
The highest relevance code of the four criteria determines the classification of the component
The classification of the Components is Operator’s responsibility.

14. company confidential
Certification Process
SECURITY – VULNERABILITY AND RISK ASSESSMENT – ISO VALIDATION
According to the Swedish Regulation, an Operator holding a valid ISO/IEC 27001:2013, covering all the requirements of
Chapter 4, 5 and 6 of the LIFS 2018:8, will be considered compliant, as long as the certificate, associated risk assessment
and Scope of Applicability are evaluated by an accredited laboratory.
What does BMM do to validate an Operator that is already ISO 27001:2013 certified?
• BMM requests the ISO certificate, associated Risk Assessment and Scope of Applicability;
• BMM evaluates the validity of the ISO certificate
• BMM determines if the implemented ISMS covers (based on the Scope of Applicability) every requirement
for the chapters 4, 5 and 6 of the LIFS 2018:8.

15. company confidential
Certification Process
CHANGE MANAGEMENT
1 Year
L
H
Production Environment
Testing Environment
1.0
1.0
L
1.1
H
1.1
L
1.1
L
H
1.1
1.1
L
H
1.1
1.3
L
H
1.1
1.4
L
1.3
L
1.4
C
1.2
L
H
1.2
1.4
L
2.0
H
2.0
L
H
2.0
2.0
• Any change to High Relevant
Components needs to be
certified before the
deployment to Production Env.
• Changes to Low Relevance
Components can be deployed
to Production Env. without
certification
• After 1 year, both High and
Low relevance components
must be re-certified
This didn’t change and
remained the old version
because the new one needs
certification before going to
production!
Now it changes cause the
new version has been
certified

16. company confidential
FAQ
SECURITY – VULNERABILITY AND RISK ASSESSMENT – CLOUD SYSTEMS
The Swedish regulation does not provide much information with regards the classification of components in case of CLOUD solutions are
adopted. The only paragraph available in LIFS 2018:8 on this regard states:
“Depending on whether and how virtualization, e.g. cloud services, is used in the gambling and ERP systems, redundancy and availability
of data may be affected. Different methods of virtualization may entail different classifications of an information asset. The license holder
should be attentive to how the classification of a hardware information asset is affected and possibly changed depending on the internal
or external selection or development of virtualization. If an external cloud service provider is used, it should be ensured that they meet the
requirements set out in the regulations.”
Due to the similarities between the Swedish and Danish standards, a good practice to assess Components residing on CLOUD solutions
can be found in the Danish standard SCP.06.00.EN.1.1, specifically paragraph 3.3.4. The Danish regulation distinguishes between 2 CLOUD
solutions: PRIVATE and PUBLIC.
For further information on the Danish standard with regards CLOUD solutions, please contact Francesco Bianchi at
Francesco.bianchi@bmm.com

17. company confidential
FAQ
SECURITY – COMPONENTS REGISTER AND B2B PROVIDERS
“If a B2B game supplier is NOT certified according to chapter 4-6 in LIFS 2018:8, does all the Information Assets of the B2B
supplier need to be incorporated in the operators’ IA register, and does changes to these Information Assets need to be
handled within the operators certified change process? If yes, do you see this to be possible to execute in practice? Not the
least, since a B2B supplier can have multiple operators as customers”
What are the advantages of a B2B that was independently tested against chapters 4-6 of LIFS 2018:9?
• The IA register of the B2B is already defined and can be incorporated as is in the Operator’s one;
• Whenever the B2B provider proposes a change to a component in the IA Register, the Operator will have a higher
confidence that the risk assessment and criticality evaluation of the change has been performed following a change
management process compliant with the Swedish regulation.
• Last but not least, the Information Security Management System (Chapter 4) that will be performed on the Operator’s
system will not have to include the infrastructure of the B2B provider
Also in this case, the Danish regulation provides a definition of good practices to be applied to properly manage the
relationship between B2Cs and B2Bs in the context of the change management: SCP.06.00.EN.1.1, specifically paragraphs
4.3.1 and 4.3.2. For further information please contact Francesco Bianchi at Francesco.bianchi@bmm.com

18. company confidential
Questions?