Cookies on the Gambling Commission website

The Gambling Commission website uses cookies to make the site work better for you. Some of these cookies are essential to how the site functions and others are optional. Optional cookies help us remember your settings, measure your use of the site and personalise how we communicate with you. Any data collected is anonymised and we do not set optional cookies unless you consent.

Set cookie preferences

You've accepted all cookies. You can change your cookie settings at any time.

Skip to main content

Strategy

Testing strategy for compliance with remote gambling and software technical standards

Requirements for the timing and procedures for the testing of remote gambling products.

Summary

The Testing strategy for compliance with remote gambling and software technical standards (the testing strategy) sets out the Gambling Commission’s (the Commission’s) requirements for the timing and procedures for the testing of remote gambling products (that is, games and software).

This sets out:

  • what the Commission considers to be the types of testing required in order for it to be satisfied that the technical standards are being met
  • the circumstances in which independent third party testing is required and who the Commission considers appropriate to carry out that testing
  • the procedures for testing.

This is issued in accordance with sections 89 and 97 of the Gambling Act 2005 (opens in new tab) and Condition 2.3 of the Commission’s Licence conditions and codes of practice (LCCP). The Act allows for the Commission to set technical standards and allows for administration of testing, whilst the LCCP requires relevant licensees to comply with the Commission’s technical and testing requirements1.

The Commission has an outcome-based approach to compliance with its technical standards. In a similar manner, the Commission takes a risk-based approach to producing the testing requirements taking into account:

  • the likelihood of non-compliance occurring
  • the impact of non-compliance
  • the means available to assess compliance and the burden imposed by the approach.

Remote technical standards (RTS)

This testing strategy should be read in conjunction with the Remote gambling and software technical standards (RTS).

The RTS can be categorised into two main areas:

  1. the technical standards covering how remote gambling should be offered including the fairness of games, player account functionality and other information provision aspects.
  2. security standards covering the licensee’s Information Security Management System.

While we would expect licensees to at all times ensure they are compliant with all aspects of the RTS we have designated certain aspects for which an element of independent compliance assurance is required. Table 1 sets out the level of assurance required for testing against different technical standards.

Pre-release testing and annual game testing audits

The testing strategy sets out the circumstances in which independent third party testing is required. The Commission maintains and has published a list of approved test houses (opens in new tab) that can perform third party testing. Licensees and their chosen test house will need to agree the scope of testing and this must be sufficient to ensure that testing will adequately assess compliance with the Commission’s standards and meet the level of testing required under this strategy.

For the technical standards this external assurance mainly applies to the fairness elements of RNG driven products such as casino, bingo and virtual betting. Licensees must ensure that all new products have been adequately tested by an approved test house prior to release and evidence of this (test report) has been supplied to the Gambling Commission2.

Some retesting will be required for updates to existing games that affect a game’s fairness. This strategy outlines what type of updates will generally constitute something requiring external retesting (called a major change) and what can be updated solely in reliance on internal processes and testing (minor changes).

To ensure licensees are correctly categorising changes (that is, major or minor) and following defined procedures for the development, testing, release and RTP monitoring of games an annual games testing audit will be required. See section 4 - Annual games testing. This audit will be conducted by an approved test house and will apply to those licensees who develop, update and procure the external testing of RNGs and games.

Security standards: annual security audit

The information security standards are based on the international standards ISO 27001 and cover all critical gambling systems and operations. Applicable remote licensees need to undergo an annual security audit conducted by an independent and suitably qualified auditor. Licensees must keep their security audit on file once completed, except in cases where requested or major non-conformities are identified which require the licensee to submit a copy of the security audit to the Commission within 7 days.

Live dealer operations: compliance inspections

The June 2017 RTS introduced standards (RTS 17) for the operation of live dealer studios. The new requirements will apply to any live dealer licensed by us. For compliance assurance purposes, where the studio has been audited by another jurisdiction, and that audit sufficiently covers the provisions set out in RTS 17, then it won’t be necessary to obtain another audit just for our purposes. If no relevant audit has been performed then one will be required to satisfy our compliance purposes.

References

1 Non-compliance with the RTS would be considered a breach of a licence condition and therefore reportable as an LCCP event notification.

2 Where a licensee relies on a B2B for the provision of games they will receive a games register reference from the B2B which, once uploaded to their games register in eServices (opens in new tab), links test reports.

Previous section
Contents page
Next section
Testing strategy for compliance with remote gambling and software technical standards - Approach
Is this page useful?
Back to top