DORA and NIS2: running one compliance programme when both apply

The short answer

A financial entity can be regulated under both DORA and NIS2 simultaneously — DORA as a financial entity under Regulation (EU) 2022/2554, and NIS2 as an essential entity in the banking or financial market infrastructure sector under Directive (EU) 2022/2555. When both apply, **DORA takes precedence as lex specialis** for ICT risk management (DORA Article 4), but NIS2 obligations do not disappear entirely — governance, incident classification thresholds, and certain supply chain requirements still require reconciliation between the two frameworks.

Who is dual-regulated

You are likely subject to both DORA and NIS2 if you are:

→ DORA Applicability Checker · NIS2 Applicability Checker

• A credit institution, investment firm, or payment institution (DORA financial entity + NIS2 Annex I "banking" or "financial market infrastructure" sector)
• A central securities depository or central counterparty (DORA + NIS2 Annex I)
• An insurance or reinsurance undertaking above the NIS2 size threshold operating critical infrastructure
• An ICT third-party service provider designated as critical (CTPP) under DORA, where the same entity also qualifies as a NIS2 "digital infrastructure" or "ICT service management" provider

DORA precedence — what "lex specialis" means in practice

DORA Article 4(1) states that where NIS2 provisions on ICT risk management, incident reporting, or resilience testing would apply to a financial entity also covered by DORA, **DORA provisions apply instead** for those specific areas. Recital 16 confirms this is to avoid duplicative or conflicting requirements.

**What DORA precedence covers:** - ICT risk management framework (DORA Art. 6 replaces NIS2 Art. 21 risk management measures for in-scope entities) - ICT-related incident reporting (DORA Art. 19 replaces NIS2 Art. 23 incident reporting) - Digital operational resilience testing (DORA Art. 24-27, including TLPT) - ICT third-party risk management (DORA Art. 28-30)

**What DORA precedence does NOT cover:** - NIS2 registration and supervisory cooperation obligations that apply at Member State level regardless of DORA status - NIS2 governance obligations for activities outside the ICT risk scope (e.g., physical security measures not captured by DORA) - National transposition provisions that extend NIS2 scope beyond the DORA carve-out

**Practical implication:** for the ICT/cyber risk core, build your programme to DORA's stricter requirements. Do not build two parallel risk management frameworks — one DORA-compliant framework, correctly scoped, satisfies the overlapping NIS2 obligations by operation of law.

Incident reporting: the timeline gap that catches teams out

This is the single most common compliance gap for dual-regulated entities, because the two frameworks specify different clocks:

**The gap:** DORA's 4-hour initial notification is stricter than NIS2's 24-hour window. Since DORA governs ICT incident reporting for dual-regulated entities, your operational clock must be built to the 4-hour standard — waiting until the NIS2 24-hour mark will breach DORA.

**Classification thresholds also differ.** An event might cross the DORA "major incident" threshold (based on DORA's quantitative criteria: client/counterpart impact, duration, geographic spread, economic impact, reputational impact, data losses, criticality of affected services) without necessarily meeting NIS2's "significant incident" bar, or vice versa. Your incident triage process needs **both classification checklists running in parallel** on every event, not a single unified threshold.

Building one incident response workflow, not two

1. **Single incident intake and triage** — one process captures the event, then runs it against both DORA and NIS2 classification criteria simultaneously. 2. **4-hour clock as the default trigger** — build your escalation and drafting process to the DORA timeline; a NIS2-only incident (rare for DORA-scope entities, but possible for obligations DORA doesn't cover) still has 24 hours, so the stricter clock never causes a miss. 3. **Two notification templates, one data set** — the underlying incident data (what happened, when, impact, remediation) is the same; only the recipient-specific report format differs (competent authority template vs. national CSIRT template). 4. **One post-incident review, two closure records** — DORA's 30-day final report and NIS2's 1-month final report should be drafted from the same root cause analysis, submitted to each recipient in their required format.

TLPT and NIS2 advanced testing

DORA Article 26 requires Threat-Led Penetration Testing (TLPT) for significant financial entities, at minimum every 3 years, using the TIBER-EU framework. NIS2 Article 21(2)(f) requires "policies and procedures to assess the effectiveness of cybersecurity risk management measures" — a broader, less prescriptive testing obligation.

**A completed TLPT exercise satisfies both.** A DORA-compliant TLPT report, covering critical functions and produced under TIBER-EU, is sufficient evidence for the NIS2 effectiveness-assessment obligation — there is no need for a separate NIS2-specific penetration test.

→ DORA TLPT guide — full TIBER-EU breakdown

ICT third-party risk — where NIS2 supply chain rules still bite

DORA Articles 28-30 govern ICT third-party risk comprehensively for financial entities — contractual requirements, exit strategies, audit rights, and the Critical ICT Third-Party Service Provider (CTPP) oversight regime.

NIS2 Article 21(2)(d) requires supply chain security assessment more broadly, including for non-ICT suppliers where relevant to service continuity. For a dual-regulated financial entity, **DORA's third-party regime satisfies the ICT-supplier dimension of NIS2 Article 21(2)(d)**, but if you have non-ICT critical suppliers (e.g., a physical facilities provider critical to service continuity) that fall outside DORA's ICT-third-party definition, NIS2's broader supply chain obligation still applies to them independently.

Governance — two boards, one framework

DORA Article 5 and NIS2 Article 20 both place cybersecurity/ICT risk governance accountability on the management body, with near-identical language on approval and oversight responsibility. In practice:

• One board-approved ICT/cyber risk framework document, explicitly citing both DORA Article 5/6 and NIS2 Article 20/21 as its legal basis, satisfies both governance obligations
• Management training requirements under NIS2 Article 20(2) should be folded into your existing DORA-driven board cybersecurity briefings — do not run separate training tracks

Common mistakes for DORA + NIS2 dual-regulated entities

**1. Building the incident response clock to NIS2's 24 hours.** DORA's 4-hour trigger is the binding constraint. Teams that build to NIS2 timelines first (because NIS2 has been in force longer) discover the DORA breach only after an incident.

**2. Running two separate risk assessments.** DORA precedence means one ICT risk management framework — built to DORA's more detailed Article 6 requirements — covers the overlapping NIS2 ground. Two parallel frameworks create version drift and audit inconsistency.

**3. Assuming DORA precedence eliminates NIS2 entirely.** It does not. Registration obligations, non-ICT supply chain requirements, and any Member State NIS2 transposition gaps remain live. Confirm your national transposition text — some Member States retain broader NIS2 scope than the DORA carve-out anticipates.

**4. Missing the TLPT-to-NIS2 evidence link.** Entities complete DORA TLPT and treat it as a DORA-only artefact, missing the opportunity to close the NIS2 Article 21(2)(f) effectiveness-testing obligation with the same evidence.

Tools on NexCyber

• DORA Applicability Checker — confirm DORA scope in 2 minutes
• NIS2 Applicability Checker — confirm NIS2 essential/important entity status
• 144-obligation gap assessment — maps DORA + NIS2 + CRA + AI Act + RED in one assessment, with DORA-precedence logic built into the obligation engine

Further reading

*This page provides regulatory guidance for informational purposes. It is not legal advice. DORA and NIS2 interaction is subject to ESA guidance and national transposition — for compliance decisions on the DORA/NIS2 boundary, consult your competent authority or a qualified legal adviser.*

*NexCyber — EU Market Access Compliance Platform*

• DORA TLPT — threat-led penetration testing
• NIS2 implementation guide — 8 steps
• NIS2 × CRA overlap — shared evidence strategy