Every cloud fails eventually. The question regulators are now asking is not whether your infrastructure can avoid failure, but whether you designed it to survive one. DORA came into application on 17 January 2025. NIS2 repealed its predecessor in October 2024. Between them, these two frameworks make cloud resilience architecture a legal obligation for financial entities, healthcare operators, energy providers, and critical infrastructure across Europe. The engineering decisions your team makes about fault-domain isolation and recovery architecture are now board-level compliance items.

This post covers the structural principles behind fault-tolerant cloud design, what the regulations actually require at a technical level, and where regulated European enterprises consistently get it wrong.

What the regulations actually demand

DORA Article 11 requires every financial entity to establish, maintain, and periodically test an ICT business continuity policy. Article 12 builds on that with dedicated recovery plans specifying how operations resume after an ICT disruption. Critically, each entity must define its own recovery time and recovery point objectives, calibrated to a Business Impact Analysis. DORA does not prescribe a universal numeric threshold: the obligation is that targets exist, are documented, are proportionate to function criticality, and are tested at least annually, including switchover scenarios between primary infrastructure and redundant capacity.

NIS2 Article 21(2)(c) requires covered entities to implement measures covering business continuity, backup management, disaster recovery, and crisis management. That single sentence expands into more than 20 specific technical requirements under Commission Implementing Regulation 2024/2690. ENISA published 170 pages of operational guidance in June 2025 translating those requirements into evidence-backed practices. One of the clearest mandates: backups of critical data must be kept physically and geographically separate from production systems, so a disaster affecting the primary site does not simultaneously destroy recovery capability.

Resilience is not a configuration option. It is an architectural property, and it has to be designed in before the first workload goes live, not retrofitted after the first incident report lands on a regulator’s desk.

Fault-domain isolation: the foundation of regulated cloud infrastructure design

The single most common mistake in European cloud high availability design is conflating redundancy with resilience. Running two instances of the same service in the same availability zone, on the same underlying physical cluster, with the same network path to the internet, is redundancy on paper and a single point of failure in practice. Fault-domain isolation means separating workloads so that a failure in one domain cannot propagate into another.

There are three layers where this separation matters in regulated environments.

Physical fault domains

Compute, storage, and networking should be distributed across physically distinct facilities with independent power, cooling, and upstream connectivity. For DORA-scoped entities, this means primary and redundant ICT infrastructure cannot share a single physical building or a single power feed. For NIS2-scoped entities, geographically separated backups are an explicit requirement, not a best practice. This is where carrier-neutral facilities with independent upstream paths matter operationally, not just on a compliance checklist.

We operate four production datacenters: MAD1 in Madrid, MUC1 in Munich, HEL1 in Helsinki, and AMS1 in Amsterdam. Each is carrier-neutral and connected to 44 points of presence across Europe and the Middle East. A customer running regulated workloads across MAD1 and MUC1 gets genuine geographic fault separation with direct peering to AWS, Azure, and GCP at both sites, so hybrid and multi-cloud recovery paths do not introduce a new single point of failure at the interconnect layer.

Network fault domains

Blast radius containment at the network layer requires more than VLANs. Regulated workloads need network segmentation that enforces policy boundaries between environments: production, DR, backup, and management planes should not share routing domains. East-west traffic between fault domains should traverse controlled chokepoints, not rely on implicit trust within a shared network fabric. In practice this means designing your network topology before you deploy, not adding security groups reactively after an audit finding.

Data fault domains

Recovery point objectives are only meaningful if your backup architecture enforces them. Synchronous replication across fault domains gives you near-zero RPO but adds latency to every write. Asynchronous replication with a defined lag gives you predictable RPO at lower cost but requires honest documentation of what data loss is acceptable for each function class. The BIA that DORA requires is not a paperwork exercise: it is the document that justifies which functions get synchronous replication and which tolerate a 15-minute lag.

Testing is the obligation that most teams underestimate

Both DORA and NIS2 treat untested continuity plans as non-compliant continuity plans. DORA Article 11 explicitly requires switchover scenarios between primary and redundant infrastructure as part of annual testing. ENISA’s June 2025 handbook for cyber stress tests provides methodology for large-scale incident simulations, including cross-border scenarios, as the expected standard for NIS2-covered entities.

In practice, this means your runbooks need to be executable under pressure by someone who did not write them. Recovery procedures that live only in the head of the engineer who designed the system are not procedures: they are tribal knowledge with an expiry date. The test cadence required by DORA also means your infrastructure has to support non-destructive failover testing without taking production offline, which has direct implications for how you architect your DR environment from day one.

The CTPP designation and what it means for cloud dependency

In November 2025, 19 providers were designated as Critical ICT Third-Party Providers under DORA, the first official list under the regulation. All major hyperscalers had published DORA addendums before that designation. What designation means in practice is that these providers now face coordinated examination by Joint Examination Teams, and their business continuity obligations, including RTO and RPO targets for services they provide, are subject to direct EU-level oversight.

For financial entities, this is relevant in two directions. It raises the floor for what hyperscalers must document and demonstrate. But it also means that concentration risk, running critical functions exclusively on a single designated CTPP, is now a documented risk factor that supervisors will examine. Distributing workloads across a European sovereign infrastructure provider alongside hyperscaler deployments is not just a sovereignty argument: it is a concentration-risk mitigation that belongs in your DORA risk framework.

What a resilient architecture actually looks like

There is no single blueprint, because RTO and RPO targets are function-specific and BIA-driven. But the structural properties of a compliant, fault-tolerant cloud design are consistent across regulated sectors:

  • Geographic separation between primary and recovery sites, with independent physical infrastructure at each.
  • Independent upstream connectivity at each site, carrier-neutral, so a single ISP failure does not isolate both environments.
  • Network segmentation enforced at the routing layer, not just the firewall layer, with separate management planes for production and DR.
  • Tiered replication strategy matching synchronous or asynchronous replication to the RPO defined for each function class in the BIA.
  • Automated failover with manual override: automation reduces recovery time, but regulators expect human decision points in the loop for critical functions.
  • Tested runbooks with documented evidence of annual switchover exercises, stored separately from the systems they describe.
  • Backup isolation enforced at the infrastructure level, not just policy, so a ransomware event affecting production cannot reach backup storage.

The architecture that satisfies DORA Article 11, NIS2 Article 21, and a competent security team’s threat model is not exotic. It is disciplined engineering applied consistently, across every layer, before the first workload goes live. The cost of retrofitting it after an incident, or after a supervisory review, is reliably higher than building it correctly the first time.