Penetration Testing and Incident Response for Gambling Operators

Penetration testing for a licensed gambling operator answers one question: can an attacker reach player funds, player records or game outcomes from where they stand today. Few regulators prescribe the test itself. They prescribe the control set, the independent audit that evidences it and the clock that starts the moment something breaks. GICNT-DS follows that structure, and so do the data security requirements behind it.

How the UKGC Treats Security Testing Under the RTS

The Gambling Commission sets its security expectations in section 4 of the Remote gambling and software technical standards. Those requirements draw on Annex A of ISO/IEC 27001:2022, which replaced the 2013 edition, and they apply to a defined group of critical systems: anything that records, stores, processes, shares, transmits or retrieves sensitive customer information, anything that generates or processes the random numbers behind game outcomes, anything holding the state of a customer gamble, the points of entry to and exit from those systems, and the networks carrying sensitive customer data.

The obligation attached to that control set is an audit, not a test. Remote and specified remote lottery licensees must have an ISO/IEC 27001 audit of remote gambling systems carried out annually by an independent, suitably qualified auditor. A newly licensed operator has six months from the grant of its licence to complete the first audit, and must supply the report within 7 days of the due date the Commission sets. Later audits stay on file. Where the auditor records a major non-conformity, the licensee sends the full report and the management responses to the Commission within 7 days of receiving it, and the Commission can request any audit at any point on the same turnaround. Non-compliance with the RTS breaches the LCCP licence conditions rather than sitting as a technical footnote.

The 2022 update also brought in control 5.23 on information security for cloud services, and audits have run against the updated control list since 1 November 2024.

Penetration testing appears nowhere in that control list. What the list does name is control 8.29 on security testing in development and acceptance, and control 5.35 on independent review of information security. No policy document satisfies either one. An operator that cannot show how it verified those controls in a live environment has an audit finding waiting for it, and a penetration test is the ordinary way of closing the gap.

Scope and Frequency Requirements Compared Across Jurisdictions

Security audit requirements for online casino platforms diverge once you leave Great Britain. Some regulators name the penetration test in the rule text. Others buy the same assurance through an audit programme and leave the method to the operator. Reading across the table below, note that MGA licence conditions attach the assurance to an approved Audit Service Provider rather than to a fixed testing cadence.

Jurisdiction	What the operator must produce	Timing
Great Britain (UKGC)	Independent security audit against the RTS section 4 controls drawn from ISO/IEC 27001:2022	First audit within 6 months of licence grant, annually after that
Malta (MGA)	Systems audit during onboarding and a system review of the live environment, both by an approved Audit Service Provider	System review after licence issuance; compliance audits when the Authority requires them
Ontario (AGCO)	Independent assessments by a qualified individual verifying the adequacy of gaming system security, with controls evidenced in a Control Activity Matrix	Regular assessments; control demonstration within six months of entering the regulated market
Michigan (MGCB)	Platform integrity and security assessment covering a vulnerability assessment, a penetration test of internal, external and wireless networks, and a policy review against ISO 27001	Within 90 days of commencing operations, annually after that
Curaçao (CGA)	CIS Controls IG1 baseline mapped to ISO/IEC 27001:2022, evidenced by annual self-assessment and, for online operators, an independent third-party security audit	IG1 implemented within 12 months of licence issuance or of publication of the guidelines

PCI DSS runs underneath all of it wherever card payments touch the estate. Requirement 11.4 sets the PCI DSS penetration testing obligations that casino operators meet in addition to their licence conditions: a documented methodology under 11.4.1 based on an industry-accepted approach such as NIST SP 800-115, internal testing under 11.4.2 and external testing under 11.4.3 at least once every 12 months and after any significant infrastructure or application change, remediation and retesting of exploitable findings under 11.4.4, and segmentation validation every 12 months for most entities and every six months for service providers. The future-dated v4 requirements stopped being optional on 31 March 2025.

Defining Penetration Test Scope Before Procurement

Scope is where most operator tests lose their value. A scope written around the marketing site and the login page produces a clean report and no assurance. Vulnerability management across an iGaming platform has to reach the components holding money, identity and game state.

• Player account platform and wallet, including deposit, withdrawal and bonus adjustment paths
• Payment interfaces and any cardholder data environment, with the segmentation boundary treated as an assertion to disprove rather than a given
• Remote gaming server integrations, game launch tokens and the aggregator APIs supplying content or results
• Sports data feed ingestion, including the authentication and integrity checks applied to the feed itself
• KYC document storage and the verification vendor integrations that read from it
• Back office and administrative consoles, covering bonus engines, player flagging tools and manual payout approval
• The identity and privilege model across domains, because privilege escalation and lateral movement decide how far one compromised endpoint travels
• Cloud configuration and the shared responsibility split with the hosting provider
• Third-party scripts executing on player-facing pages

Add a trigger for significant change on top of the annual date. A test dated eleven months ago says nothing about the payment rail integrated last week.

What an Incident Response Plan Must Contain

The incident response plan an iGaming licensee maintains gets read twice: once by an auditor, once at 03:00 by whoever is on call. Both readers want the same things in it.

• A named primary and a named deputy incident response manager, with defined roles for IT, security, compliance, legal and communications
• A severity classification that maps technical events to regulatory triggers, so whoever triages an alert knows which clock they have started
• A contact directory covering gaming regulators, the relevant data protection authority, the financial intelligence unit, law enforcement, insurers and the vendors running critical infrastructure
• A written definition of a reportable incident, with escalation criteria, reporting channels and pre-drafted notification templates
• Evidence preservation instructions, because containment done badly destroys the logs that later prove what did and did not leave the estate
• Post-incident review with owners and dates, feeding back into the control set
• Exercise records. Tabletop runs against gaming scenarios such as payout manipulation or feed tampering expose gaps that a document review never surfaces

GICNT-DS treats the plan as a certification artefact rather than a policy statement, and looks for the version history and the exercise records alongside it. The plan also has to reconcile with the operator’s data protection position, since one incident can engage licence conditions and GDPR and PIPEDA obligations at the same time.

Notification Clocks Run in Parallel, Not in Sequence

Breach notification to gambling regulators does not replace breach notification to a data protection authority, and neither one waits for a forensic conclusion. The clocks start on awareness.

Obligation	Trigger	Deadline
GDPR Article 33	Personal data breach likely to result in a risk to individuals	Without undue delay and, where feasible, not later than 72 hours after becoming aware; reasons required for any delay
GDPR Article 34	Personal data breach likely to result in a high risk to individuals	Communication to affected individuals without undue delay
LCCP licence condition 15.2.1, key event 16	Security breach adversely affecting the confidentiality of customer data, or preventing customers, staff or legitimate users from accessing accounts for longer than 12 hours	As soon as reasonably practicable and in any event within 5 working days, via eServices
LOK Article 5, as applied by the CGA framework	Incident compromising gaming integrity, affecting player funds or personal data, or affecting regulatory reporting, system availability or game fairness	Without undue delay and in any event within 24 hours
GICNT-DS	Confirmed breach affecting player data or gaming systems	72 hours

That 24 hour deadline comes from the Information Security Control Requirements the Curaçao Gaming Authority published in April 2026 under the Landsverordening op de Kansspelen (the National Ordinance on Games of Chance, or LOK) and put out for consultation until 18 June 2026. The document adopts Center for Internet Security Controls Implementation Group 1 as the enforceable baseline, maps each control to ISO/IEC 27001:2022, and states that compliance forms a mandatory condition of licensure. IG2 is the stated target for most licensees within 24 to 36 months. Much of the Curaçao regime has shifted since the LOK took effect in December 2024, so verify the current status of the framework before treating any date in it as settled.

Recurring Findings in Gambling Operator Infrastructure

The clearest recent illustration is not a gambling case at all. On 15 October 2025 the Information Commissioner’s Office fined Capita £14 million, split as £8 million against Capita plc and £6 million against Capita Pension Solutions Limited, over a March 2023 ransomware incident that exposed the personal data of 6.6 million people. Three findings from that decision transfer straight onto an operator estate.

The first is privilege. Capita ran no tiering model for administrative accounts, so an attacker who compromised one device escalated privileges and moved laterally across multiple domains. The second is response time: a high-priority alert fired within 10 minutes of the initial malicious download, and the device was isolated roughly 58 hours later against an internal target of one hour. The third is what happens to test results. Penetration tests had flagged the privileged access weakness on at least three occasions before the incident, and the findings stayed inside the business unit that commissioned them instead of reaching the rest of the network.

The patterns that recur in gambling infrastructure specifically:

• Back office and administrative interfaces reachable from the public internet, often on a forgotten subdomain
• Multi-factor authentication enforced for players and skipped for privileged staff and vendor accounts
• Service accounts between the wallet, the platform and the remote gaming server carrying far broader permissions than the integration needs
• Internal APIs that trust the caller because the call arrives behind a load balancer
• Bonus and promotion endpoints left live after the campaign ends
• Third-party scripts on player-facing pages that nobody in compliance has inventoried
• Network edge devices running end-of-life firmware

None of it is exotic. The same categories surface in the enforcement record, and the analysis of regulatory fines in iGaming rarely turns on a novel attack.

Remediation, Retesting and the GICNT-DS Evidence Pack

A report is not evidence. What an assessor reviews is the package around it.

• The methodology, referenced to a recognised approach such as NIST SP 800-115, PTES or the OWASP testing guide, with the scope boundary stated in writing
• Findings rated with CVSS, each supported by the evidence behind the rating
• A remediation plan naming an owner and a date per finding, not a severity bucket
• Retest evidence for every exploitable finding, since PCI DSS 11.4.4 and most auditors treat an unretested fix as an open finding
• Distribution beyond the commissioning team, with a record of who received the report
• Board or executive visibility of unremediated high-severity findings
• Retention of results and remediation records for at least 12 months under PCI DSS, and longer where licence conditions set a higher floor, such as the three year minimum Ontario applies to compliance records

GICNT-DS runs on an Annual Security Assessment cycle, so the evidence pack is reviewed as a whole rather than as a stack of certificates. An operator preparing for that review will find most of its gaps by working through the pre-launch compliance checklist before the assessor does.