Separating NIS2 and DORA Compliance: A Compliance Cluster in Kubernetes
NIS2 and DORA require various obligations. Here's how cloud architects can implement both as separate compliance clusters in Kubernetes and pass audits.
Two regulatory frameworks, one cluster, a lot of confusion. Organisations that squeeze NIS2 and DORA into the same Kubernetes environment are building an audit problem that only surfaces when the inspector arrives. A clean separation into dedicated compliance clusters saves the weeks a team would otherwise spend hunting down evidence when it matters most.
Key Takeaways
- NIS2 and DORA address different worlds: DORA has applied to the financial sector and its IT service providers since 17 January 2025; NIS2 covers a far broader range of critical and important entities. For banks and insurers, DORA takes precedence as the more specific rule.
- Compliance clusters mean separation with evidentiary weight: Dedicated namespaces, enforced policies, and automatically collected evidence beat any after-the-fact documentation. Auditors want to see the target state enforced technically, not described in a PDF.
- Data sovereignty belongs in the cluster configuration, not the contract: Region pinning, encryption, and traceable access paths determine whether an architecture survives an audit or fails on day one.
Related:Kubernetes as the AI Default OS: Clusters as a Compliance Question / AI Sovereignty Starts with Infrastructure
1. Separate NIS2 and DORA before the architecture takes shape
The most common mistake happens before the first line of YAML. Teams treat NIS2 and DORA as a single compliance package because both come from Brussels and both talk about resilience. In practice, they target different audiences with different levels of depth.
DORA, the Digital Operational Resilience Act, has been in force since early 2025. It applies directly to financial entities and brings critical third-party IT providers under a dedicated supervisory and contractual regime. NIS2, the underlying EU directive, casts a far wider net: energy, healthcare, transport, digital infrastructure, and many suppliers all fall within its scope. In Germany, the NIS2 implementation act has been passed and has been in force since December 2025, making the obligation to comply concrete.
What matters for architecture is the order of precedence. For a regulated financial institution, DORA takes precedence over the general NIS2 requirements wherever both cover the same subject matter. A cloud architect in the mid-market building for a bank therefore plans primarily against DORA. Building for an energy provider or a mechanical engineering firm means planning against NIS2. Serving both types of client means keeping both worlds separate – not merged.
2. Clean cluster boundaries instead of mixed workloads
What is a compliance cluster? A compliance cluster is a self-contained Kubernetes environment in which workloads governed by a specific regulatory framework run in isolation – with their own policies, their own access controls, and their own audit trail. The boundary is technically enforced and documented throughout ongoing operations.
The term reflects a deliberate segmentation decision. The core rule: workloads subject to different regulatory frameworks do not share a trusted zone. In Kubernetes, this can be implemented on two levels.
Hard separation runs through dedicated clusters with their own control plane and their own access model. Node pools separate only compute capacity while sharing the control plane – for strictly regulated financial workloads, that is often not enough. Softer separation within a single cluster uses namespaces as a compliance boundary, secured with Network Policies that block cross-zone traffic. A namespace only becomes a real boundary once a Network Policy is actively enforced; without that, it remains nothing more than a label.
What makes the difference is enforcement. Policy engines such as Kyverno or Open Policy Agent validate every resource against defined rules before it lands in the cluster. No pod without defined resource limits, no container running as root, no image from an unapproved registry. These rules are the actual compliance evidence, because they enforce the target state – and therefore prove it at any point in time.
| Dimension | NIS2 | DORA |
|---|---|---|
| Scope | Critical and important entities across many sectors | Financial entities and their critical ICT service providers |
| Legal form | EU directive, requiring national transposition | EU regulation, directly applicable since 17 January 2025 |
| Focus | Risk management, reporting obligations, supply chain | IT resilience, third-party risk, resilience testing |
| Relationship | General framework | Sector-specific rule, takes precedence in financial services |
3. Collect evidence automatically, not on audit day
Most compliance work burns out on documentation, not on implementation. Teams that scramble to pull logs on the day of an audit have built the wrong system. A compliance cluster produces its own proof throughout normal operations.
Three layers should be active by default. The Kubernetes audit log captures every API action – who changed which resource and when. A runtime watchdog such as Falco reports suspicious container behaviour, for instance a shell spawning inside a production pod. And the policy engine logs every rejected resource as a concrete record that the rule is working. Together these three layers form an evidence chain that an auditor can follow independently, without needing to look over anyone’s shoulder.
The value extends well beyond the audit itself. NIS2 requires affected entities to report significant security incidents within tight timeframes. Organisations that have properly instrumented their telemetry can answer questions about the what and when of an incident from their own data – rather than having to reconstruct events after the fact.
4. Anchoring Data Sovereignty in Cluster Configuration
Sovereignty is decided in configuration, not in the contract with the hyperscaler. Both regulatory frameworks demand control over where data resides and who can access it. On Kubernetes, this can be technically locked down.
Region pinning via node affinities and topology constraints ensures that regulated workloads never leave their designated region. Encryption belongs on both paths – in transit and at rest – with keys whose management remains under the organization’s own control. And access runs through role-based permissions scoped to the principle of least privilege. A cluster where half the team holds cluster-admin rights won’t survive a serious audit.
What Fails an Audit
- Namespaces without enforced network policies
- Compliance existing only in documents, not enforced in the cluster
- Broad admin rights without justification
- Evidence that’s scrambled for on the day of the audit
What Holds Up
- Policy engine enforces the target state technically
- Audit log, runtime monitoring, and policy logs as a chain of evidence
- Region pinning and self-managed key management
- Permissions scoped to least privilege
5. Where Architects Should Start First
The sequence determines the effort. Those who begin with the segmentation decision – which workloads belong in which zone – avoid costly rework later. Those who start with the tooling end up writing policies for a separation they haven’t actually thought through yet.
Three steps in this order deliver the greatest leverage. First, the regulatory map: which workload falls under which framework, and are there financial workloads that trigger DORA priority. Then the separation: dedicated clusters for the hard cases, namespaces with network policies for the rest. Finally, automating evidence so that proof is generated during operations. Fines are real – the NIS2 Directive provides for sanctions of at least 10 million euros or 2 percent of global annual revenue for essential entities, whichever is higher. But the real damage typically comes earlier: in the weeks a team loses to retroactive documentation because the architecture never produced the evidence itself.
Frequently Asked Questions
Do NIS2 and DORA apply to my company at the same time?
It depends on your sector. Financial companies fall primarily under DORA, which takes precedence over general NIS2 requirements wherever both frameworks cover the same ground. Companies outside the financial sector that qualify as critical or important entities plan against NIS2. Those operating in both worlds keep them technically separate.
Is a single Kubernetes cluster enough for both frameworks?
Technically possible using namespaces with enforced Network Policies. In stricter cases – such as critical financial workloads under DORA – physical separation into dedicated clusters or node pools is the cleaner choice. The decision hinges on risk, not convenience.
What counts as solid compliance evidence in an audit?
An enforced target state plus a traceable evidence chain. A policy engine that checks every resource against rules, a Kubernetes audit log, and runtime monitoring together demonstrate that requirements actually take effect. A PDF describing the state is considerably weaker.
When did DORA take effect, and is NIS2 already law in Germany?
DORA, as an EU regulation, has applied directly since 17 January 2025. NIS2 is a directive that requires national transposition. In Germany, the NIS2 Implementation Act has been in force since December 2025. Affected organisations should therefore actively review their registration and reporting obligations.
Where should mid-sized cloud teams start?
With the regulatory map, not the tooling. First clarify which workload falls under which framework, then draw the separation, then automate the evidence. This sequence prevents costly rework and ensures that proof is already in place during normal operations.
Image source: AI-generated (Juli 2026)
