ESIC Launches Gold Standard Scheme for CPU vs CPU Esports Products

The Esports Integrity Commission (ESIC) has announced the launch of its CPU v CPU Gold Standard, a technical and operational integrity framework for automated esports competitions whose match outcomes are supplied to betting markets.

The Standard establishes 17 areas of mandatory controls covering the systems that generate and validate match outcomes, the infrastructure that runs them, and the people authorised to change or operate them. It provides distinct requirements for locally deployed machine-learning models, externally hosted large language model APIs, and deterministic or rules-based algorithms, alongside platform-wide security and governance obligations.

Why automated competition needs specific integrity controls

In CPU v CPU competition, software controls the competing participants. Integrity therefore depends on being able to establish which software, model, rules and configuration were in use, how they were approved, and whether the match ran under those declared conditions. A change to a build, model version, input or privileged account can affect the competitive environment without an obvious change to what spectators see.

The Standard addresses that risk through controls across the full operating lifecycle. Before a match, relevant versions and configurations must be declared and recorded. During execution, unauthorised changes and external influences are restricted, and failures trigger verification or integrity safeguards. Afterwards, retained records must support investigation and reconstruction of relevant system activity. This gives operators and independent reviewers an evidential basis for examining an outcome and assessing whether the controls operated as intended.

The framework also recognises that technical assurance depends on organisational accountability. Approval rights, independent code review, separation of duties, personnel checks and incident escalation govern who may change a system and how those decisions can be challenged. These requirements connect software integrity with the conduct of the organisation operating it.

Three decision system routes with a common integrity objective

Locally deployed machine learning models

Where an organisation trains, owns and deploys its own model, the model artifact must be cryptographically signed and verified before deployment or at initialisation. Failed signature verification must prevent execution. Deployment requires two authorised individuals, while a versioned inventory records each model’s version, cryptographic hash and team assignment. Model versions must be declared before a match and remain fixed for that match. These controls establish which approved model was used and help detect substitution or unauthorised modification.

Externally hosted large language model APIs

Closed-weight hosted models require a different assurance method because the platform operator cannot sign the provider’s underlying model artifact. The Standard therefore requires an ESIC-approved provider and model, an exact dated model identifier and a pinned endpoint. Rolling “latest” aliases and services capable of silently substituting models are prohibited. A minimum eligible version in the approved registry does not replace the requirement to lock one exact version for each match.

The provider, model identifier and relevant inference settings must be declared before the match and captured in immutable, timestamped records. Match-relevant calls must record the provider-returned model identifier, timing, prompt and response, and a response hash. An identifier mismatch halts the affected decision cycle. Provider or model changes require dual authorisation, and live internet browsing or external retrieval must be disabled. These controls make the inputs and service identity auditable; they do not assume that every hosted model response is perfectly reproducible.

Deterministic and rules based algorithms

For fixed algorithms, the exact build version and artifact hash must be recorded before the match and remain unchanged. Identical input state must produce identical output, except for explicitly declared, seeded and logged random components. Dependencies on team identity, attributes or playing style must be documented and auditable. Undisclosed triggers or hidden conditioning on match circumstances are prohibited, and code review must specifically examine dormant or conditional logic. Runtime behaviour that deviates from declared logic constitutes a failed verification event.

Controls around the software and the match

Across these routes, the Standard requires documented architecture, communication paths and deployment flows, with strict separation between build, staging and production environments. Each code change needs a pre-approved ticket from a non-engineering authority and independent review. Releases must pass automated security scanning, with no unmitigated High or Critical vulnerabilities scoring 7.0 or above under the Common Vulnerability Scoring System. Deployment requires dual authorisation and cryptographic signature verification; failed verification must reject deployment or terminate the system.

Access controls include centralised identity management, multi-factor authentication for production and sensitive systems, individual privileged credentials, just-in-time privilege elevation and quarterly access reviews. An identity-aware control plane must continuously verify identity, device trust and access policy. Default-deny firewalls, service segmentation and controlled outbound connections limit the opportunities for an unauthorised user or compromised service to reach match-critical systems.

The match lifecycle must be fully automated, with technical validation, logical data-consistency checks and anomaly safeguards that trigger automatic suspension. Documented procedures govern the investigation of failures. That distinction matters: human oversight is necessary to maintain systems and investigate incidents, while manual intervention in the automated match lifecycle is prohibited.

Centralised monitoring must retain evidence across applications, databases, virtual machines, identity systems, firewalls and hosting providers. Real-time alerts and forensic traceability help connect a suspicious result to the relevant build, access event or system condition. Configuration changes must also be approved, version-controlled and recoverable. The Standard accepts equivalent controlled and auditable deployment processes where full infrastructure automation is not used.

Ongoing security and accountable oversight

The framework makes maintenance part of integrity assurance. Infrastructure requires weekly vulnerability scanning, while production systems must be monitored continuously against newly disclosed vulnerabilities. New disclosures must be assessed within five business days. Risk-based patching deadlines are seven days for Critical vulnerabilities, 30 days for High and 90 days for Medium; unresolved issues require formal Director-level or higher risk acceptance. Emergency patching must retain dual authorisation.

Supporting obligations cover encryption, cryptographic key inventories and rotation, sensitive-data protection, personnel screening and separation of development, operations and security duties. Hosting assurance follows either independently certified cloud or colocation providers, or equivalent physical-security and resilience controls for private environments. Organisations must maintain 24/7 security monitoring, incident-response playbooks, business-continuity and disaster-recovery plans, and quarterly restoration testing.

Certification requires demonstrated compliance with all applicable mandatory components, independent audit review, continuing compliance and cooperation with ESIC oversight. Accredited organisations must participate in ESIC’s Suspicious Betting Alert Network, report integrity concerns and engage in relevant training and feedback. Accreditation may be suspended or revoked for material non-compliance. The Standard will be reviewed as threats, technologies and operating practices evolve.

Stephen Hanna, Chief Executive Officer of ESIC, said:

“The launch of ESIC’s CPU vs CPU Gold Standard Accreditation is an important milestone for the development of this competition format. As CPU vs CPU events continue to attract interest, it is important that the industry has a clear and trusted benchmark for the way they are delivered.

“This accreditation gives organisers and other stakeholders a recognised standard to work towards, while helping audiences, partners and the wider esports community have greater confidence in the competitions they follow. We look forward to working with the industry as the standard is adopted and contributes to a more consistent, transparent and credible CPU vs CPU ecosystem.”

The launch establishes a common reference for integrity assessment in automated esports betting products. Certification provides assurance against the applicable requirements and assessed scope. It is not a regulatory licence or a guarantee of future compliance, uninterrupted service or the absence of security vulnerabilities.