GLI certifies that a game, random number generator or platform meets a regulator’s technical rules. ISO accreditations certify the process or the lab behind the test. They are not interchangeable, and a licensing file usually needs evidence of both kinds.
Treating them as one badge is the most common mistake in compliance planning. It leads operators to submit a security certificate where a test report is expected, or the reverse. This article separates what each document covers, who issues it, and which regulator question it answers.
What Gli And Iso Accreditations For Igaming Compliance Actually Certify
Start with the three names, because each one does a different job.
GLI: The GLI independent gaming test lab tests gaming products against technical standards and the rules of individual jurisdictions. What it produces is evidence about a product: does the RNG behave as required, does the game math pay out as declared, does the platform meet the technical requirements a regulator has written down. GLI is a testing and certification lab, not a standards body.
ISO/IEC 17025: This standard sets out the general requirements for the competence of testing and calibration laboratories. A lab that is accredited to it has had its methods, equipment, staff competence and impartiality assessed by an accreditation body. The accreditation says the lab is competent to run certain tests. It says nothing about any particular game.
ISO/IEC 27001: This standard defines an information security management system. An organization that holds a certificate has been audited against it by a certification body. For an iGaming business, that covers how player data, payment data and internal systems are protected and managed, not whether a slot pays out correctly.
The International Organization for Standardization publishes the ISO standards but does not issue certificates against them. That detail matters later, when you need to verify who actually stands behind a document.
So the questions separate cleanly:
- GLI answers whether this product meets the technical standard.
- ISO/IEC 17025 answers whether the lab doing the testing is competent.
- ISO/IEC 27001 answers whether the organization manages information security systematically.
A lab can hold ISO/IEC 17025 accreditation and test your game. You can hold ISO/IEC 27001 and still ship a game that fails testing. The two sets of documents support each other in a file, but neither substitutes for the other.
How Does GLI Certification Differ From an ISO Certificate?
A GLI report tests a specific product version against a jurisdiction’s standards. An ISO certificate covers a system or an organization and does not test the game itself. One is product evidence, the other is management-system or competence evidence.
GLI certification is tied to a build. The report names the software, the version and the standard it was tested against. Change the build materially and the report no longer describes what you are running. Regulators care about this because they want the version in production to match the version that was tested.
An ISO/IEC 27001 certificate works differently. It is issued by an accredited certification body after an audit of the management system. The auditor checks that you have defined a scope, assessed risks, selected controls and operate them consistently. The certificate attests to that system. It does not attest that any given game is fair, and it does not replace a penetration test of a particular platform.
ISO/IEC 17025 sits one level further back. An accreditation body assesses the lab and lists the tests or methods it is accredited to perform. That list is the lab’s accreditation scope. A lab can be accredited for some test methods and not others, so the accreditation supports the credibility of a report without being the report.
| Document | Issued by | Covers | Tests the game? |
|---|---|---|---|
| GLI test report or certification | Test lab | A named product and version | Yes |
| ISO/IEC 17025 accreditation | Accreditation body | A lab’s competence for listed methods | No |
| ISO/IEC 27001 certificate | Accredited certification body | An organization’s security management system | No |
Two practical consequences follow. First, a logo on a website tells you almost nothing, because none of these documents is a general-purpose seal. Second, the three have different lifespans. A test report is valid for a version, a management certificate runs on an audit cycle, and a lab accreditation is reassessed on the accreditation body’s own schedule.
Which Accreditation Answers Which Regulator Question?
Regulators ask for lab-tested evidence on game fairness and for security evidence on data and payments, so each question maps to a different document. One badge cannot satisfy both, because no single document covers both a product and a management system.
Walk through a typical licensing file and the split shows up quickly.
- Is the RNG statistically sound and correctly implemented? This calls for an independent test report on the RNG, usually from a lab the regulator recognizes.
- Do the games pay out as declared? This calls for a test report covering game math, return-to-player figures and game rules for each title or version.
- Does the platform meet the technical standard? This calls for a platform-level test report covering things like game session handling, logging and wallet integrity, depending on the jurisdiction’s rules.
- How is player and payment data protected? This calls for security evidence, and an ISO/IEC 27001 certificate is a common way to present it. Your own security steps for a betting platform sit underneath that certificate, because the audit looks at what you actually operate.
- Is the testing itself credible? This is where the lab’s ISO/IEC 17025 accreditation helps, since it shows the lab’s methods have been independently assessed.
A game studio might hold a clean test report and have no information security certificate. An operator might hold ISO/IEC 27001 and rely on the studio’s reports for every title. Both can be sound. What fails is the file that offers one in place of the other.
Acceptance depends on the jurisdiction. Some regulators publish a list of approved test labs and will not accept reports from anyone else. Some name specific technical standards. Some ask for security evidence in their own format and treat ISO/IEC 27001 as supporting material rather than a requirement. In the US, requirements differ state by state, so read state betting rules in the US and how the state-by-state license process works before deciding what to commission and in what order. Confirm the current requirement with the regulator itself, not with a vendor’s summary.
Checking Scope and Expiry Before Relying on a Certificate
A certificate only counts for the scope written on it. Before you use one in a license application, check the scope, the dates and the issuing body.
Read the scope statement line by line. For an ISO/IEC 27001 certificate, the scope names the activities, locations and sometimes the systems covered. A certificate that covers a head office and a development team does not automatically cover the data center or cloud environment that hosts your player accounts. For a test report, check the product name, the exact version or build identifier, the standard applied and the jurisdiction. If the report covers version 2.3 and you are deploying 2.5, you have a gap to close.
Check the entity. The legal entity on the certificate should match the entity in your application, or you need to be able to explain the relationship. Group structures make this easy to get wrong, and it ties directly into licenses and company formation for igaming, since the entity that holds the license and the entity that holds the certificate are not always the same.
Check dates. Look at the issue date, the expiry date and, for management certificates, any note about surveillance audits. An expired certificate is a finding. A certificate that expires during the review of your application is a risk you can manage by planning the renewal early.
Verify with the issuer, not the holder. For ISO/IEC 27001, confirm that the certification body is itself accredited and that the certificate appears in the body’s public directory or can be confirmed with them directly. For a testing lab, find the lab in the accreditation body’s public directory and read its schedule of accredited activities. Match the methods listed to the testing performed on your product. The same applies to a certificate from a vendor you depend on, such as a game provider or payment partner.
Ask for the full report. A logo, a badge or a one-page letter is not evidence. Request the complete test report or the full certificate with its scope page. Read the conditions, the limitations and any open findings. A report can be valid and still carry conditions that affect how you deploy the product.
If a supplier cannot or will not share the document, treat the claim as unverified.
Keeping Gli And Iso Accreditations Current After Each Release
Accreditations need upkeep. Every software release or system change can fall outside the tested scope, so you need a process that notices when it does.
Re-testing on change. When a game build or an RNG changes, the earlier report no longer describes the product. Whether you need a full re-test, a delta review or only a notification depends on the jurisdiction and the nature of the change. Cosmetic changes, a new game math model and a new RNG implementation sit at very different points on that range. Ask the lab and the regulator early, and agree how changes are classified before you build the release plan around them.
Change control that flags scope drift. Tie your release process to your certified scope. A practical way to do it is to keep a register that lists each certified product, the tested version, the report reference and the jurisdictions it was approved for. Every release ticket then asks one question: does this change touch anything in the register? If the answer is yes, the release waits for a compliance decision. The same logic applies to infrastructure. Moving hosting, adding a new payment integration or opening a new office can move you outside an ISO/IEC 27001 scope.
Surveillance audits. ISO management certificates run on a multi-year cycle, and the certification body typically performs surveillance audits between the full recertification audits. These are shorter, but they can raise findings. Treat them as a standing part of the operating calendar rather than a surprise. Lab accreditations under ISO/IEC 17025 are likewise reassessed by the accreditation body, so check that the lab you used still holds the relevant scope when you come back for new testing.
A practical checklist for an operator or platform provider:
- List every certified product, version, report reference and approved jurisdiction in one register.
- Record the scope, issuer and expiry date of each ISO certificate you hold or rely on.
- Verify each lab and certification body in the public directory of its accreditation body.
- Obtain full reports and certificate scope pages, never logos alone.
- Add a compliance gate to the release process so any change to an RNG, game math or hosting setup is reviewed before deployment.
- Agree with the regulator and the lab how each type of change is classified.
- Put surveillance audits and renewal dates on the shared calendar at least one quarter ahead.
- Match the legal entity on every document to the entity named in the license application.
None of this is exciting work. It is what keeps a license file accurate after the day you submit it.
