Disaster recovery planning for European cloud infrastructure: RTO, RPO, and compliance requirements

For most of the last decade, disaster recovery sat in the “nice to have” column of infrastructure budgets. Regulators have ended that era. Finance firms answering to DORA, healthcare operators under NIS2, and energy providers governed by sector-specific frameworks now face legally defined recovery thresholds. Miss them and the conversation shifts from incident report to enforcement action.

This post maps the compliance landscape, explains what RTO and RPO actually require at the infrastructure level, and explains why the geography of your cloud provider is not a secondary consideration.

What RTO and RPO mean when regulators define them

Recovery Time Objective (RTO) is the maximum acceptable duration between a service disruption and full restoration. Recovery Point Objective (RPO) is the maximum acceptable data loss measured in time: how far back your last clean restore point can be. Both are engineering targets, but under DORA and NIS2 they become contractual and regulatory commitments.

DORA, which applies to financial entities and their critical ICT third-party providers across the EU from January 2025, requires firms to set explicit RTO and RPO targets for each critical function, test them regularly, and demonstrate that their cloud infrastructure can actually meet them. The European Banking Authority’s guidelines make clear that “best efforts” is not a documented target.

A recovery objective that exists only in a Word document is not a recovery objective. It is a liability.

NIS2 extends similar logic across essential and important entities in sectors including energy, transport, water, healthcare, and digital infrastructure. Member states are transposing NIS2 into national law with varying timelines, but the core obligation is consistent: entities must implement technical and organisational measures to handle incidents, and those measures must include tested backup and recovery procedures with defined objectives.

Sector-specific obligations worth knowing

Financial services and DORA

DORA’s business continuity requirements go beyond backup schedules. Article 12 requires financial entities to have ICT business continuity policies that cover RTO and RPO for critical or important functions, with recovery scenarios tested at least annually. Critically, the regulation requires that recovery capabilities be validated against realistic disruption scenarios, not just planned maintenance windows.

For cloud-hosted workloads, this means your provider’s architecture must support failover within your defined RTO. If your RTO for a core banking function is four hours, a cloud provider that replicates data asynchronously to a single secondary site in a different continent cannot reliably meet that target, and the audit trail will show it.

Healthcare under NIS2 and national frameworks

Healthcare operators face a dual obligation: NIS2’s baseline requirements plus sector-specific rules that vary by member state. Germany’s BSI framework, France’s ANSSI guidelines, and the Dutch NEN 7510 standard each layer additional specificity onto the NIS2 baseline. The common thread is that patient data systems must have tested recovery paths, and backup data must remain within jurisdictions where data protection law applies.

Energy and critical infrastructure

Energy operators classified as essential entities under NIS2 face some of the strictest incident reporting timelines in the regulation: initial notification within 24 hours of becoming aware of a significant incident, with full reporting following. That clock makes recovery speed a compliance input, not just an operational preference. Operational technology environments in energy present additional complexity, since OT systems often cannot tolerate the latency or network paths that IT workloads accept.

Why cloud geography shapes your compliance posture

Schrems II removed the legal basis for transferring personal data to the United States under the Privacy Shield framework. Its successor, the EU-US Data Privacy Framework, faces ongoing legal challenges, and the underlying tension, that US surveillance law can compel access to data held by US-owned entities regardless of where the servers sit, has not been resolved by any framework agreement.

For disaster recovery specifically, this creates a concrete problem. If your primary workload runs in a European region of a US hyperscaler, and your disaster recovery replica also runs in that provider’s infrastructure, both copies sit within the legal reach of US law. A recovery event that forces failover to the DR site does not change that exposure; it may concentrate it.

European cloud infrastructure owned and operated by a European legal entity, subject exclusively to European law, closes that gap. Backup data, replication traffic, and failover environments all remain within a jurisdiction where GDPR applies and where no foreign government has a statutory route to compel access.

Designing a compliant cloud disaster recovery architecture

Replication topology

Synchronous replication between sites eliminates RPO at the cost of latency; it suits databases and transaction logs where any data loss is unacceptable. Asynchronous replication tolerates a small RPO window (typically seconds to minutes) in exchange for lower latency on writes. Most regulated workloads use a tiered approach: synchronous for the most critical data, asynchronous for secondary systems, with cold backup for archival data.

Multi-site European infrastructure matters here because replication latency is a function of physical distance and network path. Two sites within the same European region can sustain synchronous replication for most database workloads. Two sites separated by an ocean cannot.

Testing cadence and evidence

DORA requires annual testing at minimum, with more frequent testing for critical functions. NIS2 does not specify a cadence but requires that measures be “regularly tested and reviewed.” Both frameworks require documented evidence: test plans, results, identified gaps, and remediation actions. A recovery test that leaves no audit trail has limited regulatory value.

Automated failover testing, where workloads are periodically failed over to the DR site in a controlled window and then failed back, produces the most credible evidence because it tests the actual infrastructure path rather than a simulated one. Runbook-only tests tell you whether the documentation is current; they do not tell you whether the infrastructure will behave as documented under load.

RTO targets by workload tier

• Tier 1 (critical, regulated): RTO under 4 hours, RPO under 15 minutes. Requires synchronous or near-synchronous replication, automated failover, and pre-warmed standby capacity.
• Tier 2 (important, business-critical): RTO 4 to 24 hours, RPO under 1 hour. Asynchronous replication with scripted failover procedures.
• Tier 3 (standard): RTO 24 to 72 hours, RPO under 24 hours. Scheduled backup with restore-from-backup recovery path.

Mapping workloads to tiers before designing the architecture prevents over-engineering low-criticality systems and, more importantly, prevents under-engineering the ones that regulators will ask about first.

Compliance is the floor, not the ceiling

Meeting DORA’s RTO and RPO requirements, satisfying NIS2’s incident response obligations, and keeping backup data within European legal jurisdiction are baseline requirements for regulated sectors. They are also, when the architecture is designed properly, the conditions under which a recovery event becomes a managed operational response rather than a crisis.

The infrastructure choices that satisfy regulators, multi-site replication within Europe, tested failover paths, documented recovery objectives, and legally unambiguous data residency, are the same choices that make recovery reliable. That alignment is not coincidental. European cloud infrastructure built for sovereignty is built for exactly this kind of accountability.