DORA vs. NIS2: Which Applies to Your Organisation?
DORA vs NIS2: understand the lex specialis relationship, where they overlap, who falls under which, and how dual-regulated entities should approach training.
If your organisation operates in financial services within the European Union, you have almost certainly encountered both DORA and NIS2 in the past eighteen months. Both regulate cybersecurity. Both impose training obligations. Both carry significant penalties. And the relationship between them is not immediately obvious from reading the headlines.
The confusion is understandable. DORA (Regulation (EU) 2022/2554) has been enforceable since 17 January 2025. NIS2 (Directive (EU) 2022/2555) required transposition into national law by 17 October 2024, with enforcement timelines varying by member state. Both arrived in the same legislative package. Both address digital resilience. And for organisations in the financial sector, both appear to apply simultaneously.
They do not. Or more precisely, they do not apply in the way most compliance teams initially assume. The relationship between these two frameworks is governed by a legal principle called lex specialis, and understanding it is the single most important step toward building a training and compliance programme that satisfies both without duplicating effort.
The Lex Specialis Relationship
Lex specialis derogat legi generali — the specific law overrides the general law. This is the foundational principle governing how DORA and NIS2 interact.
NIS2 is the general framework. It applies across a wide range of sectors — energy, transport, health, digital infrastructure, public administration, and many others — establishing baseline cybersecurity risk-management and reporting obligations for essential and important entities across the EU.
DORA is the sector-specific framework. It applies exclusively to the financial sector and establishes more granular, more prescriptive requirements for digital operational resilience — including ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing.
Article 4 of DORA makes this hierarchy explicit. Where DORA addresses a matter also covered by NIS2, the DORA provisions take precedence for financial entities. NIS2 itself acknowledges this in Recital 28, which states that where sector-specific legislation requires financial entities to adopt ICT risk-management frameworks with equivalent or stronger requirements than NIS2, those sector-specific rules should apply.
In practice, this means that if your organisation is a financial entity within DORA's scope, DORA is your primary compliance framework for digital resilience. You do not need to separately comply with NIS2's cybersecurity risk-management provisions — DORA's requirements are deemed to meet or exceed them.
This is not a theoretical distinction. It has direct consequences for how you structure your compliance programme, how you report incidents, and how you design your training.
Who Falls Under Which Regulation
The scope question is where most of the practical confusion lives. Here is a simplified breakdown.
DORA applies to financial entities, defined broadly across 21 categories. These include credit institutions, investment firms, insurance and reinsurance undertakings, payment institutions, electronic money institutions, central securities depositories, trading venues, central counterparties, trade repositories, managers of alternative investment funds, UCITS management companies, crypto-asset service providers, and — importantly — ICT third-party service providers that serve the financial sector.
The scope is deliberately wide. If you hold a financial services licence or provide critical ICT services to entities that do, you are very likely in scope.
NIS2 applies to essential and important entities across sectors including energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, ICT service management, postal services, waste management, chemicals, food, manufacturing, digital providers, research organisations, and public administration. The thresholds are generally 50 or more employees, or EUR 10 million or more in annual turnover for important entities, with higher thresholds for essential entities.
The overlap exists primarily in two areas. First, credit institutions and financial market infrastructure operators are explicitly listed in NIS2's Annex I as essential entities. Second, ICT service providers that serve financial clients may fall under both DORA (as critical ICT third-party service providers) and NIS2 (as digital infrastructure or ICT service management providers).
For the first group — banks and market infrastructure — the lex specialis principle is clear. DORA governs. NIS2's general provisions do not add additional requirements where DORA already addresses the same subject matter.
For the second group — ICT service providers — the position is more nuanced, and we will return to it below.
Where They Overlap and Where They Diverge
Understanding the specific points of overlap and divergence helps you avoid both gaps and unnecessary duplication.
ICT risk management. Both frameworks require organisations to implement risk-management measures for their ICT systems. DORA's requirements (Articles 5-16) are substantially more detailed than NIS2's (Article 21). DORA specifies ICT risk-management frameworks, protection and prevention measures, detection capabilities, response and recovery processes, and backup policies at a granular level. For financial entities, DORA's framework satisfies and exceeds NIS2's risk-management expectations.
Incident reporting. Both require reporting of significant incidents, but the mechanisms differ. DORA requires financial entities to report major ICT-related incidents to their competent financial authority (such as the ECB, EBA, ESMA, or EIOPA) through a structured reporting process defined in Articles 17-23. NIS2 requires reporting to the relevant CSIRT or competent authority designated under national transposition. For financial entities, DORA's reporting obligations apply. You report through your financial supervisor, not through the NIS2 reporting channel.
Third-party risk management. This is where DORA goes significantly further than NIS2. Chapter V of DORA establishes an entire framework for managing ICT third-party risk, including contractual requirements, concentration risk assessment, and — for critical ICT third-party providers — an oversight framework led by a designated Lead Overseer from the European Supervisory Authorities. NIS2 addresses supply chain security in Article 21(2)(d), but at a much higher level of generality.
Resilience testing. DORA requires financial entities to conduct digital operational resilience testing (Articles 24-27), including threat-led penetration testing (TLPT) for significant entities. NIS2 has no equivalent requirement.
Training. Both impose training obligations, but with different emphases. This is the area most directly relevant to compliance teams building training programmes — and where the relationship requires the most careful navigation.
Training Requirements: A Side-by-Side Comparison
DORA's training requirements are embedded throughout the regulation rather than concentrated in a single article. Article 5(4) requires financial entities to ensure that their management body maintains "sufficient knowledge and skills to understand and assess ICT risk." Article 13(6) requires entities to develop ICT security awareness programmes and digital operational resilience training as part of their ICT risk-management framework. The training must be "compulsory" for all staff, "proportionate to their function," and extended to relevant third-party service providers.
NIS2's training requirement sits primarily in Article 20(2), which requires management body members to "follow training" sufficient to "identify risks and assess cybersecurity risk-management practices and their impact on the services provided by the entity." It also encourages — but does not mandate — similar training for employees generally.
Several differences are worth noting.
Scope of obligation. DORA mandates training for all staff, proportionate to role, plus relevant third parties. NIS2 mandates training for the management body and encourages it for broader staff. DORA's obligation is wider.
Specificity. DORA links training to a detailed ICT risk-management framework with specific operational components. NIS2 links training to a general competence standard around risk identification and assessment. DORA is more prescriptive about what training must cover.
Evidence standard. Neither regulation specifies a training format. But DORA's connection to the broader resilience testing framework — and the scrutiny of financial supervisors who are accustomed to examining operational processes in detail — means that the evidence bar for DORA training is likely to be higher in practice. Financial regulators have decades of experience examining whether compliance programmes are substantive or decorative.
For a deeper analysis of what DORA's training provisions require in practice, including the Article 13 obligations, see our detailed guide on DORA staff training requirements.
Dual-Regulated Entities: How to Handle the Overlap
The most common question we hear from compliance teams is: "We think we fall under both. What do we do?"
The answer depends on which type of dual-regulated entity you are.
Financial entities that are also NIS2 essential or important entities. For credit institutions and financial market infrastructure operators listed in NIS2's Annex I, the position is straightforward. DORA governs your digital resilience obligations. Comply with DORA, and you have met the corresponding NIS2 requirements by operation of the lex specialis principle. You may still need to register under your national NIS2 transposition — check your member state's implementing legislation — but the substantive compliance obligations flow from DORA.
ICT service providers that serve financial clients. If you are an ICT third-party service provider designated as critical under DORA's oversight framework, you will face DORA-specific obligations including potential direct oversight by a Lead Overseer. If you also meet NIS2's thresholds as a digital infrastructure or ICT service management provider, you may face NIS2 obligations for aspects of your business not covered by DORA. In practice, this means your financial services operations are governed by DORA while your broader operations fall under NIS2.
Groups with both financial and non-financial subsidiaries. A holding company with a bank and a manufacturing subsidiary will find that the bank falls under DORA while the manufacturer falls under NIS2 (if it meets the thresholds). There is no single framework that covers both. The group compliance function will need to maintain parallel programmes, though the underlying training content and risk-management practices will share significant common ground.
For all three cases, the practical recommendation is the same: build from DORA outward. DORA's requirements are more detailed and more demanding. A training programme that satisfies DORA's standards will, in almost every case, exceed what NIS2 requires. Starting from DORA and extending to cover any NIS2-specific gaps is more efficient than trying to reconcile two separate programmes.
Building a Training Programme That Covers Both
If you accept that DORA is the higher standard and the natural starting point, the question becomes how to build a programme that efficiently addresses both sets of obligations without creating separate training tracks that duplicate content and confuse staff.
Map your obligations first. Before designing any training, establish which entities in your group fall under which regulation. This is a legal and compliance exercise, not a training design exercise. Get it right at the outset and the training architecture follows naturally.
Design for DORA's standard. Build your core training programme around DORA's ICT risk-management framework: risk identification, protection and prevention, detection, response and recovery, and third-party risk management. Include the management body obligations from Article 5(4) and the all-staff requirements from Article 13(6). If this programme is well designed, it will inherently cover NIS2's Article 20 and Article 21 competence standards.
Add NIS2-specific modules where needed. For entities or business units that fall under NIS2 but not DORA, you will need training that addresses NIS2's specific provisions — particularly around incident reporting through the NIS2 channel (which differs from DORA's), supply chain security obligations under Article 21(2)(d), and any member state-specific requirements from national transposition.
Use scenario-based approaches for both. Both regulations require demonstrated competence, not just completion. A slide deck with a quiz may document that training occurred, but it does not demonstrate that staff can respond to an ICT incident, assess a third-party risk, or make governance decisions under pressure. Scenario-based training produces evidence of applied competence — which is what both sets of regulators are increasingly looking for.
The DORA training programme is designed around this principle, using scenario-based modules that map directly to DORA's ICT risk-management framework while producing the kind of decision-level evidence that financial supervisors expect. For organisations that need to cover NIS2 as well, the NIS2 board training programme addresses the Article 20 management body obligations through a parallel scenario-based approach.
If you are unsure which regulation applies to your organisation — or whether you face dual obligations — the compliance training diagnostic can help you map your regulatory exposure and identify the training programme that fits.
The Bottom Line
DORA and NIS2 are not competing frameworks. They are complementary — one specific, one general — with a clear legal hierarchy governing their interaction. For financial entities, DORA is the primary obligation. For non-financial entities in NIS2's scope, NIS2 is the governing framework. For the subset of organisations that touch both — primarily ICT service providers and financial groups with non-financial subsidiaries — the approach is to build from the more demanding standard and extend as needed.
The training implications follow the same logic. A well-designed DORA training programme that covers ICT risk management, incident response, third-party risk, and management body governance will satisfy both frameworks for most financial entities. The organisations that will struggle are those that try to address each regulation separately, creating parallel programmes that duplicate effort without improving outcomes.
Start with clarity on scope. Build from the higher standard. Design training that produces evidence of competence, not just evidence of attendance. That approach serves both regulations — and, more importantly, it serves the operational resilience that both regulations are trying to achieve.