DORA vs. NIS2 — Which EU Resilience Rule Applies to You?

DORA and NIS2 at a Glance

Few compliance questions currently cause as much confusion in the DACH market as "DORA or NIS2?". The reason: both are EU mandates for digital and operational resilience, both address ICT risk management, and both have been in force since 2025 — yet they have different scopes, different supervisory authorities, and different legal consequences. Conflating them risks duplicated effort or, worse, an unguarded gap.

A second misunderstanding compounds the issue, one we encounter almost weekly in consulting practice: the acronym "DORA" is systematically confused. In a regulatory context, DORA stands for the Digital Operational Resilience Act — an EU regulation for the financial sector, applicable since 17 January 2025. In DevOps circles, however, "DORA" refers to the DORA metrics (DevOps Research and Assessment): Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service. Two entirely different worlds, identical four letters.

This article resolves both confusions. We provide a clean disambiguation, a side-by-side comparison of the DORA regulation and NIS2, a decision tree for the question "which rule applies to us?", and a clear answer on the precedence relationship in the financial sector (the lex specialis principle). The basis is the official EU texts and the German NIS2 transposition.

The DORA Trap: Regulation vs. DevOps Metric

Before comparing DORA and NIS2, a terminological clarification is needed that is almost always missing in German-language sources. In 2026, "DORA" denotes two fundamentally different things, and search queries mix both indiscriminately.

First: the Digital Operational Resilience Act is Regulation (EU) 2022/2554. It governs the digital operational resilience of financial entities — banks, insurers, payment service providers, crypto-asset service providers, trading venues, and their critical ICT third-party providers. DORA has been directly applicable since 17 January 2025. 2025 was considered a transition year; 2026 is the year of active enforcement, partly via the Register of Information (cut-off date 31 December 2025).

Second: the DORA metrics from the DevOps domain originate from the DevOps Research and Assessment program. They measure the software delivery performance of engineering teams and have nothing to do with EU regulation. For readers who want to dig into that distinction: our guide "DORA Metrics Explained" deals exclusively with the DevOps metrics and is the right reference for Deployment Frequency and Lead Time — not financial supervision.

Practical consequence: when your compliance department says "we need to implement DORA", first determine which DORA is meant. A financial entity almost always means the regulation. An engineering lead almost always means the metrics. Those five seconds of clarification prevent weeks of misdirected planning.

What Is the DORA Regulation?

The Digital Operational Resilience Act is the EU framework for the digital operational resilience of the financial sector. Its objective is for financial entities to withstand severe ICT disruptions — cyberattacks, outages, third-party provider failures — without endangering financial stability or customer protection. DORA has been applicable since 17 January 2025 and is detailed through regulatory technical standards issued by the European Supervisory Authorities (EBA, ESMA, EIOPA).

DORA rests on five pillars: first, ICT risk management with a documented framework under the responsibility of the management body; second, the handling, classification, and reporting of ICT-related incidents to the competent supervisor; third, digital operational resilience testing, including threat-led penetration testing (TLPT) for significant institutions; fourth, ICT third-party risk management including mandatory contractual clauses and the Register of Information; fifth, information sharing on cyber threats.

The addressees are roughly twenty categories of financial entities — from credit institutions and investment firms to payment and e-money institutions, insurers and reinsurers, crypto-asset service providers, and trading venues. In addition, DORA establishes an oversight regime for critical ICT third-party providers (such as major cloud providers), which can be supervised directly by the European Supervisory Authorities.

What Is NIS2?

NIS2 is EU Directive (EU) 2022/2555 on the security of network and information systems. It is the broad horizontal framework for cybersecurity across virtually all sectors critical to society and the economy — energy, transport, water, health, digital infrastructure, public administration, postal services, waste, chemicals, food, manufacturing, and digital providers. Unlike a regulation, a directive must be transposed into national law.

In Germany, transposition is implemented via the NIS2 Implementation Act (NIS2UmsuCG). It significantly tightens obligations compared to the previous IT security regime: mandatory risk management covering ten minimum-measure areas, a tiered reporting regime for significant security incidents (early warning within 24 hours, notification within 72 hours, final report within one month), supply chain security, and a non-delegable management responsibility with personal liability. A deeper treatment of the ten measure areas and deadlines is available in our article on the NIS2 Implementation Act.

NIS2 distinguishes between "essential" and "important" entities, with classification driven primarily by sector and company size (thresholds typically from 50 employees or EUR 10 million in turnover, with sector-specific special cases). The set of affected companies, numbering in the tens of thousands, is significantly larger than under the predecessor regime.

DORA vs. NIS2: The Comprehensive Comparison

The fundamental difference can be stated in one sentence: DORA is a sector-specific, directly applicable resilience framework exclusively for the financial sector; NIS2 is a cross-sector cybersecurity minimum standard that applies through national transposition laws. Both overlap in ICT risk management but diverge in scope, supervision, reporting paths, and legal nature.

The following table systematically contrasts the decision-relevant criteria. It does not replace legal advice but provides the structure with which IT and compliance leaders can perform the mapping for their organization.

Important: the comparison is not a value judgment. Both frameworks are mandatory within their respective scopes. The relevant question is not "which is better" but "which applies to us — and in what order".

Precedence of DORA in the Financial Sector (lex specialis)

The decisive question for many institutions is: "We are a bank/insurer — does DORA, NIS2, or both apply to us?". The answer follows from the principle lex specialis derogat legi generali — the more specific rule displaces the more general one.

DORA is the sector-specific rule for the financial sector and explicitly takes precedence over the ICT risk management and reporting obligations of NIS2 for the financial entities it covers. Concretely: if a financial entity meets the DORA requirements on ICT risk management, incident reporting, resilience testing, and third-party risk, it is not additionally held to the corresponding NIS2 obligations to that extent. Here DORA acts as lex specialis, NIS2 as lex generalis.

This does not mean NIS2 is entirely irrelevant for financial entities. The specificity effect concerns the congruent ICT areas. Aspects that DORA does not address, or addresses differently, or group units outside the DORA scope (such as non-financial subsidiaries) may still fall under NIS2. A robust mapping therefore requires an entity- and activity-specific analysis — not a blanket group-level statement.

Overlaps in ICT Risk Management

Despite their different reach, DORA and NIS2 share a common conceptual core: documented, management-body-owned ICT/cyber risk management, structured incident handling with reporting obligations, supply chain and third-party security requirements, and business continuity and recovery. Implementing either framework cleanly already covers a substantial portion of the substance of the other.

This overlap is the strategic opportunity: a common control set, mapped to a recognized security framework, can be aligned against both DORA and NIS2 requirements simultaneously. In practice we use the NIST Cybersecurity Framework 2.0 as the integrating bracket; the detailed treatment is in our NIST CSF 2.0 assessment guide. This avoids two separate programs with redundant evidence.

The differences must not be flattened in the process. DORA demands considerably more granular third-party governance (Register of Information, mandatory clauses, TLPT for significant institutions), while NIS2 sets its own sharper accents with the tiered 24/72/one-month reporting scheme and non-delegable management liability. An integrated target picture must therefore cover both maxima, not the lowest common denominator.

Decision Tree: Which Rule Applies to You?

The following step sequence leads from organizational reality to the correct regulatory mapping. It is intended as an initial indication and does not replace a legal case-by-case assessment — but it provides the robust structure to set up the compliance program correctly.

1. 1Is your entity a financial entity within the meaning of DORA (bank, insurer, payment/e-money institution, investment firm, crypto-asset service provider, trading venue)? If yes: DORA applies and takes precedence for the ICT obligations — proceed to step 2. If no: proceed to step 4.
2. 2Do you fully meet the five DORA pillars (ICT risk management, incident reporting, resilience testing, third-party risk incl. Register of Information, information sharing)? If no: prioritize the DORA program, as 2026 is the active enforcement year.
3. 3Are there entities or activities within the same group outside the DORA scope (e.g., non-financial subsidiaries, IT service companies)? If yes: assess NIS2 applicability separately for those entities — proceed to step 4. If no: mapping complete, DORA is governing.
4. 4Does the entity fall under a NIS2 sector (energy, transport, water, health, digital infrastructure, public administration, etc.) and exceed the size thresholds (typically from 50 employees or EUR 10 million in turnover, with sector-specific special cases)? If yes: classify it as an essential or important entity — proceed to step 5. If no: no direct DORA/NIS2 obligation, but still review third-party contractual supply chain requirements.
5. 5Implement the NIS2 obligations: ten minimum-measure areas, tiered reporting (24 h / 72 h / 1 month), supply chain security, and non-delegable management responsibility — and map the control set to a recognized security framework to avoid duplicating any DORA requirements.

When Which Rule — and When Both

When DORA: you are a regulated financial entity or a critical ICT third-party provider to such. Then DORA is not optional but directly applicable law — with precedence over the congruent NIS2 ICT obligations. The 2026 priority here is proof: Register of Information, contractual ICT third-party clauses, and an auditable ICT risk framework.

When NIS2: you operate critical infrastructure or essential services outside the financial sector and exceed the size thresholds. Then the national NIS2 transposition law applies, with the ten measure areas, the 24/72/one-month reporting scheme, and personal management liability. Time pressure in the DACH market is particularly high here because no long transition period is provided.

When both: in mixed groups with financial and non-financial units, or for financial entities whose group also operates NIS2-relevant services. Here we do not recommend a dual parallel program but an integrated resilience target picture: a common control set mapped to NIST CSF 2.0 that takes the stricter requirement per domain as the target value and carries entity-specific evidence (DORA register vs. NIS2 reporting chain) as derivations. The methodological superstructure for this is provided in our IT governance assessment guide.

Conclusion

The question "DORA or NIS2?" has two answers — a terminological one and a regulatory one. Terminologically: the DORA regulation and the DORA metric are not the same; clarify that before any program starts. Regulatorily: DORA is the sector-specific rule for the financial sector and displaces the congruent NIS2 ICT obligations there, while NIS2 is the broad cross-sector minimum standard for critical entities.

For pure financial entities, DORA is the governing framework, and in 2026 the focus shifts from design to auditable proof. For critical entities outside the financial sector, NIS2 is the unavoidable obligation with high time pressure. Mixed groups need an integrated target picture instead of two parallel programs.

Our recommendation to CIOs and compliance leaders: first cleanly clarify the entity-to-rule mapping (decision tree above), then build a common control set mapped to a recognized security framework, and carry the rule-specific evidence as derivations from it. This avoids both the costly duplication and the dangerous gap.

As consultants for IT governance and resilience, we accompany organizations from regulatory mapping through control mappings to auditable proof. Use our assessment tools to determine your current resilience maturity and derive a robust roadmap.

Sources & References

The legal acts and standards referenced in this article are based on the following official sources:

• DORA — Regulation (EU) 2022/2554 (EUR-Lex): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554
• NIS2 — Directive (EU) 2022/2555 (EUR-Lex): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2555
• BSI — NIS-2 Regulated Companies: https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/nis-2-regulierte-unternehmen_node.html
• ISACA — Resilience and Security in Critical Sectors: Navigating NIS2 and DORA: https://www.isaca.org/resources/white-papers/2025/resilience-and-security-in-critical-sectors-navigating-nis2-and-dora-requirements
• NIST Cybersecurity Framework 2.0: https://www.nist.gov/cyberframework