DORA and NIS2: Double Compliance for Financial Firms
By ArvexLab Team — Compliance Research
Two Regulations, One Compliance Budget
If you work in compliance at a European bank, insurance company, or investment firm, you are navigating a regulatory landscape that has never been more demanding. Since January 2025, the Digital Operational Resilience Act (DORA) has been directly applicable across all EU member states. Simultaneously, the NIS2 Directive — transposed into national law throughout 2024 and 2025 — applies to financial entities as part of its 18-sector scope.
The result is dual compliance: two distinct regulatory frameworks, each with their own requirements, supervisory authorities, and reporting obligations, applying to the same organisation at the same time.
Deloitte's 2025 DORA Readiness Survey found that 46% of financial institutions cited return on investment as the most challenging aspect of DORA implementation — not the technical requirements, but justifying the cost of compliance programmes that overlap substantially with existing obligations. When you add NIS2 to the equation, the duplication becomes even more acute.
This guide maps exactly where DORA and NIS2 overlap, where they diverge, how the lex specialis principle operates in practice, and how to build a unified compliance programme that satisfies both without doubling your effort.
The Lex Specialis Principle: How DORA and NIS2 Interact
The relationship between DORA and NIS2 is governed by the lex specialis principle — the principle that a specific law prevails over a general one when both apply to the same subject matter.
NIS2 Recital 28 explicitly addresses this:
> *This Directive should be considered lex generalis in relation to Directive (EU) 2022/2554 [DORA] with regard to financial entities... the provisions of [DORA] relating to ICT risk management, ICT-related incident reporting and in particular digital operational resilience testing, information-sharing and ICT third-party risk management should apply instead of those set out in this Directive.*
In practical terms:
- Where DORA has equivalent or stricter requirements (ICT risk management, incident reporting, testing, third-party risk), DORA prevails and the organisation follows DORA's rules.
- Where NIS2 has requirements that DORA does not cover (management body training obligations, broader supply chain security beyond ICT, coordination with national CSIRTs), NIS2 applies in addition to DORA.
- Where both address the same topic with different specifics, DORA takes precedence as the sector-specific regulation.
This does not mean NIS2 is irrelevant for financial entities. It means DORA is the primary obligation for most cybersecurity requirements, with NIS2 filling gaps in areas DORA does not address.
Detailed Requirement Mapping
The following table maps each major compliance domain across both regulations, indicating which takes precedence and where incremental NIS2 work is required.
ICT Risk Management
| Requirement | DORA (Art. 5–16) | NIS2 (Art. 21) | Which Applies? |
|---|---|---|---|
| Risk management framework | Detailed ICT risk management framework with identification, protection, detection, response, recovery | 10 security measures covering risk analysis, incident handling, BCP, supply chain, etc. | DORA (more specific and detailed) |
| Risk tolerance and appetite | Must be defined and approved by management body | Implied through proportionality principle | DORA (explicit requirement) |
| Asset management | ICT asset register required with classification and dependency mapping | "Security in network and information systems acquisition" | DORA (more prescriptive) |
| Encryption and cryptography | Specific requirements within ICT security policies | Art. 21(2)(h) — cryptography and encryption policies | DORA (embedded in broader ICT security framework) |
| Access control | Detailed within ICT security measures | Art. 21(2)(i) — HR security, access control, asset management | DORA (integrated with ICT risk management) |
| MFA and secure comms | Required for ICT systems | Art. 21(2)(j) — multi-factor authentication | Overlap — DORA's ICT-specific requirements satisfy NIS2 |
Incident Reporting
| Aspect | DORA (Art. 19) | NIS2 (Art. 23) | Which Applies? |
|---|---|---|---|
| Initial notification | 4 hours (major ICT incidents) | 24 hours (early warning to CSIRT) | DORA (stricter timeline) |
| Detailed report | 72 hours | 72 hours | Same |
| Final report | 1 month | 1 month | Same |
| Reporting authority | Competent financial authority (e.g., BaFin, Banca d'Italia, ACPR) | National CSIRT | Both — may need to report to different authorities |
| Scope | Major ICT-related incidents | Significant incidents affecting service delivery | DORA (for ICT incidents); NIS2 (may apply for non-ICT incidents) |
Critical note: Financial entities must report major ICT incidents to their financial supervisor under DORA. However, if the incident also qualifies as a "significant incident" under NIS2, the national CSIRT may also need to be notified. Member state transposition determines whether dual reporting is required or whether supervisors share information between themselves.
Digital Operational Resilience Testing
| Aspect | DORA (Art. 24–27) | NIS2 (Art. 21(2)(f)) | Which Applies? |
|---|---|---|---|
| General testing | Comprehensive testing programme including vulnerability scans, network security, gap analysis, source code review | "Policies and procedures to assess the effectiveness of cybersecurity risk-management measures" | DORA (far more prescriptive) |
| TLPT | Threat-led penetration testing every 3 years for significant entities, based on TIBER-EU framework | Not required | DORA (unique requirement) |
| Scope of testing | All critical ICT systems and applications | General effectiveness assessment | DORA (more comprehensive) |
Third-Party Risk Management
| Aspect | DORA (Art. 28–30) | NIS2 (Art. 21(2)(d)) | Which Applies? |
|---|---|---|---|
| ICT third-party risk framework | Detailed framework: register of arrangements, risk assessment, exit strategies, concentration risk | "Supply chain security including security-related aspects concerning the relationships between each entity and its direct suppliers" | DORA (significantly more detailed for ICT providers) |
| ESA information register | Mandatory register of all ICT third-party arrangements, submitted to regulators in standardised format | Not required | DORA (unique requirement) |
| Concentration risk | Must assess and mitigate ICT concentration risk | Implied but not explicit | DORA (explicit requirement) |
| Critical ICT providers | ESAs designate and directly oversee critical ICT third-party service providers | Not applicable | DORA (unique oversight framework) |
| Non-ICT supply chain | Not covered | Covered — broader supply chain beyond ICT | NIS2 (applies where DORA does not cover non-ICT suppliers) |
Governance and Management Body Responsibilities
| Aspect | DORA (Art. 5) | NIS2 (Art. 20) | Which Applies? |
|---|---|---|---|
| Framework approval | Management body approves ICT risk management framework | Management body approves cybersecurity risk-management measures | Both — complementary obligations |
| Oversight | Active oversight of ICT risk | Active oversight of all Article 21 measures | Both |
| Training | Management body must maintain sufficient ICT knowledge and skills | Management body members must undergo cybersecurity training | NIS2 — NIS2's training mandate is explicit and enforceable; DORA's knowledge requirement is broader but less prescriptive on training specifically |
| Personal liability | Implied through financial regulation frameworks | Explicit — Article 20(1) states management bodies "can be held liable for infringements" | NIS2 — explicit personal liability with Article 32(5)(b) management bans |
| Budget allocation | Must allocate sufficient budget for ICT risk management | Implied through adequacy of measures | DORA (more explicit on ICT-specific budget) |
The Gaps: Where NIS2 Adds Requirements Beyond DORA
For financial entities, DORA covers most cybersecurity obligations. But NIS2 introduces specific requirements that DORA does not fully address:
1. Management Body Training (Article 20(2))
DORA Article 5(4) requires management bodies to "actively keep up to date with sufficient knowledge and skills to understand and assess ICT risk." NIS2 Article 20(2) goes further: members of management bodies "are required to follow training."
The distinction is meaningful for auditors. Under DORA, a board that can demonstrate ICT knowledge may satisfy the requirement. Under NIS2, documented training records are expected — who attended, what was covered, when, and how frequently.
Action: Implement a formal board cybersecurity training programme with documented records. Annual training covering the organisation's risk landscape, NIS2/DORA obligations, and emerging threats.
2. Non-ICT Supply Chain Security
DORA's third-party risk framework is comprehensive but limited to ICT third-party service providers. NIS2's supply chain requirement (Art. 21(2)(d)) covers all suppliers, including non-ICT providers who may have access to facilities, data, or operational processes.
Action: Extend your vendor risk management programme beyond ICT providers to cover facility management, physical security, consulting firms with data access, and any non-ICT supplier with a material impact on your operational security.
3. CSIRT Coordination
Under DORA, financial entities report incidents to their financial competent authority. Under NIS2, entities must also coordinate with the national CSIRT (Computer Security Incident Response Team). Some member states have streamlined this into a single reporting channel; others require separate notifications.
Action: Map the reporting requirements in each jurisdiction where you operate. Establish templates and workflows for both financial authority and CSIRT notification.
4. Cross-Border Cooperation
NIS2's cooperation framework (Articles 14–15, the Cooperation Group and CSIRTs Network) creates information-sharing obligations that operate differently from DORA's financial supervisory cooperation. Financial entities in multiple member states may need to engage with NIS2's cooperation mechanisms in addition to DORA's.
Action: Identify your NIS2 competent authority and CSIRT in each member state of operation. Ensure your incident response procedures include NIS2-specific coordination steps.
Evidence Reuse Strategy: Doing the Work Once
The most expensive mistake in dual compliance is doing the same work twice. A well-structured evidence management approach can reduce the marginal cost of NIS2 compliance for DORA-compliant organisations to 15–25% of what a standalone NIS2 programme would cost.
Framework-Agnostic Evidence Repository
Structure your evidence around controls, not regulations. A control — such as "multi-factor authentication for privileged access" — satisfies requirements in both DORA (ICT security measures) and NIS2 (Art. 21(2)(j)), as well as ISO 27001 (A.8.5) and GDPR (Art. 32).
| Control Domain | Evidence Item | DORA Reference | NIS2 Reference | ISO 27001 Reference |
|---|---|---|---|---|
| Access control | MFA configuration evidence, access review logs | Art. 9(4)(c) | Art. 21(2)(j) | A.8.5 |
| Incident response | IR plan, tabletop exercise records, incident logs | Art. 17 | Art. 21(2)(b) | A.5.24–5.28 |
| Risk assessment | Risk register, assessment methodology, treatment plans | Art. 6–8 | Art. 21(2)(a) | A.5.2, 8.2–8.3 |
| BCP/DR | Business continuity plan, DR test results, RTO/RPO metrics | Art. 11–12 | Art. 21(2)(c) | A.5.29–5.30 |
| Vendor management | ICT third-party register, risk assessments, contracts | Art. 28–30 | Art. 21(2)(d) | A.5.19–5.22 |
| Encryption | Encryption policy, key management procedures, certificate inventory | Art. 9(4)(d) | Art. 21(2)(h) | A.8.24 |
| Training | Training records, awareness programme, completion rates | Art. 5(4) | Art. 20(2) | A.6.3 |
Cross-Mapping Methodology
- Start with DORA. DORA's requirements are more granular and prescriptive. If you build your evidence base to satisfy DORA, the majority of NIS2 requirements are already covered.
- Identify NIS2 deltas. Using the gap analysis in the previous section, identify the specific areas where NIS2 adds requirements beyond DORA (management training records, non-ICT supply chain, CSIRT coordination).
- Tag evidence to multiple frameworks. Every evidence item should carry metadata indicating which framework requirements it satisfies. This enables single-click generation of framework-specific evidence packs for different auditors.
- Automate cross-framework scoring. Platforms with multi-framework support (such as ArvexLab) can automatically calculate compliance scores against both DORA and NIS2 from the same evidence base, showing exactly where you are compliant with one and not the other.
Dual-Compliance Checklist for Financial Institutions
DORA-Primary Requirements (These Also Satisfy NIS2)
- [ ] ICT risk management framework approved by management body
- [ ] ICT asset register maintained with classification and dependencies
- [ ] Incident classification and reporting process aligned with Art. 19 timelines (4h/72h/1m)
- [ ] ICT third-party register submitted to competent authority
- [ ] Concentration risk assessed for critical ICT providers
- [ ] TLPT programme in place (for significant entities)
- [ ] Digital operational resilience testing programme covering all critical systems
- [ ] Exit strategies documented for critical ICT third-party service providers
- [ ] Business continuity and disaster recovery plans tested annually
- [ ] Information-sharing arrangements in place (Art. 45)
NIS2-Incremental Requirements (Beyond DORA)
- [ ] Board members have completed documented cybersecurity training (Art. 20(2))
- [ ] Training records maintained with content, dates, and attendance
- [ ] Non-ICT suppliers assessed for security risk (Art. 21(2)(d) broader scope)
- [ ] National CSIRT identified and incident reporting procedure established (Art. 23)
- [ ] Dual reporting workflow in place (financial authority + CSIRT where required)
- [ ] Management body personal liability acknowledged and D&O coverage reviewed
- [ ] NIS2-specific entity registration completed with national competent authority
- [ ] Cross-border NIS2 cooperation requirements mapped (if operating in multiple member states)
Unified Evidence Management
- [ ] Evidence repository organised by control domain (not by regulation)
- [ ] Each evidence item tagged to all applicable framework requirements
- [ ] Automated cross-framework compliance scoring operational
- [ ] Framework-specific evidence packs generatable for DORA and NIS2 audits
- [ ] Evidence refresh schedules defined (aligned with the stricter of DORA/NIS2 requirements)
Timeline and Prioritisation
For financial institutions that are already on their DORA compliance journey, the NIS2 incremental work can be completed in parallel without a separate programme.
| Priority | Action | Effort | Timeline |
|---|---|---|---|
| 1 | Complete NIS2 entity registration (if not already done) | Low | Immediate |
| 2 | Map CSIRT reporting requirements in all jurisdictions | Low-Medium | 2 weeks |
| 3 | Implement board cybersecurity training programme | Medium | 4–6 weeks |
| 4 | Extend vendor risk programme to non-ICT suppliers | Medium-High | 6–10 weeks |
| 5 | Establish dual incident reporting workflows | Medium | 4–6 weeks |
| 6 | Cross-tag existing DORA evidence to NIS2 requirements | Medium | 4–8 weeks |
| 7 | Generate NIS2-specific evidence packs for audit readiness | Low-Medium | 2–4 weeks |
Supervisory Expectations: What Regulators Will Ask
Financial supervisors (ECB/SSM, BaFin, Banca d'Italia, AMF, etc.) will examine DORA compliance. But NIS2 competent authorities — often different bodies — may also request evidence from financial entities.
Expect questions like:
- "Show us your board training records for the past 12 months" (NIS2 Art. 20)
- "How do you manage non-ICT supply chain risk?" (NIS2 Art. 21(2)(d))
- "Demonstrate your CSIRT notification procedure" (NIS2 Art. 23)
- "Provide evidence that your management body has approved the cybersecurity risk-management measures" (NIS2 Art. 20 — distinct from DORA's ICT risk management approval)
The worst outcome is being caught between two supervisors, each expecting compliance with their regulation, and discovering that your DORA programme — however comprehensive — left NIS2-specific gaps unaddressed.
Conclusion
Dual compliance with DORA and NIS2 is not double the work if approached correctly. The lex specialis principle means DORA does the heavy lifting for ICT-related requirements. The incremental NIS2 obligations — board training, non-ICT supply chain, CSIRT coordination — are manageable additions, not a separate programme.
The key is unified evidence management. Build once, tag to many frameworks, and generate regulation-specific outputs as needed. Financial institutions that adopt this approach will not only reduce their compliance cost but will be better prepared for the next regulatory wave — because in the EU, DORA and NIS2 are not the end of the story. They are the foundation.
Sources and References
- DORA Regulation — Full Text (EUR-Lex)
- NIS2 Directive — Recital 28 and Article 4: Lex Specialis (EUR-Lex)
- Deloitte — DORA Readiness Survey 2025
- ECSO — NIS2 Transposition Tracker (2026)
- EIOPA — DORA Overview and Implementation Guidance
- DORA Article 28 — ICT Third-Party Risk (EUR-Lex)
- EBA — DORA Regulatory Technical Standards (2024)
- DLA Piper — DORA and NIS2 Interaction for Financial Entities (2025)
Ready to assess your NIS2 readiness?
Use our free self-assessment tool or speak with our compliance team.