Two industries. One question. Most can't answer it.
iGaming regulators reach operational resilience through consumer protection. Crypto regulators reach it through financial stability. The mechanisms differ, but by 2026 they're converging on one expectation: manage your concentration risk.
Late 2025 into early 2026, the internet's foundations buckled in public. AWS, then Cloudflare, then Microsoft 365 each went dark for hours. No attacks. No breaches. Just routine config and routing faults inside the handful of providers that quietly run the digital economy, taking dependent businesses down within minutes through no fault of their own.
Here's the part that should worry every iGaming operator and crypto-asset service provider: your regulator holds you accountable for that downtime, whoever's infrastructure actually failed.
The convergence nobody planned
Gaming and crypto are regulated by different authorities, under different laws, born of different concerns. Modern gaming regulation prioritises consumer protection and fairness: the UKGC, Malta's MGA. Crypto regulation, by contrast, grew out of financial stability and investor protection: MiCA paired with DORA, Dubai's VARA.
No shared lawmaker. No shared tradition. The mechanisms differ too. DORA is prescriptive, the UK's RTS principles-based, NIS2 risk-management, VARA governance-led. The convergence is thematic, not literal. But it's real: by 2026 a UK gaming operator, a Malta CASP and a Dubai VASP are all being pushed toward the same three outcomes:
Know your critical providers. Eliminate single points of failure. Prove, don't assert, that you survive losing one.
When two unrelated regulatory worlds land on identical controls independently, that's not a quirk to manage jurisdiction by jurisdiction. That's the direction of travel. And for the growing number of groups running gaming and crypto arms off shared infrastructure and the same payment rails, it isn't a comparison. It's one compounding reality.
First, what the term means
Operational resilience isn't backup-and-restore, and it isn't cybersecurity. It's the ability to keep delivering your most important services through disruption, not just recover them afterwards.
The regulators define it almost identically. DORA calls it the ability to withstand, respond to, recover from and learn from ICT disruptions. The FCA frames it as an outcome: identify the services that would cause intolerable harm if they failed, set an impact tolerance for how much disruption each can absorb, and prove you can stay within it under severe but plausible scenarios.
Strip out the legalese and it's four things: stay within acceptable limits during the incident, keep critical services running, contain the impact, and recover fast, with minimal disruption to customers and operations. The focus is the handful of services that can't be allowed to fail, not defending every system equally. The shift is from "can we recover?" to "can we keep operating, and within what limits?" That's what all four regimes below are reaching for.
"But we're not even on AWS"
Here's why your hosting choice doesn't get you off the hook. If resilience is about your most important services surviving disruption, the regulator doesn't care how you host them.
The obligation is identical whether your critical provider is a hyperscaler, a specialist host, a custody provider or a payment processor. A specialist host serving a whole market can be a more concentrated point of failure than the public cloud, and it may depend on a small set of upstream providers you've never mapped. "We don't use AWS" too often means "our provider does, and we never checked." Regulators have a name for that blind spot now: fourth-party risk.
The question is no longer are you on the cloud? It's can you name your critical dependencies, and prove you keep running when one fails?
How the demand reaches you
Four regimes, same destination, but the evidence each expects differs.
UK gaming (RTS). Principles-based: business continuity, disaster recovery, redundancy, tested change management, supplier oversight, penetration testing, with material failures escalated to the Commission. Audited annually against ISO 27001, now with a control specifically for cloud services. The RTS is updated periodically as policy evolves, and enforcement tests whether controls work in production, not on paper.
EU horizontal cybersecurity (NIS2). Not a gaming regulation: a general cybersecurity directive that catches covered sectors above size thresholds. In force in Malta since 23 January 2026. Many larger and more ICT-dependent gaming operators and suppliers are likely in scope as essential or important entities by virtue of size and digital-service criticality, but each must assess its own position. Those captured face governance and supply-chain duties, personal management accountability, and fast incident reporting to CSIRT-Malta. First audits are expected from H2 2027.
EU crypto (MiCA + DORA). The sharpest case. DORA has been fully applicable to in-scope financial entities since January 2025; CASPs are bound directly, unlike gaming operators, who are caught only indirectly through their payment providers. In Malta it shows at the application stage: the MFSA's process increasingly expects MiCA applicants to evidence operational resilience and ICT third-party risk assessment as part of authorisation. Resilience isn't bolted on after licensing; it's part of getting licensed. The MiCA CASP transition (a separate clock) closes 30 June 2026, and thin submissions are being rejected.
Non-EU crypto (VARA). Dubai got there by a separate road. Its technology rules push redundancy and the avoidance of single points of failure, separate backups, and resilience testing, and its custody and key-management provisions bear down on the concentration of control over wallet infrastructure. A Gulf regime and an EU regime, no shared lawmaker, leaning the same way.
Why crypto raises the stakes
Both sectors share one trap: running production and recovery on the same provider. When it goes, both go, and a firm relying on a single host's own backup product is as exposed as one running production and DR in the same AWS region.
In gaming, that's downtime: lost revenue, an escalation, reputational damage. In crypto, where custody and keys are involved, a single point of failure can mean losing client assets, not just access. That's why VARA's custody rules press so hard on the concentration of control over wallet infrastructure. Concentration risk in crypto isn't just an availability problem. It can be a solvency one.
What good looks like
Four things, none delivered by a contract alone, and all expected by sportsbooks and exchanges alike:
Map dependencies, including fourth parties. You can't manage concentration you can't see.
Build real redundancy. Multi-region, cross-provider where it matters, never production and recovery on one provider.
Test and evidence continuity. Under MiCA and VARA, supervisors increasingly expect to see this at authorisation, not just afterwards.
Assure continuously. The annual supplier review is stale the day it's signed.
The plan you've tested, not the one you've filed
Most firms have a business continuity document. Far fewer have a resilience playbook they've actually run, a tested sequence for the moment a critical provider goes dark: who decides to fail over, what keeps running on what, and which regulator hears what, by when. A document satisfies an auditor on a calm day. A tested playbook is what holds up at 3am when the provider isn't answering and your reporting clock has already started.
Most resilience planners now assume the next major outage is a matter of time, not chance. When it comes, no supervisor asks whose infrastructure failed. They ask what you'd already put in place, and "we were working on it" has never once worked as an answer.
So settle it now, while it's still a planning exercise and not an incident report:
If your most critical provider failed tomorrow, would you be opening a playbook you trust, or writing one live?
Endida helps iGaming operators and crypto-asset service providers benchmark their resilience and regulatory posture, identify gaps, and map a prioritised route to assurance. Our complimentary Regulatory Benchmark Assessment gives you an independent expert view of where you stand, and what to do next. A good first step if you're not sure your playbook would hold the moment a critical provider fails. Request yours at https://endida.com/#contact
Photo by Igor Omilaev on Unsplash