Sovereign business continuity and disaster recovery, as a compliance concept, refers to the ability of an organisation to restore critical operations after a disruptive event using infrastructure and processes that remain exclusively under European legal jurisdiction, independent of any foreign government’s compulsory access powers, and verified through documented, auditable testing. For essential entities under the NIS-2 Directive and financial institutions subject to the Digital Operational Resilience Act (DORA), this is no longer a design aspiration: it is an enforceable legal obligation.
What NIS-2 and DORA Actually Require
Both frameworks impose continuity obligations that go well beyond generic IT disaster-recovery practice, and supervisors are empowered to request evidence of compliance, not just self-attestation.
NIS-2 Directive Article 21(1)(c) requires essential and important entities to implement “business continuity and crisis management” as one of the minimum security measures subject to supervisory review. This obligation is not optional or risk-weighted out of existence: it applies to all entities in scope, and the accompanying ENISA guidelines on business continuity for NIS-2 entities clarify that continuity measures must be proportionate to the risk profile of the organisation, tested at documented intervals, and maintained in a form that regulators can audit. ENISA states: “Business continuity management is not a technical afterthought; it is a governance obligation. Essential entities must demonstrate, not merely assert, that their recovery capabilities are tested, documented and proportionate to the risk.”
DORA Regulation (EU) 2022/2554 is more granular. Article 11 requires financial entities to establish, implement and annually test ICT business continuity plans, including scenarios in which critical third-party ICT service providers become unavailable. Article 12 requires each entity to set documented recovery time objectives (RTOs) and recovery point objectives (RPOs) derived from a business impact analysis, classified by function criticality. The European Parliament and Council text of Article 11(6) states directly: “Financial entities shall implement ICT business continuity plans that are tested at least yearly and cover scenarios severe enough to trigger activation of the plan, including scenarios in which critical third-party ICT service providers are unavailable.”
The practical difference from conventional DR planning is threefold. First, supplier unavailability, including cloud provider outage or a foreign government compelling suspension of service, must be a named test scenario. Second, RTO and RPO targets must be documented and tested, not estimated. Third, the recovery environment itself must be legally and technically separate, so that the same incident cannot disable both the primary and the recovery system simultaneously.
Designing a Jurisdiction-Isolated Failover Architecture
A sovereign failover environment is one in which every dependency, including authentication, DNS resolution, certificate issuance, file access and communications, resolves to infrastructure under European jurisdiction and outside the reach of the US CLOUD Act, the Foreign Intelligence Surveillance Act Section 702, or equivalent foreign instruments.
In practical terms this means operating a self-hosted identity provider (such as Keycloak on European bare-metal servers) rather than relying on Azure Active Directory or Google Workspace identity, which remain subject to US jurisdiction regardless of where the data physically sits. DNS must resolve via a resolver that the organisation controls within its recovery perimeter: public DNS services operated by US entities can be compelled to redirect or withhold resolution. PKI must use a private certificate authority hosted within the sovereign environment, so that if the recovery network is isolated from the internet, TLS remains functional for internal services.
File access during a failover event should be served by a self-hosted Nextcloud cluster in the recovery environment, replicating from the primary site via encrypted, integrity-verified synchronisation. Communications, including messaging and video, must failover to a self-hosted instance of a tool such as Element (Matrix protocol) rather than Microsoft Teams or Slack, both of which depend on US-controlled back-end services. The recovery environment should be configured to operate in a fully air-gapped mode: all authentication, storage and communication functions work without any outbound internet dependency.
The DNS and PKI problem in practice
Organisations frequently underestimate how many internal services break when external DNS or public PKI is unavailable. A tabletop simulation that removes external DNS resolution from the recovery network will expose these dependencies quickly. The remediation is to pre-populate internal DNS zones with all recovery-environment hostnames and to distribute the private CA certificate to all managed endpoints before an incident occurs, not during one.
RTO, RPO and Audit Evidence
DORA does not prescribe universal numeric RTO or RPO values. Article 12 requires each entity to derive targets from its own business impact analysis and to align the most critical functions with the most aggressive recovery targets, which competent authorities in some sectors (banking supervisors under the EBA) have further specified in supervisory expectations. For tier-one critical functions, recovery within two hours is a common supervisory benchmark, though entities must document their own justified targets.
Immutable, air-gapped backup is the technical mechanism that makes a documented RPO credible to an auditor. Immutability means that backup data, once written, cannot be modified or deleted by ransomware that has obtained administrative credentials on the primary network. Air-gapping means that the backup storage is not reachable from the production network during normal operations, removing the pathway by which an attacker traverses from primary to backup. Regular restoration testing, meaning an actual restoration to a test environment followed by integrity verification, transforms a backup into audit evidence. A backup that has not been restoration-tested is not evidence of RPO compliance: it is a statement of intent.
IBM’s Cost of a Data Breach Report 2024 found the average cost of a data breach globally had reached USD 4.88 million, the highest figure ever recorded. The Veeam Data Protection Trends Report 2023 found that 74% of organisations cited ransomware as the biggest threat to data protection and continuity. Despite this, ENISA’s Threat Landscape 2023 found that only 54% of critical infrastructure operators had tested their incident response plans at least annually. These figures collectively indicate that the gap between stated continuity capability and verified continuity capability remains wide across precisely the sectors that NIS-2 and DORA most directly regulate.
| Framework | Continuity obligation | Test frequency | Audit evidence required |
|---|---|---|---|
| NIS-2 Article 21(1)(c) | Proportionate BCM integrated into risk management | Documented intervals, risk-proportionate | Test outcomes, policies, risk assessments |
| DORA Article 11 | ICT BCP covering third-party unavailability | At least annually | Test reports, scenario documentation, lessons learned |
| DORA Article 12 | Documented RTO and RPO by function criticality | Annual review and test | BIA, RTO/RPO targets, restoration test records |
| ISO 22301:2019 | BCMS with continual improvement cycle | At least annually (or after significant change) | Management review, exercise reports, corrective actions |
The EU Cyber Solidarity Act and Independent Recovery Capability
The EU Cyber Solidarity Act (Regulation (EU) 2024/2847) establishes a European cybersecurity reserve: a pool of pre-contracted private-sector incident response providers that member states and EU institutions can activate during large-scale or cross-border cybersecurity incidents. It is a mutual-assistance mechanism, not a substitute for organisational resilience.
The critical implication for essential entities is sequencing. The cybersecurity reserve is available after an organisation has exhausted its own response and recovery capabilities. An essential entity that has not invested in independent recovery capability cannot simply invoke cross-border mutual assistance at the moment of crisis. Regulators will examine whether the entity’s own BCM was adequate before the reserve was called upon. This makes demonstrated independent recovery capability a precondition for legitimately accessing the solidarity mechanism, not an alternative to it.
Sovereign SIEM, Out-of-Band Alerting and Reporting Deadlines
NIS-2 Article 23 requires essential entities to submit an early warning to the relevant competent authority within 24 hours of becoming aware of a significant incident, followed by a full incident notification within 72 hours. Meeting these deadlines requires detection and alerting infrastructure that remains operational when the production environment is under attack.
A sovereign SIEM, meaning a self-hosted security information and event management system operating on European infrastructure under the organisation’s exclusive control, must ingest telemetry from the production environment, the recovery environment, and the network boundary simultaneously. Critically, the SIEM itself must not depend on the production network for its own operation: if an attacker segments or shuts down the primary network, the SIEM must continue to receive logs and generate alerts through an out-of-band channel such as a dedicated management network or a cellular-connected monitoring node.
Forensic-ready logging architecture means that logs are written in a tamper-evident format, retained for a period consistent with both NIS-2 supervisory expectations and any sector-specific requirements such as those under DORA for financial entities, and accessible to the incident response team even when primary systems are offline. The 24-hour early-warning window begins from the moment of awareness, not from the moment of confirmed attribution: a sovereign SIEM that detects anomalous lateral movement at 02:00 starts that clock immediately.
Testing: Tabletop Exercises, Live Failover Drills and DORA TLPT
DORA’s Threat-Led Penetration Testing (TLPT) requirements, described in Articles 26 and 27, mandate that significant financial entities conduct penetration tests against live production systems using threat intelligence-led scenarios, at least every three years. TLPT is distinct from BCP testing but intersects with it: TLPT findings should feed directly into the BIA that informs RTO and RPO targets and may reveal that a continuity scenario was insufficiently severe.
For sovereign continuity testing specifically, the correct sequence is: tabletop exercise first, live failover drill second, and the two must be kept architecturally separate from each other. A tabletop exercise should simulate the decision-making process under a named incident scenario (for example, a ransomware attack that has encrypted all primary storage and disabled the production identity provider) without actually activating the recovery environment. This allows the organisation to identify procedural gaps without risking the recovery environment’s integrity.
A live failover drill activates the actual recovery environment in isolation from the production network. The test must validate that the sovereign identity provider authenticates real user accounts, that files are accessible from sovereign Nextcloud with correct permissions, that internal communications function without any outbound internet dependency, and that the SIEM continues to generate alerts and log events. The results, including time to first successful authentication, time to first file access, and any failures encountered, constitute the audit evidence required under both NIS-2 Article 21 and DORA Article 11.
ISO 22301:2019 provides the overarching business continuity management system framework within which both tabletop and live exercises sit. Its requirement for post-exercise corrective action and management review ensures that test findings translate into documented improvements rather than filed reports. Regulators examining NIS-2 or DORA compliance will look for exactly this closed loop: test, find gaps, remediate, retest, document.
Frequently Asked Questions
What is the difference between a general DR plan and what NIS-2 Article 21(1)(c) actually requires?
A general DR plan focuses on restoring technical services after disruption. NIS-2 Article 21(1)(c) goes further by requiring that continuity measures be proportionate to the risk, regularly tested, documented in a way that supports supervisory review, and integrated into a broader risk-management framework. Regulators can request evidence of actual test outcomes, not just the existence of a written plan.
Can an organisation use a US hyperscaler as its recovery environment and still comply with DORA Article 11?
DORA Article 11(5) requires recovery sites to be clearly separated from primary sites and able to operate independently. If the primary and recovery environments both depend on the same US-controlled cloud, the separation requirement is not met, and the CLOUD Act creates a channel through which US authorities could access or compel action on data in both environments simultaneously.
What RTO and RPO values does DORA specify for financial institutions?
DORA does not prescribe universal numeric RTO and RPO values. Article 12 requires each financial entity to define its own targets based on a business impact analysis, classify them by function criticality, and ensure recovery of critical functions within timeframes that competent authorities may further specify. The entity must document and test these targets at least annually.
What is the EU Cyber Solidarity Act’s cybersecurity reserve, and when can an organisation invoke it?
The Cyber Solidarity Act (EU) 2024/2847 establishes a cybersecurity reserve of pre-contracted incident-response providers available to member states during large-scale incidents. An essential entity cannot invoke the reserve unilaterally; it must first exhaust its own response and recovery capabilities. Demonstrated independent recovery capability is a precondition, not an alternative, to cross-border mutual assistance.
How does a sovereign SIEM support the NIS-2 24-hour early-warning deadline?
NIS-2 Article 23 requires an early warning within 24 hours of becoming aware of a significant incident. A sovereign SIEM with out-of-band alerting ensures that security teams receive detection signals even when production systems are compromised. Without this, an attacker who disables the primary network could suppress alerting and cause the organisation to miss the 24-hour window, creating a separate compliance failure on top of the incident itself.