DORA vs NIS2: What Compliance Officers Need to Know About the Overlap

Two Regulations, One Calendar, Different Masters

On January 17, 2025, two of the most consequential pieces of EU cybersecurity legislation became applicable simultaneously: the Digital Operational Resilience Act (DORA) and the Network and Information Systems Directive 2 (NIS2). For compliance officers in financial services, this convergence creates an urgent question: which regulation takes precedence, where do they overlap, and what happens when their requirements conflict?

The answer lies in a single legal concept that most compliance teams underestimate: lex specialis derogat legi generali — the specific law overrides the general law. DORA is the specific law for financial services. NIS2 is the general cybersecurity framework for essential and important entities across all sectors. Where they overlap, DORA wins. But the boundaries of that override are more nuanced than most institutions appreciate.

The Lex Specialis Principle: What It Actually Means

Article 1(2) of NIS2 states explicitly that where sector-specific EU legal acts require measures "at least equivalent" to NIS2's obligations, those sector-specific acts take precedence. DORA is the sector-specific act for financial entities. Article 1(1) of DORA reinforces this by establishing itself as the comprehensive framework for digital operational resilience in the financial sector.

In practice, this means that a bank subject to both DORA and NIS2 does not need to comply with NIS2's risk management requirements (Art. 21 NIS2) or incident reporting obligations (Art. 23 NIS2) to the extent that DORA's equivalent provisions apply. But "to the extent" is the critical qualifier. Not every NIS2 obligation has a DORA equivalent, and not every financial entity is exempt from all NIS2 requirements.

The European Commission's interpretive guidance clarifies three scenarios:

Full override: Where DORA imposes requirements at least equivalent to NIS2, DORA's requirements apply exclusively. This covers ICT risk management (DORA Art. 5-16 vs. NIS2 Art. 21), incident reporting (DORA Art. 17-23 vs. NIS2 Art. 23), and resilience testing (DORA Art. 24-27 vs. NIS2 Art. 21(2)(e)).

Partial overlap: Where DORA addresses a topic but with different scope, both may apply depending on the specific obligation. Supply chain security under NIS2 Art. 21(2)(d) goes beyond DORA's third-party focus on ICT service providers — it covers all supply chain dependencies.

No DORA equivalent: Where NIS2 imposes obligations that DORA does not address at all, NIS2 applies in full. This includes certain information-sharing provisions and cooperation with national CSIRTs.

Incident Reporting: The Most Visible Divergence

The most operationally significant difference between DORA and NIS2 lies in incident reporting — not just in timelines, but in who receives the report, what triggers the obligation, and what information must be included.

DORA Incident Reporting (Art. 17-23)

DORA requires financial entities to classify ICT-related incidents against seven quantitative criteria defined in Art. 18(1): the number of clients affected, the duration, the geographic spread, data losses, the criticality of services affected, the economic impact, and cross-border implications. When an incident meets the "major" threshold across these criteria, a three-phase reporting obligation activates:

• Initial notification: Within 4 hours of classification as major (Art. 19(4)(a))
• Intermediate report: Within 72 hours, with updated impact assessment (Art. 19(4)(b))
• Final report: Within 1 month of the intermediate report, including root cause analysis and remediation measures (Art. 19(4)(c))

Reports go to the relevant national competent authority (NCA) — the ACPR in France, BaFin in Germany, the CSSF in Luxembourg — which then shares with the ESAs (EBA, ESMA, EIOPA) via a centralized reporting hub (Art. 21).

NIS2 Incident Reporting (Art. 23)

NIS2 requires essential and important entities to report "significant" incidents to the national CSIRT or competent authority:

• Early warning: Within 24 hours of becoming aware of the significant incident
• Incident notification: Within 72 hours, including initial assessment of severity and impact
• Final report: Within 1 month, including detailed description, root cause, and cross-border impact

The trigger threshold is different: NIS2's "significant incident" is defined in Art. 23(3) as one causing severe operational disruption or financial loss, or affecting other persons by causing considerable material or non-material damage.

Practical Implications for Financial Entities

For a bank experiencing a major ICT incident, the DORA reporting pathway supersedes NIS2 — the report goes to the financial NCA, not the CSIRT, and the initial deadline is 4 hours, not 24. However, if the same incident also affects the bank's non-financial services (e.g., a payment institution also operating a non-financial marketplace), the NIS2 obligation may apply to the non-financial component.

Where NIS2 Still Applies to Financial Entities

The lex specialis principle does not create a blanket exemption. Several NIS2 obligations remain relevant even for DORA-regulated entities:

Supply chain security beyond ICT (NIS2 Art. 21(2)(d)): DORA's Pillar IV (Art. 28-44) focuses specifically on ICT third-party service providers. NIS2's supply chain security obligations extend to all suppliers and service providers — including non-ICT vendors whose compromise could affect the entity's security. A financial institution relying on a physical document courier, a facilities management provider with building access, or a cleaning service with access to data centers may find these relationships governed by NIS2 rather than DORA.

CSIRT cooperation (NIS2 Art. 11-13): NIS2 establishes a cooperation framework between entities and national CSIRTs for threat intelligence sharing, coordinated vulnerability disclosure, and crisis response. DORA does not replicate this framework, and financial entities remain expected to participate in national cybersecurity coordination.

Certification and standardization (NIS2 Art. 24-25): NIS2 encourages the use of European and international standards and certification schemes. While DORA does not preclude this, it does not establish equivalent provisions — and NCAs may expect financial entities to demonstrate compliance with relevant cybersecurity standards as part of their overall resilience posture.

The Dual-Regulated Entity Challenge

The most complex compliance scenarios arise for entities regulated under both frameworks simultaneously. Payment institutions operating electronic marketplaces, financial market infrastructures providing non-financial services, and financial holding companies with non-financial subsidiaries may find themselves subject to DORA for their financial services and NIS2 for their non-financial activities.

For these entities, the compliance challenge is organizational:

Governance: Art. 5 of DORA places ICT risk management responsibility on the management body. NIS2 Art. 20 similarly requires management bodies to approve cybersecurity risk management measures. In practice, this means the board agenda must address both frameworks — but the reporting structures, escalation paths, and approval workflows may differ.

Incident triage: When an incident affects both financial and non-financial services, the compliance team must conduct parallel assessments against DORA's seven criteria (Art. 18) and NIS2's significance threshold (Art. 23(3)), then route reports to different authorities within different timelines. Building this dual-track triage into a single incident management workflow requires deliberate process design.

Testing programs: DORA Art. 24-27 mandates a comprehensive digital operational resilience testing programme including advanced threat-led penetration testing (TLPT) for significant institutions. NIS2 Art. 21(2)(e) requires regular testing but with less prescriptive requirements. Financial entities should design testing programs that satisfy both sets of requirements, using DORA's more demanding standard as the baseline.

Mapping Key Requirements

Practical Guidance for Compliance Teams

For compliance officers navigating this dual landscape, the following approach minimizes duplication and maximizes coverage:

Step 1: Entity scoping. Determine which of your legal entities and business lines fall under DORA, which fall under NIS2, and which fall under both. Use the entity classification in DORA Art. 2 and the essential/important entity designation in NIS2 Annex I-II.

Step 2: Requirement mapping. For each entity, map applicable requirements from both regulations. Where DORA provides equivalent or superior coverage, document the lex specialis analysis — supervisors will expect to see this documented, not just assumed.

Step 3: Unified governance framework. Establish a single governance framework that satisfies both sets of board-level obligations. DORA Art. 5 is more prescriptive than NIS2 Art. 20, so building to DORA's standard will generally satisfy both.

Step 4: Integrated incident management. Build a single incident management process with dual-track classification and routing. The workflow should classify against both DORA Art. 18 criteria and NIS2 significance thresholds, then route reports to the appropriate authorities within the tighter DORA timelines.

Step 5: Consolidated testing program. Design a resilience testing programme that meets DORA Art. 24-27 requirements (including TLPT where applicable). This program will inherently satisfy NIS2 Art. 21(2)(e) testing obligations.

Step 6: Gap identification. Identify areas where NIS2 imposes obligations that DORA does not cover — particularly non-ICT supply chain security and CSIRT cooperation — and ensure dedicated processes exist for those areas.

Institutions managing this dual-regulation challenge with spreadsheets and email chains are building compliance debt that compounds with every audit cycle. Purpose-built operational resilience platforms like Valendir that natively model both DORA's five pillars and cross-regulatory mapping provide the structural foundation needed for sustained, demonstrable compliance across both frameworks.

The Strategic Perspective

DORA and NIS2 are not competing regulations — they are complementary layers of the EU's digital resilience architecture. DORA provides the deep, prescriptive, sector-specific framework that financial entities need. NIS2 provides the broad, cross-sector baseline that catches what sector-specific legislation misses.

For compliance officers, the practical implication is clear: build to DORA's standard for all ICT and operational resilience obligations, then identify and address the NIS2 gaps that DORA does not cover. This approach minimizes compliance cost, maximizes regulatory coverage, and produces a unified evidence base that satisfies both sets of supervisors.

The institutions that treat these regulations as a single compliance challenge — rather than two separate projects — will find that the overlap works in their favor. The institutions that maintain separate tracks for each will discover, painfully, that duplication is the most expensive form of non-compliance.

---

This analysis reflects the regulatory landscape as of Q1 2026. Readers should consult applicable national transposition measures and supervisory guidance for jurisdiction-specific requirements.

---