Reevaluating backup and disaster recovery for regulated EU organizations: Reconciling DORA, NIS2, and data sovereignty

In many markets, but especially regulated EU markets, backup disaster recovery is evolving from traditionally just an IT function to a compliance obligation with real financial and legal weight.  

The introduction of DORA and NIS2 turns ‘we’ve got a plan’ into ‘prove it works’ while data sovereignty adds a third pressure most guidance ignores entirely, more on that below.  

Ultimately, this article gives CTOs, CISOs and heads of IT a practical framework for reevaluating their current stance against these regulatory scopes, with clear checklists and next step at the end. 

TL; DR, we’ve included checklists and an FAQ section towards the end of the article. Let’s dive in. 

What you’ll find in this article: 

• Who this actually applies to  

• Key definitions in disaster recovery planning 

• What’s actually changed under DORA and NIS2 

• The real gap: compliant on paper vs resilient in practice 

• The sovereignty-resilience trade-off no one talks about 

• Vendor and third-party risk: the overlooked compliance dimension 

• Reevaluating your DR posture 

• FAQs 

Who (or which sectors) this actually applies to 

DORA (Digital Operational Resilience Act) applies to financial entities operating in the EU and their critical ICT providers. Whereas, NIS2 applies to essential and important entities across eighteen sectors, including energy, health, transport and digital infrastructure.  

Many regulated organisations fall under both regimes at once, particularly where their services or supply chains cross sectors. 

This overlap trips up more organisations than you’d expect.  

Does DORA apply to non-financial companies? 

Not directly. DORA is written for financial entities and the ICT providers that serve them.  

A payments firm is a financial entity under DORA, but it may also count as a digital infrastructure or managed service provider under NIS2.  

Per the scope of Article 2, 2. (c), a hospital group is required to comply with NIS2’s directive for the health sector. Yet, if it processes payments through a regulated financial intermediary, aspects of DORA’s ICT risk requirements can still influence it at a contract level, even though the hospital itself isn’t a financial entity. 

DORA’s scope 

DORA is enforced jointly by the European Supervisory Authorities, EBA, ESMA and EIOPA and it covers around twenty categories of financial entity, some of which include: 

• Credit and payment institutions 

• Investment firms and asset managers 

• Insurance and reinsurance corporations 

• Crypto-asset service providers 

• Trading venues and central counterparties 

• Critical ICT third-party providers serving any of the above 

Are small financial firms exempt from DORA? 

No. Smaller entities get a simplified framework, not an exemption. For example, a small investment firm won’t face the same obligations as a systemically important bank, the core requirements around ICT risk management and incident reporting still apply. 

In essence, the underlying duty remains the same for all: manage ICT risk, maintain a business continuity and disaster recovery plan, and report major incidents within set timeframes. 

NIS2’s scope 

NIS2 sorts organisations into two categories: essential entities and important entities. The split depends mainly on sector and size rather than a single fixed list. 

Cloud providers, data centre operators and managed IT service firms fall under NIS2’s digital infrastructure category. If your organisation depends on one of these providers, their compliance posture becomes part of your own risk picture, not just theirs.  

What’s the difference between an essential and an important entity under NIS2? 

Essential entities face direct supervision, including proactive audits. Important entities are supervised reactively, usually only after an incident or complaint. Both face similar core obligations around risk management and business continuity, but the level of regulatory oversight differs. 

Why this matters before you go further 

Scoping is where many disaster recovery reviews stall. Teams often assume they’re covered by whichever regulation is most visible in their sector and miss the other entirely. A quick way to check: 

• You’re likely in scope for DORA if you’re a financial entity, or you provide critical ICT services to one 

• You’re likely in scope for NIS2 if you operate in one of the eighteen listed sectors, meet the relevant size thresholds, and rely on network and information systems to deliver your services 

• You may be in scope for both if you’re a financial entity that also qualifies as digital infrastructure or a managed service provider, or if your supply chain crosses sectors 

National transposition adds a further variable. National authorities enforce this locally, for example BaFin in Germany, the CSSF in Luxembourg, the ACPR in France, and the DNB in the Netherlands. As NIS2 is a directive, each member state writes its own legislation. The Netherlands’ Cyberbeveiligingswet is one example of its interpretation in the case of cybersecurity.  

Exact thresholds, deadlines and enforcement mechanics can vary by country even though the underlying obligations are harmonised at EU level.  

DORA works differently: it’s a regulation, so it applies directly and uniformly across all member states, with no national transposition step. That’s one reason financial entities often find DORA’s requirements more concrete to work against than NIS2’s. 

Which regulation should I check first? 
Start with your sector. To reiterate, financial entities should check DORA first, then assess whether any part of the business also falls under NIS2. Organisations outside finance should check NIS2’s sector list and size thresholds first. 

The long and short of it is, compliance increasingly influences almost every decision that follows in your backup and disaster recovery strategy, from testing to where recovery data can legally be held.  

If you’re unsure which regime applies, resolving that question early matters. Be sure to synch up with your legal or compliance team. 

Before diving into the exact implications of each regulatory framework, let’s quickly recap some key terms you need to know when disaster recovery planning. 

Key definitions in disaster recovery planning 

If you’re seasoned in DR planning, you can probably skip this section. But, for those that aren’t, detailed below are the key concepts and terminology you need to get familiar with. 

There are four key terms sit at the centre of any disaster recovery plan:  

Recovery time objective (RTO) 

RTO is the maximum acceptable downtime before an outage becomes damaging. 

Recovery point objective (RPO) 

RPO is the maximum data loss a business can tolerate, measured in time rather than volume. 

Business impact analysis (BIA)  

BIA is the process of identifying which systems matter most and what happens if they fail. 

Immutability 

Immutability means backup data that cannot be changed or deleted by anyone, including an administrator, which is what keeps a ransomware attack from reaching your last clean copy. 

Note: Immutability protects data from being altered, but it doesn’t answer who can reach the backup environment in the first place. Access governance, controlling and logging who holds credentials to backup and recovery systems, is a separate control, and one auditors increasingly check alongside immutability rather than instead of it. 

What does this look like in a real disaster recovery example?  

A core banking system with an RPO of 15 minutes needs backups running at least every 15 minutes. Since any longer gap risks losing more data than the business can absorb.  

If the same system carries an RTO of 1 hour, the recovery process itself, not just the backup schedule, must bring it fully back online within 60 minutes of the outage being declared.  

Backup, disaster recovery, and business continuity get used loosely in everyday conversation, but regulators and auditors treat them very differently. That distinction is worth holding onto.  

Another term that you’ll see crop up with regularity is your critical ICT third-party provider (CTPP). This is a vendor whose failure could cause systemic damage across your services.  

Under DORA, these providers face direct oversight from EU supervisors rather than oversight through their clients alone. If your disaster recovery vendor could reasonably be designated a CTPP, that status changes what your contract with them needs to include, which is a point worth returning to once you’re assessing vendors rather than definitions. 

What’s actually changed under DORA and NIS2 

DORA and NIS2 have turned back up and disaster recovery into an enforceable regulatory obligation, complete with testing requirements, strict reporting deadlines and financial penalties. DORA has applied directly across the EU since January 2025. NIS2 took effect from October 2024, though national transposition is still uneven across member states. 

DORA’s ICT risk management, testing and incident reporting requirements 

DORA’s Articles 11 and 12 require financial entities to maintain ICT business continuity policies, disaster recovery plans and backup policies. These must be tested regularly and updated after every disruption, resilience test or audit finding. Articles 17 to 23 go further, setting a strict incident reporting regime: major ICT incidents must be classified against defined criteria and reported to regulators within hours. 

NIS2 article 21 and the business continuity obligation 

NIS2 Article 21(2)(c) requires essential and important entities to put business continuity measures in place, covering backup management, disaster recovery and crisis management, as part of a wider all-hazards approach to risk. 

Where GDPR fits alongside DORA and NIS2 

GDPR doesn’t set disaster recovery requirements directly, but it does constrain where backup copies of personal data can legally be restored to and processed from. A recovery plan that restores personal data into a jurisdiction without an adequacy decision or valid transfer mechanism can satisfy DORA or NIS2’s business continuity requirements, while still creating a separate GDPR breach.  

This is worth checking specifically for any recovery region outside the European Economic Area (EEA). 

DORA vs NIS2 at a glance 

Where ISO 22301, ISO 27001 and TIBER-EU fit in 

Neither regulation mandates ISO 22301 or ISO 27001, but both map closely onto what auditors expect, so they’re worth adopting as a working framework rather than treating as optional extras.  

DORA also introduces threat-led penetration testing (TLPT) under TIBER-EU. This requires the largest, most critical entities to simulate genuine attacks on live systems, going well beyond a tabletop exercise. 

Penalties and enforcement, what’s actually at stake 

Boards tend to respond to figures faster than they respond to abstract risk. A few worth having ready to justify changes in your infrastructure: 

• DORA fines can reach €10 million or 5-10% of annual turnover, whichever is higher 

• NIS2 fines can reach €10 million or 2% of global turnover for essential entities, and €7 million, or 1.4% for important entities 

• Both regimes permit further sanctions, including temporary suspension of services 

In short, both DORA & NIS2 dictate that a recovery plan that has never been independently tested is not just an operational weakness, but a compliance and financial risk to the business.  

The real gap: compliant on paper vs resilient in practice 

A disaster recovery plan can tick every regulatory box under DORA or NIS2 and still fail when it matters most.  

Compliance confirms that policies, contracts and test records exist.  

Resilience confirms that systems actually recover within the agreed time, with the agreed data intact.  

These are different questions and treating them as one is where most gaps hide. 

Example: A firm passes its annual audit with a fully documented plan, signed-off RTOs and RPOs, and years of simulation exercises on file. Then a genuine ransomware incident hits, and the real failover takes fourteen hours against a stated RTO of four.  

The last full restore test only covered a subset of systems, not the production environment under real load. The paperwork was accurate. The plan had simply never been proven. 

5 signs a plan is compliant, but not resilient 

• Testing consists only of discussion-based simulation exercises or plan reviews, with no full restore under production-like conditions 

• RTOs and RPOs exist on paper but haven’t been checked against actual recovery times in the last twelve months 

• Backup integrity is assumed, not verified, with no independent check that restored data is clean and usable 

• Recovery documentation hasn’t been updated since the last infrastructure change 

• No named owner exists for decisions in the first hour of an incident, which is a governance gap as much as a technical one. 

Physical resilience gets overlooked in the same way. A plan can pass every documentary check while both the primary and recovery sites sit on the same power grid or in the same flood zone, a gap that only becomes visible when a physical disruption, not a cyberattack, is what takes systems down. 

What auditors and regulators actually look for 

Auditors now ask for evidence rather than assurance, including:  

• Restore logs 

• Timestamped test results 

• Clear lines from a specific test to a specific fix 

A plan that shows intent, but no outcome, still counts as a gap, however well it reads on paper. 

The organisations that close this gap fastest stop asking whether they have a disaster recovery plan and start asking when they last proved it works, and against what.  

That second question is where a disaster recovery audit comes in, but more on that later.  

The sovereignty-resilience trade-off no one talks about 

The trade-off is this: the disaster recovery setup that restores fastest is often not the one that keeps your data under EU jurisdiction, and few organisations choose between the two deliberately.  

Regulation pushes towards rapid, flexible recovery, wherever that capacity happens to sit.  

Sovereignty expectations pull the other way, favouring infrastructure that stays under EU control even if that means a slower or costlier recovery path.  

Most disaster recovery advice ignores this clash entirely, as though speed and sovereignty always align. In practice, they often don’t, and the choice of recovery region is exactly where that tension surfaces. 

Data residency vs data sovereignty vs data localisation 

Before you can choose a recovery region sensibly, it helps to be precise about what you’re actually protecting against, because these three terms get treated as synonyms and aren’t.  

Data residency 

Means data is stored in a given location, which is the easiest requirement to satisfy and the easiest to satisfy without noticing you haven’t gone far enough.  

Data sovereignty 

The data stays subject to the laws of that jurisdiction, regardless of who owns the infrastructure or where the parent company is based.  

Data localisation 

A hard legal requirement that certain data must stay within a country or region, no exceptions.  

This distinction matters directly for disaster recovery, because a backup copy can sit in an EU data centre and still fail a sovereignty test, if the provider running it remains legally reachable by a foreign government under its home jurisdiction’s laws. 

Sovereign cloud vs hyperscaler vs hybrid 

That gap between residency and sovereignty is precisely what shapes the choice between the three infrastructure models available for a recovery estate. 

None of these models is right in every case, but for disaster recovery in the regulated EU market, sovereign cloud is usually the strongest starting point. It closes the sovereignty gap outright, and the tooling maturity gap that once separated it from hyperscalers has narrowed considerably as providers have matured their recovery and failover capabilities specifically for regulated workloads. 

A hyperscaler solves for raw speed and scale, but it reopens the jurisdictional question this section opened with, worth weighing carefully rather than defaulting to for convenience. 

Hybrid setups are how many regulated organisations balance this in practice, keeping regulated workloads on sovereign infrastructure while routing genuinely lower-sensitivity recovery workloads through a hyperscaler.  

For most regulated organisations, though, the more confident and durable path is to build the recovery estate on sovereign infrastructure from the outset, and treat hyperscaler use as the exception that needs justifying, rather than the default that sovereignty has to work around. 

A decision checklist for choosing where recovery data lives 

Given that trade-off, the practical question isn’t which model is best in the abstract, but which model fits your specific recovery obligations. Before settling on a recovery region or provider, work through: 

• Which regulation, DORA, NIS2, or a national equivalent, actually drives your sovereignty requirement, and does it cover the whole estate or only specific systems 

• Whether your provider’s parent company is subject to foreign legal access requests, regardless of where the servers physically sit 

• Whether a hybrid model, sovereign infrastructure for regulated data and hyperscaler for everything else, meets both compliance and recovery time needs 

• What the real cost and performance difference is for your recovery workloads specifically, tested with actual figures rather than assumptions 

Few organisations make this trade-off consciously for their disaster recovery assets. It’s usually inherited from whichever provider was chosen years ago, long before DORA or NIS2 existed, and rarely revisited once the original decision is made. Revisiting it deliberately, specifically for recovery data rather than the estate as a whole, is one of the more overlooked steps in a genuine disaster recovery reassessment. 

Another commonly overlooked step: third party risk. 

Vendor and third-party risk: the overlooked compliance dimension 

As mentioned previously in this article, under most regulations, a disaster recovery failure remains your organisation’s responsibility, even when a vendor runs the infrastructure.  

Regulators hold you accountable, not your provider, even if a critical CTPP causes the outage. That’s why vendor contracts, not just technical architecture, also belong in the compliance conversation. 

What DORA requires in ICT third-party contracts 

Per DORA’s Articles 28 to 30, there are specific terms that ICT contracts must meet. These include clear service levels, audit rights, exit provisions, and cooperation during incidents. If a provider could reasonably be designated a CTPP, your contract needs to reflect that, since CTPPs face direct oversight from EU supervisors on top of whatever your own agreement covers. 

What happens if our DR vendor is designated a CTPP? 

While they fall under direct supervision from EU authorities, your organisation still carries the compliance obligation. Designation adds a layer of oversight; it doesn’t remove your responsibility. 

DRaaS vs colocation 

The choice between disaster recovery as a service and colocation usually depends on three things:  

1. How fast you need to recover 
2. How much expertise you can sustain internally 
3. How much control you need over where data sits 

DRaaS suits firms wanting speed without building the capability themselves, provided the sovereignty questions covered earlier in this article are properly resolved with the provider first.  

Colocation suits firms needing stronger control over data location, where infrastructure has to stay identifiably within a specific jurisdiction rather than managed entirely by a third party. 

Either route can quietly create vendor lock-in if exit provisions aren’t negotiated up front. A DRaaS contract without a clear, tested exit path leaves you dependent on one provider’s proprietary recovery tooling, which is exactly the operational control question worth resolving before signing, not after an incident. 

Is DRaaS compliant with DORA and NIS2? 
It can be, provided the contract meets DORA’s third-party requirements and the provider can demonstrate tested recovery, not just hosted backups. 

Proportionality for smaller entities 

Per the Simplified ICT Risk Management Framework, smaller regulated firms get simplified obligations, not an exemption. The duty to manage third-party risk still applies, scaled to the size and complexity of the business. 

Cyber insurance and testing evidence 

Insurers increasingly ask for proof of recent, successful recovery tests before underwriting cover. That makes testing evidence commercially useful, not just a regulatory formality. 

Reevaluating your DR posture 

Reevaluating disaster recovery means checking six areas raised throughout this article: data residency and jurisdiction, legal and regulatory exposure, operational control and vendor lock-in, business continuity and physical resilience, governance, compliance and sovereignty readiness, and security and access governance.  

Most organisations check one or two of these at a time, which is why gaps go unnoticed until an incident or audit forces the question. 

These areas interact more than they first appear to.  

Weak governance often hides behind strong technical documentation, since nobody has tested whether the plan holds under pressure.  

Vendor lock-in can quietly undermine a residency commitment, if a provider’s parent company stays reachable under foreign law regardless of where servers physically sit. 

Can we assess all six areas ourselves? 
Some organisations can, but an independent review tends to surface issues faster, since internal teams often assume controls work rather than testing them directly. 

With this in mind, here are six questions you need to be asking when reevaluating back up and disaster recovery. 

The 6 questions to ask before your next audit 

• Where does recovery data legally sit, and under whose jurisdiction? 

• What’s the actual exposure if DORA, NIS2, or a national equivalent isn’t met? 

• How dependent is recovery on a single vendor, and what would switching cost? 

• Has a full restore been tested under production-like conditions in the last year? 

• Is there a named owner accountable for each stage of recovery, with evidence to show it? 

• Who can access backup systems, and is that access properly governed? 

How often should we reevaluate our DR posture? 
At least annually, and immediately after any merger, major infrastructure change, or new regulatory deadline. A BIA left unreviewed for longer than that tends to drift out of step with current business priorities. 

How to prioritise gaps once you’ve found them 

Not every gap carries equal weight. Start with anything touching legal exposure or untested recovery, since those are the two most likely to surface during an actual incident or audit. Governance and access gaps come next, as they’re usually cheaper to fix but easy to overlook. Vendor lock-in tends to take longest to resolve, so flag it early even if you address it last. 

Conclusion 

Backup disaster recovery in a regulated EU market now sits at the intersection of three separate pressures:  

1. Proving resilience under DORA and NIS2 
2. Keeping recovery data within the right jurisdiction 
3. Managing the vendor risk that comes with both.  

If you’re not confident how your current setup would hold up, feel free to reach out to the Ilkari team to discuss your disaster recovery needs, for cloud or colocation.