⚡ Key takeaways
Regulatory compliance in iGaming infrastructure means engineering your hosting, data flows, and APIs so they satisfy regulator requirements — not just bolting on a compliance checklist after launch.
UKGC, MGA, and GLI-19 all now reference ISO/IEC 27001:2022 as a security baseline, but each adds its own data residency, audit-trail, and reporting requirements.
Multi-jurisdiction operators typically integrate 30–60 third-party APIs (KYC, payments, geolocation, RG monitoring) — each one is a potential audit finding if it isn't logged and versioned correctly.
Non-compliance risk is not theoretical: UKGC's 2026 review found recurring failures in deposit-limit enforcement, age-verification callbacks, and responsible-gambling trigger delivery.
If you run engineering for a betting, casino, or lottery platform, regulatory compliance in iGaming infrastructure is not a legal afterthought — it is an architecture decision. Where you host data, how you log RNG outcomes, and how fast your KYC and responsible-gambling APIs respond are all things a regulator will physically audit. Get the infrastructure wrong and no amount of legal paperwork fixes it after the fact.
At Gart Solutions, we've built and re-platformed infrastructure for sports betting, casino, and gaming operators running across the US, UK, Germany, and Australia — including state-by-state compliance across 100+ platform components for a sportsbook processing over 100 million bets a year. This guide walks through what regulators actually check, the frameworks that matter, and how to architect infrastructure that passes audit the first time. If you want a structured review of where your stack currently stands, our compliance audit service is built specifically around this gap.
What is regulatory compliance in iGaming infrastructure?
Regulatory compliance in iGaming infrastructure is the practice of designing hosting, data storage, networking, and application architecture so that they meet the technical standards set by gambling regulators — alongside general data-protection and payment-security law. It sits at the intersection of three normally separate disciplines:
Gaming-specific technical standards — rules written by gambling regulators and testing labs (UKGC, MGA, GLI) that govern RNG fairness, game-result logging, and responsible-gambling controls.
Cross-industry security and privacy law — ISO/IEC 27001, PCI DSS for payment data, and GDPR (or state-level equivalents) for personal data.
Jurisdictional infrastructure rules — where servers and regulatory data must physically sit, and which entities are allowed to access them.
The distinction matters because an operator can pass a generic SOC 2 or ISO 27001 audit and still fail a gambling regulator's technical review — regulators check things a standard security audit never touches, like RNG seed logging, deposit-limit enforcement latency, and whether regulatory data replicates in real time to an approved jurisdiction.
Why iGaming compliance is harder than standard IT compliance
Three things make gambling infrastructure compliance meaningfully harder than a typical SaaS compliance program:
1. Regulators audit APIs, not just documents
A modern MGA licensee typically integrates 30 to 60 third-party APIs — game content delivery, KYC identity verification, payment orchestration, affiliate tracking, anti-fraud screening, and responsible-gambling monitoring. Auditors increasingly request the raw API logs and response times for each of these, not a policy document describing them.
2. Multi-jurisdiction operators run multiple rulebooks simultaneously
An operator licensed in New Jersey, Ontario, and Malta is running three different data-residency regimes, three different RG-intervention rulesets, and three different audit cadences — on the same underlying codebase. Infrastructure has to isolate and route by jurisdiction without forking the whole platform.
3. The cost of getting it wrong is a suspended license, not a fine
Unlike most compliance regimes, gambling regulators can suspend or revoke an operating license. A failed technical audit doesn't just cost money — it can take the platform offline in that market entirely.
The core regulatory frameworks shaping iGaming infrastructure
UKGC Remote Gambling and Software Technical Standards (RTS)
The UK Gambling Commission's RTS is issued under the Gambling Act 2005 and covers everything from RNG fairness (RTS 7) to responsible product design (RTS 14) and in-play betting integrity (RTS 15). Its security requirements are explicitly based on Annex A of ISO/IEC 27001:2022, and updates that took effect in October 2025 tightened API audit requirements further — the Commission has flagged recurring failures specifically in deposit-limit enforcement, age-verification callbacks, and real-time responsible-gambling trigger delivery.
Malta Gaming Authority (MGA) Technical Infrastructure Guidelines
The MGA's guidelines on technical infrastructure require that regulatory data be hosted in Malta, the EEA, or another MGA-approved jurisdiction — with real-time replication back to Malta if the primary hosting sits elsewhere. After initial approval, licensees have 60 days to deploy the live environment and undergo a systems audit by a certified third-party auditor confirming the live setup matches what was approved on paper.
GLI-19: Standards for Interactive Gaming Systems
Published by Gaming Laboratories International, GLI-19 was the first worldwide technical framework for online gaming and is used as a reference standard by regulators who don't maintain their own detailed technical rulebook. Version 3.0 splits requirements into two tracks — supplier requirements, tested in a lab before launch, and operator requirements, including periodic on-site security testing after the system goes live. That split matters architecturally: your build needs to pass a point-in-time lab test and keep generating audit evidence continuously afterward.
US state-by-state frameworks
In the US, there is no single federal gambling regulator — each state (New Jersey's DGE, Pennsylvania's PGCB, Michigan's MGCB, and others) runs its own technical certification process, often requiring dedicated, geographically isolated environments per state. This is the exact challenge we solved for a national sportsbook client, adapting 100+ platform components to be state-specific compliant while migrating the core betting environment to AWS.
PCI DSS and GDPR: the two frameworks every operator carries regardless of license
Every iGaming platform accepting cards has to maintain PCI DSS compliance across its payment orchestration layer, and any platform touching EU or UK player data has to satisfy GDPR-equivalent data protection rules — encryption at rest and in transit, data minimization, and a documented lawful basis for profiling used in responsible-gambling risk scoring.
Infrastructure requirements regulators actually audit
Beyond the frameworks themselves, here is what shows up in a real technical audit:
Data residency and hosting location
Regulators want to know exactly where regulatory data physically lives, and whether replication to an approved jurisdiction happens in real time or on a delay. This needs to be an explicit architectural decision, not an artifact of wherever it was cheapest to spin up a region.
RNG certification and audit-trail logging
Every game outcome needs a logged, tamper-evident audit trail — seed values, RNG API calls, and result records — retained for the period your regulator specifies. Labs testing against GLI-19 or UKGC RTS 7 will request sample logs, not a description of your RNG methodology.
Geolocation and identity verification architecture
Geolocation checks have to run before a bet is placed, not after, and need to fail closed (block the bet) rather than fail open if the geolocation service times out. The same applies to KYC/AML identity checks feeding into onboarding and payment approval flows.
Responsible-gambling trigger delivery
This is precisely the area the UKGC flagged as a recurring failure point: deposit-limit enforcement and RG interventions need to fire in real time, with logged confirmation that the trigger reached the player-facing layer — not just that the backend event was generated.
Audit finding documentation
Regulators increasingly expect findings logged in a structured four-field format: the finding itself, the objective technical evidence (log entries, API responses, screen captures), the regulatory consequence, and the corrective action with a target date. Infrastructure that can't produce that evidence on demand turns a routine audit into a prolonged remediation cycle.
How Gart Solutions builds compliant iGaming infrastructure
Our approach to iGaming infrastructure compliance follows five phases, refined across sportsbook, casino, and betting-provider engagements:
Jurisdiction mapping — we map every market the platform serves or plans to serve against its specific data-residency, licensing, and reporting requirements before touching architecture.
Infrastructure-as-Code environment design — using declarative IaC (Terraform, Ansible), we template each jurisdiction's environment so new regions or states can be provisioned in days, not months, with regulatory guardrails baked in rather than bolted on.
Compliance-aware CI/CD — pipelines that gate deployments on region-specific policy checks, so a build cannot ship to a regulated environment without passing its jurisdiction's specific controls.
Continuous monitoring and audit-evidence collection — centralized logging tuned to capture exactly the evidence auditors ask for: RNG logs, RG trigger confirmations, API response times, and access logs with retention aligned to each regulator's requirement.
Audit readiness & re-certification support — we prepare documentation packages and run mock audits ahead of scheduled regulator reviews, so findings get caught internally first.
Case study: state-by-state compliance for a multi-state sportsbook
A sports betting platform operating across the US, UK, and Australia — processing more than 100 million bets a year — needed to adapt its architecture to be state-specific compliant across 100+ components while simultaneously migrating its core betting environment to AWS.
Gart embedded an AWS Cloud Architect, DevOps engineer, and SRE directly into the client's team. We configured infrastructure across OpenStack and AWS, defined every environment declaratively through Infrastructure as Code, and established dedicated environments to accommodate third-party certification regulators for each state. The result: new data-center onboarding dropped from weeks to two days — a 20x improvement — while overall application performance rose 30–40% and new features reached the market 60% faster. Full details are in our sportsbook infrastructure localization case study. We've applied the same pattern for other betting providers — see our DevOps transformation case study for a betting provider.
Multi-jurisdiction compliance: architecture patterns that scale
Operators licensed in more than one market need infrastructure that isolates jurisdiction-specific rules without maintaining separate codebases. The comparison below shows how requirements typically differ:
JurisdictionData residency ruleDistinct infrastructure requirementReference standardMalta (MGA)Malta, EEA, or MGA-approved jurisdiction; real-time replication to Malta if hosted elsewhereThird-party systems audit within 60 days of approvalMGA Technical Infrastructure GuidelinesUnited Kingdom (UKGC)No strict residency mandate; strong emphasis on security & RG-trigger evidenceISO/IEC 27001:2022-aligned controls; structured audit-finding logsRemote Gambling & Software Technical Standards (RTS)US states (NJ, PA, MI, etc.)Often state-specific data center or logical isolationPer-state third-party certification; geolocation enforced pre-betState gaming control board technical rulesEU/EEA generalPersonal data protection under GDPR-equivalent rulesDocumented lawful basis for RG risk-scoring profilingGDPRMulti-jurisdiction compliance: architecture patterns that scale
The engineering pattern that scales across all four: a shared platform core, jurisdiction-specific environments defined through containerized, Kubernetes-managed workloads, and policy-as-code guardrails that block a deployment from reaching a regulated environment unless it satisfies that jurisdiction's specific controls.
Compliance readiness checklist for iGaming infrastructure
Control areaWhat to implementPriorityData residencyRegulatory data hosted or replicated to an approved jurisdiction in real time🔴 CriticalRNG & audit trailTamper-evident logging of seeds, outcomes, and RNG API calls, retained per regulator🔴 CriticalGeolocation & KYCPre-bet geolocation checks that fail closed; KYC/AML gating on onboarding and payouts🔴 CriticalResponsible-gambling triggersReal-time deposit-limit and RG intervention delivery with logged confirmation🔴 CriticalSecurity baselineISO/IEC 27001:2022-aligned controls across the full stack🟠 HighPayment securityPCI DSS-compliant payment orchestration; secrets kept out of app config🟠 HighAudit evidenceStructured findings log (finding / evidence / consequence / corrective action)🟠 HighDisaster recoveryTested RTO/RPO per jurisdiction, immutable backups🟡 MediumCompliance readiness checklist for iGaming infrastructure
Common infrastructure compliance failures — and how to avoid them
RG triggers fire in the backend but never reach the player. Log confirmation at the player-facing layer, not just at event generation.
Geolocation fails open during an outage. Bets should be blocked, not allowed, if the geolocation service is unreachable.
Regulatory data replication runs on a batch delay instead of real time, which fails MGA's real-time replication requirement outright.
Audit evidence lives in someone's memory instead of a structured log, turning a routine review into weeks of manual reconstruction.
Emerging trend: continuous, API-level compliance monitoring
With 2026 audit cycles increasingly requiring API-level evidence rather than policy documents, the direction of travel is clear: compliance is moving from a periodic, document-based exercise to continuous, machine-verifiable monitoring. Operators building automated evidence pipelines — where every RG trigger, geolocation check, and RNG call generates its own audit trail by default — are the ones sailing through regulator reviews instead of scrambling before them.
Let's work together
See how Gart Solutions can help you overcome iGaming compliance and infrastructure challenges - from first audit to multi-jurisdiction scale. Contact us
You might also like: DevOps Practices in iGaming, Casinos, and Sports Betting Companies
Why ISO 27001 Is a Crucial Step for Successful Companies
Roman Burdiuzha
Co-founder & CTO, Gart Solutions · Cloud Architecture Expert
Roman has 15+ years of experience in DevOps and cloud architecture, with prior leadership roles at SoftServe and lifecell Ukraine. He co-founded Gart Solutions, where he leads cloud transformation and infrastructure modernization engagements across Europe and North America. In one recent client engagement, Gart reduced infrastructure waste by 38% through consolidating idle resources and introducing usage-aware automation. Read more on Startup Weekly.
Bare metal vs. public cloud for iGaming is one of the highest-stakes infrastructure decisions a betting or casino operator will make — it shapes latency, licensing eligibility, DDoS resilience, and the total cost of running the platform for years. There is no universal winner: the right answer depends on your game mix, your license jurisdictions, and how spiky your traffic really is. This guide breaks down the trade-offs with real numbers, so you can make the call with evidence instead of vendor slides. If you're mid-decision, Gart Solutions' infrastructure management team can also assess your current stack in a single audit.
Every iGaming operator eventually hits this fork in the road: stay on public cloud for its elasticity, move core systems to bare metal for performance and cost control, or run both. The decision affects everything downstream — from how fast your odds engine reacts to a last-minute goal, to whether your license application survives a data-residency review.
What "Bare Metal" and "Public Cloud" Actually Mean Here
Bare metal is a dedicated, single-tenant physical server: you get the full CPU, RAM, and disk, with no hypervisor sitting between your application and the hardware. Public cloud is virtualized, multi-tenant compute — AWS, Azure, and GCP being the obvious examples — where resources are provisioned on demand and billed by the hour or second. Public cloud's elasticity is only possible because hyperscalers have built planet-scale capacity that a single operator could never replicate independently; Synergy Research Group's tracking of global cloud infrastructure spend shows just how concentrated — and how large — that capacity has become.
For most SaaS companies this comparison is academic. For iGaming, it isn't. Betting and casino platforms combine three characteristics that almost no other vertical stacks together: sub-second latency requirements on real-money transactions, extreme and predictable-yet-unpredictable traffic spikes (a World Cup final, a jackpot promotion), and licensing regimes that sometimes dictate exactly where a server may physically sit.
Latency and Performance: Why Milliseconds Move Money
Bare metal wins the raw performance argument, and the gap is measurable rather than anecdotal. Disk I/O on bare metal with NVMe drives typically runs at 50–100 microseconds, while cloud VMs relying on network-attached storage see 200–500 microseconds — a 3–5x difference that shows up directly in odds-feed freshness, bet-slip confirmation time, and live-casino stream synchronization.
That gap matters most on the systems where it's felt: the odds engine, the bet-settlement pipeline, and the wallet ledger. A few hundred milliseconds of added latency on a checkout page is a UX annoyance; the same delay on an in-play odds update is a trading risk, because sharp bettors will exploit the lag before your system re-prices the market.
It matters far less on systems where a human is the bottleneck anyway — marketing pages, the CMS, back-office reporting, or async KYC document review. Running everything on bare metal "just in case" is usually over-engineering; running the trading-critical path on shared cloud compute is usually under-engineering.
Scalability: Handling World Cup- and Super Bowl-Scale Spikes
This is where public cloud earns its premium back. Cloud infrastructure can add compute in minutes during a tournament surge, while scaling bare metal means provisioning new hardware or migrating workloads — a process that takes hours to days, not minutes. Operators are already planning for total betting volume increases of 70–75% during major 2026 tournaments compared to the last comparable event, and that kind of surge is exactly the scenario cloud elasticity was built for.
We covered the operational side of this in detail in our breakdown of architecting sportsbook infrastructure for Super Bowl-scale traffic — the short version is that the spike itself is rarely the real risk. The real risk is what compounds around it:
Live, in-play markets that re-price thousands of times per second as odds move with the game
Payment and wallet bursts as deposits, cash-outs, and bonus triggers all fire in the same 90-minute window
Third-party dependency load on odds feeds, KYC providers, and payment gateways that weren't sized for your peak, not just your average — a failure mode we go deeper on in our piece on third-party single points of failure in iGaming
Support and fraud-review queues that spike in lockstep with transaction volume
This is also where DDoS activity concentrates: gaming is one of the most consistently targeted industries online, and attack volumes regularly exceed 100 Gbps during exactly these high-visibility windows — a topic we examine further in our comparison of World Cup DDoS attacks and game-launch outages.
Cost and TCO: When Bare Metal Saves Money — and When It Doesn't
The cost argument is more nuanced than "cloud is expensive." For steady-state, predictable workloads - the core betting engine, the primary database cluster, always-on game servers — bare metal is regularly reported to deliver 40–50% lower total cost of ownership than the equivalent public cloud footprint, because you're not paying a virtualization and elasticity premium on capacity you use 24/7 anyway.
Public cloud earns its cost back on variable, bursty workloads: the marketing microsite that gets one traffic wave a year, the analytics pipeline that runs nightly, or the extra web tier you spin up for a single tournament. The FinOps Foundation has documented how much of that promise gets left on the table in practice — roughly a quarter of cloud spend across the industry goes to idle or oversized resources that nobody right-sized after the initial migration, which is a governance failure, not an argument against cloud itself.
The trend worth watching is cloud repatriation: a growing share of enterprises are moving specific, steady-state workloads back to dedicated infrastructure once usage patterns stabilize enough to make the economics obvious, without abandoning cloud for the workloads that still need it.
FactorBare MetalPublic CloudHybrid (typical Gart setup)Latency (odds engine, wallet)Lowest — direct hardware accessHigher — virtualization + network storage overheadBare metal for the trading-critical pathTraffic-spike scalingSlow — hours to days to add capacityFast — auto-scale in minutesCloud burst tier absorbs event spikesSteady-state cost (TCO)Lowest for 24/7 workloadsHigher — pay for elasticity you may not useFixed cost on core, variable cost on burstData residency / licensingFull control of physical locationDepends on region availability of chosen providerCore data stays in-license, edge stays cloudDDoS mitigationProvider-dependent; leading providers now include Tbps-scale protectionNative, built into hyperscaler edge networkCloud-based scrubbing in front of both layersOperational overheadHigher — capacity planning, hardware lifecycleLower — provider manages hardwareRequires unified observability across bothBare metal, private or hybrid for igaming
Licensing and Data Residency: The Variable Most Comparisons Miss
Most generic "bare metal vs. cloud" articles never mention the one factor that can override every performance and cost argument for an iGaming operator: your license terms may dictate where the server physically sits. This is squarely within the remit of the UK Gambling Commission, which requires operators to maintain documented evidence of system availability, incident response, and data handling regardless of where infrastructure is hosted.
Curaçao's LOK licensing framework goes further and is explicitly prescriptive: licensed platforms must place at least one gaming server physically in Curaçao within a Tier-IV certified data center, synchronize player and transaction data on a defined schedule, and retain records for a mandated period before any deletion or alteration — requirements that are far easier to satisfy with a dedicated, auditable bare metal footprint than with a multi-region cloud deployment where "where the data lives" can be genuinely ambiguous. Cyprus's NBA framework similarly expects servers to sit in Cyprus or the wider EU. The UK Gambling Commission and Malta Gaming Authority don't mandate physical server location as explicitly, but both expect auditable proof of controls, which is exactly the documentation our compliance-by-design approach is built to produce.
This is precisely the situation we walked one operator through in our infrastructure localization case study for a sportsbook platform: the license terms, not the performance benchmarks, ended up dictating the final architecture.
DDoS and Security: Gaming Is Among the Most Attacked Sectors Online
Gaming has consistently ranked as one of the most heavily targeted industries for DDoS activity, with attack volumes in the space regularly exceeding 100 Gbps and record assaults reaching terabit scale. Attackers time these campaigns deliberately — the same major sporting events and game launches that drive your legitimate traffic spikes are also when attackers strike, because that's when an outage costs you the most and gets the most attention.
The practical implication for the bare-metal-vs-cloud decision: don't evaluate DDoS resilience as a property of the compute layer alone. Leading bare metal providers now include multi-terabit mitigation as standard, and public cloud platforms bake DDoS scrubbing into their edge networks by default — so in 2026, the deciding factor is less "which one has DDoS protection" and more "which architecture lets you fail over cleanly when an attack does get through" — usually a question of orchestration, not hosting model, which is why most resilient setups lean on Kubernetes-based failover across both layers.
Gart Solutions
The Right Infrastructure Mix — Not a One-Size-Fits-All Answer
Gart Solutions designs and manages bare metal, public cloud, and hybrid infrastructure for iGaming operators — matching each workload to the platform that actually fits it. We've helped gaming platforms cut infrastructure costs, pass licensing audits across multiple jurisdictions, and hold 99.99% uptime through World Cup- and Super Bowl-scale traffic.
Infrastructure Management
Cloud & Bare Metal Migration
SRE & Reliability
Compliance Audits
Kubernetes & Platform Engineering
8.2
avg. MTTR reduction (×)
10+
iGaming platforms delivered
50+
engineers across cloud & bare metal platforms
Get an infrastructure assessment →
The Hybrid Model: What Most Mature Operators Actually Run
In practice, few large iGaming platforms are purely one or the other. The pattern we see most often across iGaming cloud infrastructure builds is a deliberate split: bare metal (or a private cloud built on dedicated hardware) for the latency- and compliance-sensitive core — odds engine, wallet, primary database — and public cloud for everything elastic and geographically distributed: CDN edge, marketing sites, analytics, CI/CD runners, and burst capacity for tournament traffic.
This isn't a compromise position — it's the version of the decision that actually reflects how iGaming traffic and licensing work. The core rarely needs to scale 10x in an hour; the edge frequently does. The core has to sit where your license says it sits; the edge usually doesn't care. It also tracks a broader industry shift: the Cloud Native Computing Foundation's annual survey consistently finds that most organizations now run hybrid or multi-platform infrastructure rather than betting everything on one model — iGaming is simply an extreme, high-stakes version of a pattern that's already mainstream.
A Practical Decision Framework
Map your workloads to latency sensitivity first. Anything touching odds, bet settlement, or wallet balance goes on the shortest possible path to the hardware.
Check your license terms for physical-location requirements before comparing performance benchmarks — a compliance constraint overrides a cost or speed advantage every time.
Model your actual traffic variance, not your average load. A platform with 3x spikes needs a different split than one with 30x spikes.
Price the steady-state core on both platforms over a 3-year horizon, including the FinOps overhead of keeping cloud resources right-sized.
Design the failover path across both layers, not just within one — your DDoS and incident response plan should assume either layer can be the one under attack.
Teams that get this split right typically lean on an experienced partner rather than building the capability from scratch — our SRE team and migration specialists typically run this exact assessment as the first phase of an engagement.
You might also like
DevOps Practices in iGaming, Casinos, and Sports Betting Companies
What Real iGaming Infrastructure Postmortems Teach Us About Reliability
The EU Cloud Managed Services Gap: What Operators Are Missing
Monolithic vs. Microservices: Do You Really Need Microservices?
What Is DevSecOps — and Why iGaming Platforms Need It
Roman Burdiuzha
Co-founder & CTO, Gart Solutions · Cloud Architecture Expert
Roman has 15+ years of experience in DevOps and cloud architecture, with prior leadership roles at SoftServe and lifecell Ukraine. He co-founded Gart Solutions, where he leads cloud transformation and infrastructure modernization engagements across Europe and North America. In one recent client engagement, Gart reduced infrastructure waste by 38% through consolidating idle resources and introducing usage-aware automation. Read more on Startup Weekly.
If you run or host an online casino, sportsbook, or iGaming platform serving European players, two EU laws now define whether your infrastructure is legally defensible: the GDPR and the NIS2 Directive. They are not optional add-ons to a licensing checklist. GDPR and NIS2 compliance for casino hosting means your data centre, cloud provider, and application architecture all have to satisfy data protection law and cybersecurity risk-management law at the same time — and the two frameworks don't always pull in the same direction.
Most operators discover this the hard way: a GDPR data-retention policy that says "delete what you don't need" collides with a NIS2 logging requirement that says "keep evidence for forensics." This guide breaks down exactly where GDPR and NIS2 apply to casino hosting, who is actually in scope (the operator, the hosting provider, or both), what technical controls satisfy both regulators, and how Gart's compliance and infrastructure engineering practice helps gaming platforms get audit-ready without slowing down releases.
Why GDPR and NIS2 Both Govern Casino Hosting
Online casino and sportsbook platforms sit at the intersection of two regulatory concerns that European lawmakers deliberately separated into two directives: protecting the personal data of individuals (GDPR) and protecting the network and information systems that critical digital services depend on (NIS2). A casino platform processes both — KYC documents, payment details, gameplay and betting history, and responsible-gambling behavioural data — on infrastructure that, by its nature as always-on, real-money, high-availability digital infrastructure, looks a lot like the kind of service NIS2 was written to protect.
The practical result is that a casino hosting stack is rarely evaluated against just one framework. Regulators, payment processors, and licensing bodies increasingly expect operators to demonstrate both data protection compliance and cybersecurity risk management maturity, and to be able to prove it with evidence, not policy documents.
🎯 The key distinction operators missGDPR protects people — it applies the moment you process the personal data of anyone in the EU, regardless of your size or sector. NIS2 protects infrastructure — it applies based on your sector, size, and role in the digital supply chain. A small casino operator might not trigger NIS2 directly, but the cloud provider, data centre, or content delivery network hosting that casino almost certainly does, because cloud computing, data centre, and CDN services are named explicitly in NIS2 Annex I as "digital infrastructure."
Does NIS2 Apply to Online Casinos? Scope for Operators and Hosting Providers
The NIS2 Directive (EU) 2022/2555 does not list "gambling" or "gaming" as one of its named sectors in Annex I or Annex II. That leads a lot of operators to conclude, incorrectly, that NIS2 doesn't concern them. In practice, casino and iGaming businesses are pulled into scope through two separate paths.
Path 1: The casino operator as a digital service provider
If your platform functions as an online marketplace, offers social or community features, or otherwise resembles the "digital provider" categories in NIS2 Annex II, you may be classified as an important entity in your own right, subject to the size thresholds (roughly 50+ employees or €10M+ turnover for medium enterprises, 250+ employees or €50M+ turnover for large ones).
Path 2: Your hosting provider as critical digital infrastructure
This is the path that matters for almost every casino platform, regardless of size. NIS2 Annex I explicitly names cloud computing service providers, data centre service providers, and content delivery network providers as "digital infrastructure" — a highly critical sector subject to the strictest obligations. If your casino platform runs on a qualifying EU cloud or data centre provider, that provider is contractually and legally obligated to run NIS2-grade risk management, incident reporting, and supply-chain security — and those obligations flow down to you through the hosting agreement, whether or not your own company is separately in scope.
Several EU member states have already transposed NIS2 into national law with gambling-specific relevance. Italy's Legislative Decree No. 138/2024 (effective 18 October 2024) expanded cybersecurity obligations with a structured registration and compliance timeline. Malta — home to a large share of EU-licensed gambling operators — enacted Legal Notice 71 of 2025, replacing its previous NIS1 regime with self-registration through the Critical Infrastructure Protection Department and a dedicated national CSIRT. As DLA Piper's analysis of NIS2 and gambling puts it, gambling operators and their suppliers "must promptly assess their eligibility under the Directive" rather than assume the absence of an explicit sector listing means the absence of obligations.
📋 What this means in practiceBefore you can answer "are we NIS2 compliant," you need a scoping exercise across three questions:
(1) does our own platform meet an Annex II digital-provider definition,(2) is our hosting/cloud/CDN provider an Annex I essential entity, and (3) does our national gambling regulator layer additional cybersecurity conditions onto our licence, independent of NIS2 itself. Gart's infrastructure assessment is typically where this scoping starts.
GDPR Requirements for Casino and iGaming Platforms
Unlike NIS2, there's no ambiguity about GDPR's applicability: if your platform processes the personal data of anyone in the EU — players, affiliates, employees — GDPR applies, regardless of where your company or servers are based. For casino hosting specifically, four requirements come up repeatedly in regulatory guidance and enforcement actions.
A Data Protection Officer is effectively mandatory
Gambling operators typically carry out large-scale, systematic monitoring of individuals (fraud detection, responsible-gambling monitoring, behavioural profiling) and process special-category data for anti-money-laundering purposes. Both conditions independently trigger the GDPR Article 37 requirement to appoint a Data Protection Officer.
DPIAs for profiling and AML/CFT processing
Two categories of processing that are core to how casino platforms operate require a Data Protection Impact Assessment as a matter of course: systems that identify excessive or at-risk gambling behaviour, and systems that support anti-money-laundering and counter-terrorist-financing (AML/CFT) checks. Both involve profiling with potentially significant effects on the individual — precisely the trigger GDPR Article 35 is built around.
Consent, cookies, and marketing
GDPR Article 7 requires that consent for gambling marketing — emails, SMS, targeted advertising, retargeting pixels — be freely given, specific, informed, and as easy to withdraw as it was to give. Cookie consent banners that pre-tick marketing categories, or that make declining harder to find than accepting, are a recurring enforcement target across EU data protection authorities.
Data residency and international transfers
Many casino platforms run analytics, fraud-scoring, or customer-support tooling on US-based SaaS vendors. Since the invalidation of Privacy Shield (Schrems II), transfers of EU player data to the US require Standard Contractual Clauses plus a documented transfer impact assessment — not just a checkbox in a vendor's terms of service. This is one of the more concrete reasons operators are re-evaluating EU-based hosting and digital sovereignty rather than defaulting to US hyperscalers.
France's gambling regulator (ANJ) and data protection authority (CNIL) jointly published a 59-page GDPR compliance guide for licensed gambling operators in May 2026, addressing exactly this intersection of licensing obligations and data protection law — a strong signal that regulators are converging on sector-specific GDPR guidance rather than leaving operators to interpret general-purpose text.
Where GDPR and NIS2 Overlap — and Where They Pull Apart
The two frameworks reinforce each other on security fundamentals — encryption, access control, incident response — but they diverge sharply on data retention, and that divergence is exactly where casino hosting architectures get into trouble.
DimensionGDPR positionNIS2 positionData retentionStorage limitation principle — keep personal data only as long as necessary for the stated purposeEncourages retaining logs, audit trails, and forensic evidence long enough to detect and investigate incidentsPrimary objectiveProtect the rights and freedoms of individuals whose data is processedProtect the availability, integrity, and confidentiality of network and information systemsWho it applies toAny controller/processor handling EU personal data, regardless of sectorEntities in named sectors (Annex I/II) above size thresholds — including hosting/cloud/CDN providersBreach/incident reporting72 hours to the supervisory authority; affected individuals notified if high risk24-hour early warning, 72-hour detailed report, final report within one month to the national CSIRTGovernanceData Protection Officer oversight; accountability principle (Article 5(2))Management-body approval and oversight of cybersecurity measures; personal liability for gross negligenceWhere GDPR and NIS2 Overlap — and Where They Pull Apart
The practical fix is architectural, not political: separate personal data from security telemetry at the schema level. Audit logs, IDS/IPS alerts, and access logs used for NIS2 incident forensics should be pseudonymised and retained under a security-specific retention schedule, distinct from the player-data retention schedule your GDPR Record of Processing Activities defines. Trying to run one retention policy for both purposes is the single most common source of audit friction Gart sees in iGaming infrastructure reviews.
Choosing GDPR- and NIS2-Ready Hosting Infrastructure
Where you host a casino platform is no longer a pure cost-and-latency decision — it's a compliance decision with legal consequences. Three factors determine whether a hosting environment actually helps you meet GDPR and NIS2 obligations, or quietly works against you.
EU data residency and sub-processor transparency
Hosting player data on EU soil, with an EU-based cloud provider that publishes a complete, current sub-processor list, removes an entire category of GDPR international-transfer risk. Operators are increasingly comparing providers like Hetzner and IONOS specifically on data-sovereignty grounds — see Gart's Hetzner vs. IONOS comparison for how these EU-native providers differ on compliance-relevant criteria like data centre location, certification scope, and contractual DPAs.
Provider-level NIS2 posture
Ask any hosting or cloud provider directly: are you classified as an essential entity under NIS2 in your jurisdiction of establishment, and can you share your incident-reporting SLAs and supply-chain security attestations? A provider that can't answer this clearly is a supply-chain risk you're inheriting without visibility into it — and NIS2 explicitly makes supply-chain security a first-class obligation for entities in scope.
Architecture that supports both regimes at once
Network segmentation that isolates wallet, KYC, and payment services from public-facing game clients serves GDPR's data-minimization-by-design principle and NIS2's risk-management requirements simultaneously — a single architectural decision satisfying two regulators. Gart's DevOps practices for iGaming, casinos, and sports betting platforms cover this kind of compliance-aware Kubernetes and network design in more depth.
Technical Controls That Satisfy Both Regulations
Rather than building two parallel compliance programs, most of the technical work overlaps. The table below maps common infrastructure controls to the specific GDPR and NIS2 obligations they help satisfy.
ControlSatisfies GDPR by...Satisfies NIS2 by...Encryption at rest and in transitMeeting Article 32 "appropriate technical measures" for security of processingMeeting the baseline cryptography requirement under Article 21 risk-management measuresRole-based access control (RBAC)Enforcing data minimization and the "need to know" principle for staff access to player dataSupporting access-control policy requirements under Article 21(2)(i)Immutable audit loggingDemonstrating accountability (Article 5(2)) — who accessed what data, whenProviding the forensic evidence trail required for incident investigation and reportingNetwork segmentation / Kubernetes NetworkPolicyReducing the blast radius of a breach involving payment or KYC dataLimiting lateral movement — a named risk-management measure under Article 21Vulnerability management & patching cadencePreventing the kind of unpatched-system breach that triggers Article 33 notificationMeeting the explicit vulnerability-handling requirement in Article 21(2)(e)Vendor / sub-processor due diligenceSatisfying Article 28 processor obligations and transfer impact assessmentsMeeting the supply-chain security requirement in Article 21(2)(d)Automated compliance-as-code (OPA/Gatekeeper)Preventing configuration drift that could expose personal data by accidentProviding continuous evidence of risk-management measures for auditsTechnical Controls That Satisfy Both Regulations
Incident Response and Breach Notification Timelines
One of the most common operational failures Gart sees during compliance reviews isn't a missing control it's a missing playbook that tells the on-call engineer which clock is ticking. GDPR and NIS2 run on different notification timelines, to different authorities, and a casino platform breach can trigger both at once.
MilestoneGDPR (Article 33/34)NIS2 (Article 23)Who you notifyNational data protection supervisory authority; affected individuals if high riskNational CSIRT or competent cybersecurity authorityFirst notificationWithout undue delay, within 72 hours of becoming awareEarly warning within 24 hours of becoming awareDetailed reportIncluded in the initial 72-hour notification (nature, scope, likely consequences)Incident notification within 72 hours, updating the initial assessmentFinal reportNot separately mandated, but documentation must be maintained under Article 33(5)Final report within one month of the incident notificationTrigger thresholdA breach likely to result in a risk to individuals' rights and freedomsAn incident with a "significant impact" on service provisionIncident Response and Breach Notification Timelines
Building one incident response runbook that maps a single security event to both timelines — rather than maintaining separate GDPR and NIS2 procedures that different teams own — is the difference between a controlled disclosure and a missed deadline discovered during an audit.
Penalties, Enforcement, and Personal Liability
The financial exposure under both regimes is large enough to change board-level risk appetite, and neither framework limits itself to fining the company.
GDPR: up to €20 million or 4% of total worldwide annual turnover for the most serious infringements — unlawful processing, breach of data subject rights, or unauthorized international transfers — whichever amount is higher.
NIS2 essential entities (including in-scope cloud, data centre, and CDN providers): up to €10 million or 2% of global annual turnover, whichever is higher.
NIS2 important entities: up to €7 million or 1.4% of global annual turnover, whichever is higher, with fines doubling for a repeat offence within three years.
NIS2 also introduces something GDPR enforcement rarely reaches for in practice: personal liability. Article 32(6) empowers national authorities to hold management bodies accountable for gross negligence, including administrative fines against individual executives and, for essential entities, temporary bans from management functions. Combined with the ENISA guidance on NIS2 implementation, this makes cybersecurity governance a board-level obligation, not a delegated IT function — a shift that gambling operators, with their traditionally licensing-focused compliance functions, are still adjusting to.
⚖️ Licence risk compounds financial riskFor a casino platform, a GDPR or NIS2 enforcement action rarely stays contained to the fine itself. Regulators such as the Malta Gaming Authority can treat a data protection or cybersecurity failure as evidence of inadequate operational controls under the gaming licence itself — turning a compliance fine into a licence review.
Compliance Checklist for Casino Hosting
AreaActionPriorityScopingDetermine whether your platform and/or your hosting provider fall under NIS2 Annex I or II🔴 CriticalGDPR governanceAppoint a DPO and complete DPIAs for problem-gambling detection and AML/CFT profiling🔴 CriticalHostingConfirm EU data residency and request your provider's NIS2 classification and sub-processor list🔴 CriticalIncident responseBuild one runbook covering both the GDPR 72-hour and NIS2 24/72-hour/1-month timelines🔴 CriticalArchitectureSegment wallet, KYC, and payment services from public-facing game clients🟠 HighData lifecycleSeparate personal-data retention schedules from security-log retention schedules🟠 HighConsent managementAudit cookie banners and marketing consent flows for pre-ticked boxes or dark patterns🟠 HighSupply chainExtend NIS2 supply-chain security assessments to payment, KYC, and analytics vendors🟡 MediumGovernanceBrief the management body on NIS2 personal-liability exposure and require sign-off on the risk register🟡 MediumCompliance Checklist for Casino Hosting
Case Study: Regulatory-Ready Infrastructure for a Sportsbook Platform
One of Gart's iGaming engagements involved migrating a US-facing sportsbook to AWS while meeting state-by-state data residency rules — a compliance problem with the same shape as GDPR/NIS2 data-residency requirements in the EU. The team designed a multi-region architecture with jurisdiction-specific VPCs and data controls enforced through Service Control Policies, paired with an Infrastructure-as-Code approach covering 100% of production resources, so every environment change was auditable by design rather than by afterthought.
Results: deployment time dropped from 4 hours to 22 minutes, feature delivery sped up by 60%, and the platform improved performance by 30–40% — all while making regulatory infrastructure reviews a matter of pulling Terraform state and Git history, not reconstructing what changed from memory.
Read the full case study: AWS Migration & Infrastructure Localization for Sportsbook Platform
Compliance-Ready Infrastructure for iGaming
Need casino hosting that passes a GDPR and NIS2 audit — not just a licensing check?
Gart designs and operates infrastructure for casino, sportsbook, and iGaming platforms with data protection and cybersecurity risk management built in from the architecture up — EU data residency, segmented environments, immutable audit trails, and incident-response runbooks that satisfy both regulators.
NIS2 Compliance & Gap Assessment
GDPR-Ready Infrastructure Design
EU Data Residency & Sovereign Cloud
DevSecOps & Compliance-as-Code
IT Infrastructure Assessment
Incident Response & Monitoring
iGaming & Casino DevOps
Talk to a compliance specialist
Explore our NIS2 compliance services →
You might also like
Strengthen Your Information Security with NIS2 Compliance Solutions
Digital Sovereignty of Europe: Choosing the EU Cloud Provider
DevOps Practices in iGaming, Casinos, and Sports Betting Companies
What Is DevSecOps? Integrating Security into Your DevOps Pipeline
Free NIS2 Compliance Checklist (PDF Guide)
Roman Burdiuzha
Co-founder & CTO, Gart Solutions · Cloud Architecture Expert
Roman has 15+ years of experience in DevOps and cloud architecture, with prior leadership roles at SoftServe and lifecell Ukraine. He co-founded Gart Solutions, where he leads cloud transformation and infrastructure modernization engagements across Europe and North America. In one recent client engagement, Gart reduced infrastructure waste by 38% through consolidating idle resources and introducing usage-aware automation. Read more on Startup Weekly.
