Docs
Sign In
Security & Compliance Blueprint

Sovereign Cloud Architecture for NIS2 & DORA Compliance

By Alberto Estévez • Updated August 14, 2026 • 4 min read

An architectural reference for European enterprises, financial institutions, and public sector organizations building self-hosted private cloud platforms designed to help address European digital sovereignty regulations.

Table of Contents

1. The European Regulatory Mandate (NIS2, DORA & GDPR)

Organizations operating critical infrastructure in the European Union face strict regulatory expectations. The enforcement of NIS2 (Network and Information Security Directive) and DORA (Digital Operational Resilience Act) places direct focus on infrastructure resilience, third-party ICT concentration risk, and supply chain sovereignty.

Under these frameworks, relying exclusively on centralized hyperscalers introduces operational concentration considerations. Building on an open, self-hosted foundation helps platform teams maintain full physical and legal custody over sensitive systems.

2. Architectural Pillars of a Sovereign Cloud

Regulatory Focus Area Architecture Strategy Implementation Mechanism
Data Residency & Perimeter Custody On-premises hardware and storage ownership SAN / NVMe-oF all-flash backends with local disk encryption
Third-Party Concentration Risk (DORA) Unforked open-source foundation (OpenStack + CNCF K8s) No proprietary hypervisor lock-in; open standard APIs
Operational Continuity Under Network Sever Autonomous local edge agents with local state reconciliation Decoupled control planes operable with zero outbound WAN
Access Isolation & Boundaries Hard multi-tenancy with segregated Keystone projects & OVN Geneve/VLAN overlay encapsulation with project security groups

3. Disconnected Topologies & Local Reconciliation

For defense, banking, and essential utilities, organizations often require a disconnected or air-gapped Kubernetes architecture. A common failure mode in modern platforms is an unannounced dependency on external license endpoints or remote metadata beacons.

In edgeContinuum's architecture, local facility agents reconcile desired state locally:

  • Internal Registry Pulls: Container images pull from internal OCI-compliant registries located directly within the network perimeter.
  • Autonomous Local Reconciliation: If upstream WAN connectivity drops, local controllers continue scheduling, running, and self-healing workloads locally.

4. Tenant Isolation, Boundaries & Resource Quotas

Regulated operations require strict separation of concerns between infrastructure operators and application teams. edgeContinuum implements a hierarchical structure:

  • Organizations: Top-level administrative tenant boundaries representing business units or clients.
  • Projects: Workload environments (e.g. production, staging) with isolated network namespaces and storage volumes.
  • Resource Quotas: Explicit caps configured in the console for compute vCPUs, RAM, and storage tiers to prevent noisy-neighbor starvation.

5. Automated Audit Trails & Incident Readiness

NIS2 Article 21 emphasizes incident handling and logging. Cloud management platforms must capture user authentication, API calls, and resource lifecycle modifications in structured audit logs, easily streamed to internal SIEM systems (e.g. OpenSearch, Wazuh, Splunk).

6. Implementation with OpenStack & edgeContinuum

For a detailed breakdown of how edgeContinuum delivers a private cloud control plane designed for European data residency, visit our sovereign cloud platform overview.

Review your compliance architecture with our engineers

Review your European regulatory requirements, disconnected deployment architectures, and isolation models with our platform team.

Book a technical consultation Request a sovereign pilot

Frequently asked questions

Does NIS2 require a sovereign cloud?
Not in those words. NIS2 sets obligations on risk management, supply-chain security, incident reporting and governance for essential and important entities; it does not mandate a particular hosting model. What it does is make several properties much easier to evidence if the platform is inside your control: who can access data, where it is processed, how incidents are detected and reported within the required timescales, and what your dependency on a third party actually is. Sovereignty is a means of satisfying those obligations, not a requirement in itself.
What is the difference between NIS2 and DORA for cloud architecture?
They overlap but point at different things. NIS2 is broad, covering security risk management and incident reporting across many sectors. DORA is financial-sector specific and much more prescriptive about third-party ICT risk, including register-keeping on providers, exit strategies and contractual requirements. Architecturally, NIS2 pushes you toward demonstrable control and detection; DORA pushes you toward provable independence from any single provider, which is where a platform you can run entirely inside your own perimeter changes the conversation.
Can a sovereign cloud run fully disconnected from the internet?
Yes, and this is the strongest form of the argument. In an on-premises deployment the whole platform including the control plane runs inside your perimeter, so there is no dependency on anything hosted elsewhere. Sites reconcile their desired state locally, which means a facility keeps provisioning, healing and serving workloads through a link outage and resynchronises when connectivity returns. For classified estates and critical infrastructure, that property is usually the requirement rather than a nice-to-have.
Is data residency in the EU enough for compliance?
It is necessary and frequently not sufficient. Residency answers where bytes sit; regulators increasingly ask who can access them, under whose jurisdiction the operator falls, and what happens if that operator is compelled by a foreign authority. A deployment can be physically in the EU and still be operated by an entity subject to non-EU disclosure law. That is why the useful questions are about the control plane and the operator, not only the data centre address.
What does the audit trail need to cover?
In practice, three things. Identity and access: who authenticated, under which organization and role, and what changed as a result. Resource lifecycle: creation, modification and deletion of clusters, databases and virtual machines, with the initiating principal recorded. Boundary events: tenancy changes, quota changes and anything that alters isolation between organizations. The point of tenancy enforced by platform IAM is that these questions have single, coherent answers rather than being reconstructed from several components' logs.