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.
Architecture Comparison: How the Two Regimes Shape CI/CD
The requirement-level mapping above shows where the two regimes overlap and diverge on paper. It is just as important to understand how those objectives translate into architecture — the way governance, CI/CD pipelines, evidence, and operational controls are actually structured under each framework. The comparison below examines NIS2 and DORA through that architectural lens, which is where dual-regulated entities most often discover practical differences.
Regulatory Scope and Intent
NIS2: Broad Cybersecurity Baseline
NIS2 establishes a horizontal cybersecurity baseline across a wide range of essential and important entities, including public sector organizations, energy, transport, healthcare, digital infrastructure, and large enterprises.
Architectural implication:
- focus on risk management and preparedness
- flexibility in technical implementation
- emphasis on proportionality
NIS2 asks:
“Are cybersecurity risks identified, managed, and addressed across the organization?”
DORA: Financial Sector Operational Resilience
DORA is a sector-specific regulation targeting financial entities and their ICT service providers. It focuses on operational resilience, ICT risk management, and supervisory oversight.
Architectural implication:
- CI/CD and ICT systems treated as regulated assets
- stronger enforcement and traceability expectations
- tighter supervisory scrutiny
DORA asks:
“Can you continuously demonstrate ICT risk control and resilience?”
Architectural Positioning of CI/CD Pipelines
NIS2 Architecture Perspective
Under NIS2, CI/CD pipelines are part of the secure development and supply chain ecosystem.
Architectural characteristics:
- CI/CD enforces secure SDLC practices
- dependency and supply chain risks addressed
- governance focuses on ownership and oversight
CI/CD pipelines support compliance but are not always explicitly classified as regulated systems.
DORA Architecture Perspective
Under DORA, CI/CD pipelines are treated as regulated ICT systems.
Architectural characteristics:
- CI/CD enforces change management and segregation of duties
- all production changes must flow through pipelines
- pipelines generate continuous audit evidence
CI/CD becomes a control enforcement layer, not just a delivery mechanism.
Governance and Risk Management Layer
NIS2 Governance Model
- cybersecurity risk management
- organizational and technical measures
- executive accountability
- supplier risk management
Architecture supports governance decisions, but technical enforcement may vary.
DORA Governance Model
- formal ICT risk management framework
- explicit inclusion of CI/CD in risk scope
- strict ownership and accountability
- strong linkage between governance and technical controls
Architecture ensures governance is enforced technically.
Evidence and Auditability
NIS2 Evidence Expectations
NIS2 requires organizations to demonstrate:
- risk assessments
- implemented security measures
- incident handling capability
Evidence may include:
- policies and procedures
- logs and monitoring records
- incident reports
Evidence is often contextual and proportional.
DORA Evidence Expectations
DORA requires:
- continuous, system-generated evidence
- traceability across the full ICT lifecycle
- reproducible audit trails
Evidence is expected to be:
- centralized
- retained
- demonstrable on demand
Architecture must support continuous compliance, not point-in-time audits.
Supply Chain and Third-Party Risk
NIS2 Supply Chain Architecture
- supplier governance and risk assessment
- proportional controls based on criticality
- focus on preparedness and coordination
CI/CD supports:
- dependency visibility
- supplier risk mitigation
DORA Supply Chain Architecture
- ICT third-party risk management integrated into ICT governance
- strong focus on critical ICT providers
- alignment with financial supervisory expectations
CI/CD supports:
- artifact integrity
- provenance
- controlled supplier access
Incident Response and Operational Resilience
NIS2 Architecture
- incident detection and response
- coordination with authorities
- focus on service continuity
Architecture supports preparedness and responsiveness.
DORA Architecture
- operational resilience as a core objective
- ICT incident management tightly integrated with governance
- testing and recovery capabilities emphasized
Architecture supports resilience by design.
Side-by-Side Architectural Comparison
| Dimension | NIS2 | DORA |
|---|---|---|
| Regulatory scope | Cross-sector | Financial sector |
| CI/CD role | Secure delivery support | Regulated ICT system |
| Governance enforcement | Organizational & technical | Strongly technical |
| Evidence model | Proportional, contextual | Continuous, system-based |
| Audit intensity | Moderate to high | Very high |
| Supply chain focus | Broad | ICT-critical providers |
| Operational resilience | Required | Core objective |
Practical Takeaways for Architects and CISOs
- NIS2 architectures prioritize risk management and preparedness
- DORA architectures prioritize continuous control and evidence
- CI/CD pipelines are supportive under NIS2, central under DORA
- Organizations subject to both must design DORA-grade architectures
A DORA-aligned architecture generally satisfies NIS2 expectations, but the reverse is not always true.
The architectural takeaway reinforces the requirement-level analysis: NIS2 and DORA share common principles but diverge sharply in rigour and enforcement. Where NIS2 treats the CI/CD pipeline as a system that supports secure delivery, DORA treats it as a regulated ICT asset that must generate continuous, demonstrable evidence. Architectures that build the pipeline as an enforcement and evidence-generating layer—rather than a delivery convenience—are best positioned to satisfy both frameworks with minimal duplication, which is precisely what the practical recommendations that follow are designed to achieve.
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
- Glossary — Plain-language definitions of technical terms
- DORA Article 21 Deep Dive
- DORA Article 28 Explained
- Audit Readiness Checklist
New to CI/CD auditing? Start with our Auditor’s Guide.
