NIS2 vs DORA — Overlap Analysis for Dual-Regulated Entities

by

Context: The Dual-Regulation Challenge

Since January 2025, many financial sector entities across the European Union find themselves subject to two major pieces of cybersecurity legislation simultaneously: the NIS2 Directive (Directive 2022/2555) and the Digital Operational Resilience Act (Regulation 2022/2554, known as DORA). This dual-regulation scenario creates legitimate questions about overlapping requirements, potential conflicts, and how to build a compliance programme that satisfies both frameworks efficiently.

This analysis is written for compliance officers, auditors, and risk managers who need to understand where these frameworks converge, where they diverge, and how to avoid both duplication of effort and compliance gaps.

The Lex Specialis Principle: Article 4 of NIS2

Article 4 of the NIS2 Directive establishes a critical legal principle: where a sector-specific Union legal act requires essential or important entities to adopt cybersecurity risk management measures or to notify significant incidents, and where those requirements are at least equivalent in effect to the obligations in NIS2, then the sector-specific act prevails.

DORA is explicitly recognised as such a sector-specific act for the financial sector. In practical terms, this means:

  • For areas where DORA provides equivalent or stronger requirements, DORA takes precedence for financial entities.
  • For areas where NIS2 covers matters not addressed by DORA, NIS2 obligations still apply.
  • The lex specialis principle does not create a blanket exemption from NIS2 — it creates a hierarchy that must be assessed requirement by requirement.

This nuance is frequently misunderstood. Compliance officers must conduct a requirement-level mapping, not assume that DORA compliance automatically satisfies all NIS2 obligations.

Comprehensive Comparison: NIS2 vs DORA Requirements

The following table provides a detailed mapping of key requirement areas across both frameworks, identifying overlaps, gaps, and which framework takes precedence for financial entities.

Requirement Area NIS2 Requirement DORA Equivalent Overlap / Gap Analysis
Risk Management Art. 21(1): Appropriate and proportionate technical, operational, and organisational measures based on all-hazards approach Art. 6-16: Detailed ICT risk management framework with specific requirements for identification, protection, detection, response, recovery, and learning DORA prevails. DORA is significantly more prescriptive on ICT risk management. Financial entities should use DORA’s framework as the primary compliance basis.
Incident Reporting Art. 23: Early warning within 24 hours, incident notification within 72 hours, final report within one month Art. 19: Initial notification, intermediate reports, and final report to competent authority. Specific classification criteria for major ICT-related incidents. DORA prevails for ICT incidents. Reporting timelines and classification criteria differ. NIS2 may still apply for non-ICT security incidents affecting network and information systems.
Supply Chain Security Art. 21(2)(d): Supply chain security including security-related aspects of relationships between entities and their direct suppliers or service providers Art. 28-44: Extensive ICT third-party risk management framework, including contractual requirements, oversight of critical ICT third-party providers, and concentration risk DORA goes significantly further. DORA creates a supervisory framework for critical ICT third-party providers that has no equivalent in NIS2. Financial entities benefit from DORA’s more detailed supply chain requirements.
Testing Art. 21(2)(f): Policies and procedures to assess the effectiveness of cybersecurity risk-management measures Art. 24-27: Digital operational resilience testing including threat-led penetration testing (TLPT) for significant entities, proportionate testing for others DORA goes further. DORA mandates specific testing methodologies including TLPT (based on TIBER-EU framework). NIS2 is less prescriptive on testing approaches.
Governance Art. 20: Management bodies must approve cybersecurity risk-management measures, oversee implementation, and can be held liable. Members must follow training. Art. 5: Management body has ultimate responsibility for ICT risk management. Must define, approve, and oversee implementation of ICT risk management framework and digital operational resilience strategy. Substantial overlap. Both require management body accountability. DORA is more specific about the ICT risk management framework the management body must approve. Compliance with DORA Article 5 should substantially satisfy NIS2 Article 20 for ICT matters.
Information Sharing Art. 29: Voluntary cyber threat intelligence sharing arrangements between essential and important entities Art. 45: Voluntary exchange of cyber threat information and intelligence among financial entities, including indicators of compromise, tactics, and alerts Parallel provisions. Both encourage voluntary information sharing. DORA is sector-specific. Financial entities may participate in both general (NIS2) and financial sector (DORA) sharing arrangements.
Business Continuity Art. 21(2)(c): Business continuity, including backup management, disaster recovery, and crisis management Art. 11-12: ICT business continuity policy, ICT response and recovery plans, backup policies, restoration and recovery procedures DORA prevails. DORA provides more detailed requirements for ICT continuity and recovery. NIS2 requirements for broader (non-ICT) business continuity may still apply.
Vulnerability Handling Art. 21(2)(e): Vulnerability handling and disclosure Art. 7-8 (within risk management): Identification and assessment of ICT vulnerabilities as part of the protection and prevention framework NIS2 is broader. NIS2 explicitly addresses coordinated vulnerability disclosure. DORA addresses vulnerability management within the ICT risk management framework but does not address public disclosure processes as directly.
Cryptography and Encryption Art. 21(2)(h): Policies and procedures regarding the use of cryptography and, where appropriate, encryption Art. 9(4)(d): Data security measures including cryptographic techniques as part of ICT risk management Comparable scope. Both require appropriate cryptographic controls. DORA embeds this within the broader ICT risk management framework. NIS2 calls it out as a distinct requirement area.
Access Control and Authentication Art. 21(2)(i-j): Access control policies; use of multi-factor authentication or continuous authentication solutions Art. 9(4)(c): Access control policies including strong authentication mechanisms Comparable scope. Both require robust access controls and strong authentication. DORA is less specific about MFA but requires strong authentication within the risk-based framework.

Where NIS2 Goes Beyond DORA

Compliance officers should pay particular attention to areas where NIS2 obligations may not be fully covered by DORA compliance:

  • Broader scope of network and information systems: NIS2 applies to all network and information systems used in the provision of services, not only ICT systems in the DORA sense. Operational technology (OT) systems, physical security systems with network connectivity, and building management systems may fall under NIS2 but outside DORA’s ICT focus.
  • Coordinated vulnerability disclosure: NIS2 specifically addresses vulnerability disclosure processes. Financial entities that discover vulnerabilities in widely used software may have obligations under NIS2 that DORA does not address.
  • Supply chain beyond ICT: NIS2 Article 21(2)(d) covers supply chain security broadly, including non-ICT suppliers whose services affect network and information system security. DORA focuses specifically on ICT third-party service providers.
  • Member State cooperation mechanisms: NIS2 establishes CSIRTs, the Cooperation Group, and EU-CyCLONe for cross-border cooperation. Financial entities may need to engage with these mechanisms for non-financial sector aspects of their operations.

Where DORA Goes Beyond NIS2

DORA provides significantly more detailed requirements in several areas:

  • ICT third-party risk management: DORA Articles 28-44 create a comprehensive framework for managing ICT third-party risk, including mandatory contractual provisions (Article 30), concentration risk assessment, and a supervisory framework for critical ICT third-party providers (Articles 31-44) with direct oversight by European Supervisory Authorities. NIS2 has nothing comparable.
  • Digital operational resilience testing: DORA mandates threat-led penetration testing (TLPT) for significant financial entities, with specific requirements for test scope, methodology, and reporting. NIS2 requires effectiveness testing but is far less prescriptive.
  • ICT incident classification: DORA provides detailed criteria for classifying major ICT-related incidents, including cross-border impact thresholds. NIS2’s incident classification is more general.
  • Digital operational resilience strategy: DORA requires a formal digital operational resilience strategy approved by the management body, with specific content requirements. NIS2 does not mandate a comparable strategy document.

Practical Recommendations for Dual-Regulated Entities

Based on the overlap analysis above, compliance officers at dual-regulated entities should consider the following approach:

1. Build on DORA as the Primary Framework

Since DORA is more prescriptive for most ICT-related requirements, use DORA compliance as your foundation. Map NIS2 requirements against your DORA compliance programme to identify gaps rather than building two separate programmes.

2. Conduct a Formal Gap Analysis

Document a requirement-by-requirement mapping between NIS2 and DORA for your organisation. Identify where DORA compliance satisfies NIS2 (leveraging the lex specialis principle), where NIS2 adds requirements beyond DORA, and where the two frameworks require different evidence or documentation.

3. Address NIS2-Specific Gaps

For areas where NIS2 goes beyond DORA, implement additional controls and documentation. Key areas likely to require supplementary measures include non-ICT supply chain security, broader network and information system scope, and vulnerability disclosure processes.

4. Harmonise Reporting Processes

Incident reporting obligations differ between the frameworks in terms of timelines, authorities, and classification criteria. Establish a single incident management process that can satisfy both sets of reporting requirements, with clear decision trees for which authority to notify and when.

5. Maintain a Single Risk Register

Do not maintain separate risk registers for NIS2 and DORA. Use one integrated ICT and cyber risk register that tags risks by applicable regulation. This avoids duplication and ensures consistent risk treatment.

What Auditors Should Verify for Dual Compliance

Auditors assessing dual-regulated entities should examine:

  • Mapping documentation: Has the entity produced a formal NIS2-to-DORA mapping that identifies which framework applies to each requirement area?
  • Gap analysis: Is there evidence of a structured gap analysis identifying where NIS2 obligations are not covered by DORA compliance?
  • Lex specialis justification: Where the entity relies on the lex specialis principle, is the justification documented and defensible for each requirement?
  • Scope assessment: Has the entity assessed whether any of its network and information systems fall outside DORA’s ICT scope but within NIS2’s broader scope?
  • Incident reporting procedures: Does the entity have clear procedures for determining which reporting obligations apply to different types of incidents?
  • Governance structure: Does the management body receive reporting that covers both NIS2 and DORA obligations, or are there governance blind spots?
  • Evidence of supplementary controls: For NIS2-specific requirements not covered by DORA, are controls in place and evidenced?

Related Resources

For further analysis of regulatory overlap and compliance architecture, see:

Related for Auditors

New to CI/CD auditing? Start with our Auditor’s Guide.