NIS2 vs DORA: Differences, Overlap and Which Applies

Last updated: 14 October 2026

Quick answer: NIS2 vs DORA is mainly a question of sector. NIS2 is a directive setting cybersecurity rules for 18 sectors. DORA is a directly applicable regulation, applying since 17 January 2025, that sets detailed ICT risk, incident, testing and third-party rules for 20 types of financial entity. For financial entities, DORA is the sector-specific law that takes precedence.

For a CISO in a bank, insurer or investment firm, the relationship between NIS2 and DORA is one of the first questions to settle. Both deal with cybersecurity and resilience. Both require incident reporting, third-party risk management and board-level accountability. Yet they differ in legal form, scope, level of detail and supervisors.

This NIS2 vs DORA guide explains how the two fit together, where they overlap and differ, and what that means for organisations that sit near the boundary, such as ICT providers serving the financial sector.

NIS2 vs DORA: what is the core difference?

The core difference is that NIS2 is a horizontal cybersecurity directive, while DORA is a sector-specific regulation for finance. Directive (EU) 2022/2555 (NIS2) sets minimum rules that each Member State had to transpose into national law by 17 October 2024. Regulation (EU) 2022/2554 (DORA) applies directly in every Member State without transposition, supplemented by technical standards.

Both were adopted on 14 December 2022 as part of the same wider push to strengthen EU cyber resilience, which is why so many concepts line up. According to EIOPA, DORA applies to 20 different types of financial entities and to ICT third-party service providers, and has applied since 17 January 2025.

How do NIS2 and DORA compare side by side?

Which law applies to a financial entity?

For financial entities, DORA takes precedence. DORA Article 1(2) states that, for financial entities identified as essential or important entities under national NIS2 rules, DORA is considered a sector-specific Union legal act for the purposes of Article 4 of NIS2. Article 4 of NIS2 in turn provides that where a sector-specific act requires at least equivalent cybersecurity risk management and incident reporting obligations, the matching NIS2 provisions do not apply.

In plain terms, a bank or insurer that is also in a NIS2 sector follows DORA for ICT risk management, incident reporting and related supervision, rather than the equivalent NIS2 rules. This is often described as DORA being the lex specialis.

Common mistake: concluding that NIS2 is irrelevant to the financial sector. Banking and financial market infrastructures remain NIS2 sectors, national laws may still include registration or information-sharing links, and your ICT suppliers may be NIS2 entities themselves. Check how your Member State’s transposition law treats DORA entities.

Who can be caught by both?

The boundary matters most for organisations that are not financial entities but serve them.

• Cloud, data centre and managed service providers. These are NIS2 sectors in their own right. If they serve financial entities, they are also ICT third-party service providers under DORA, and their clients must apply DORA’s contractual requirements to them.
• Critical ICT third-party providers. On 18 November 2025, the ESAs published the list of designated critical ICT third-party providers under DORA. These providers face direct EU oversight under DORA while still being subject to NIS2 as digital infrastructure or ICT service providers.
• Group entities. A banking group’s IT subsidiary that also serves non-financial clients may be a NIS2 entity and an intra-group ICT provider under DORA at the same time.

Worked example: a banking group

Consider a mid-sized banking group with three entities:

In practice: build one control set and map it to both laws. Most controls, such as access management, logging, backup and supplier assessment, serve both, and only reporting routes and some documentation differ.

How do the incident reporting rules differ?

Both laws use a staged approach, but DORA’s first deadline is tighter and is triggered by classification.

NIS2

For significant incidents, NIS2 Article 23 requires an early warning within 24 hours of becoming aware, an incident notification within 72 hours and a final report within one month of the notification. We cover each stage in our NIS2 incident reporting guide.

DORA

For major ICT-related incidents, the regulatory technical standards in Delegated Regulation (EU) 2025/301 set these time limits:

• Initial notification: within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it.
• Intermediate report: within 72 hours of the initial notification, with updates when regular activities are recovered.
• Final report: no later than one month after the latest intermediate report.

The standards allow some deadlines falling on weekends or bank holidays to move to the next working day, but not for certain entities, including credit institutions, central counterparties, trading venue operators and entities identified as essential or important under NIS2.

DORA also uses its own classification criteria to decide what counts as major, different from NIS2’s significance test. Running both from one incident and breach management workflow helps when a single event also triggers GDPR’s 72-hour personal data breach notification.

How do third-party risk requirements differ?

This is where DORA goes much further than NIS2.

• NIS2 requires supply chain security, including security aspects of relationships with direct suppliers and service providers, as one of its Article 21 measures. It also allows EU-level coordinated risk assessments of critical supply chains.
• DORA sets out a full third-party risk regime: a strategy on ICT third-party risk, a register of information on all ICT contractual arrangements, pre-contract due diligence, mandatory contract clauses, exit strategies and concentration risk assessment, plus direct oversight of critical providers.

If your third-party programme is built for DORA, it will generally exceed NIS2’s supply chain expectations. A structured vendor and third-party risk management process makes it easier to keep the register of information and supplier assessments consistent. Our DORA register of information guide covers the templates in detail.

How does resilience testing differ?

NIS2 asks for policies and procedures to assess the effectiveness of cybersecurity risk management measures. It does not prescribe a testing programme.

DORA requires a risk-based digital operational resilience testing programme, including vulnerability assessments, scenario-based tests and other appropriate tests. Under Article 26, financial entities identified by their competent authority must carry out threat-led penetration testing at least every 3 years, with microenterprises and certain other entities excluded.

What do both laws expect from the board?

Both place accountability firmly with senior management, but in different words:

• NIS2 Article 20: management bodies approve the risk management measures, oversee their implementation, can be held liable for infringements and must follow training.
• DORA Article 5: the management body defines, approves, oversees and is responsible for the ICT risk management framework and bears ultimate responsibility for managing ICT risk. Members must keep their ICT risk knowledge and skills up to date.

For a board that oversees several group entities, one dashboard mapped to both laws avoids two parallel reporting streams. Enactia’s Compliance Universe maps controls across DORA, NIS2, ISO 27001 and GDPR, and you can start your 14-day free trial to see the mapping on your own controls.

How should you manage NIS2 and DORA together?

A practical sequence for organisations exposed to both:

1. Classify every entity. List each legal entity, whether it is a DORA financial entity, a NIS2 essential or important entity, an ICT third-party provider to financial entities, or several of these.
2. Pick a primary control framework. Many organisations use ISO 27001 as the backbone and map both laws to it.
3. Map requirements once. Link each control to the NIS2 and DORA provisions it satisfies, and flag the gaps unique to each.
4. Separate the reporting routes. Define who reports what to which authority, and within which deadline, for each entity.
5. Unify third-party management. Keep one supplier inventory that feeds the DORA register of information and NIS2 supply chain assessments.
6. Report to the board once. Present one view of cyber and ICT risk, with the legal obligations noted per entity.

For a broader view of how these laws overlap with the EU AI Act, see our DORA, NIS2 and EU AI Act overlap strategy, and for DORA fundamentals, our guide to mastering DORA compliance.

Key takeaways

• NIS2 is a cross-sector directive; DORA is a directly applicable regulation for the financial sector.
• For financial entities, DORA is the sector-specific act under NIS2 Article 4 and takes precedence for equivalent obligations.
• DORA’s first incident notice is due within 4 hours of classifying an incident as major, no later than 24 hours after awareness.
• DORA’s third-party and testing rules go well beyond NIS2.
• ICT providers to finance, including designated critical providers, can face both regimes.

Frequently asked questions

Does NIS2 apply to banks?
Banking is a NIS2 sector, but for financial entities covered by DORA, DORA is the sector-specific act under NIS2 Article 4. That means banks follow DORA for ICT risk management and incident reporting instead of the equivalent NIS2 provisions. National transposition laws may still contain related obligations, so check your Member State’s rules and your supervisor’s guidance.

Is DORA stricter than NIS2?
In several areas, yes. DORA has a tighter first incident deadline, a detailed ICT risk management framework, mandatory threat-led penetration testing for identified entities and a much more detailed third-party regime, including a register of information and oversight of critical providers. NIS2 is broader in sector coverage but generally less prescriptive in its requirements.

Can one incident trigger both NIS2 and DORA reporting?
Yes, where different entities are involved. For example, a cloud provider that is a NIS2 entity may report a significant incident under NIS2, while its financial entity clients assess whether the same event is a major ICT-related incident under DORA. If personal data is affected, GDPR breach notification may also apply within 72 hours.

Are ICT service providers subject to DORA?
DORA’s obligations fall mainly on financial entities, which must manage ICT third-party risk through contracts, due diligence and a register of information. Providers designated as critical by the ESAs are also subject to direct EU oversight. The ESAs published the first list of designated critical ICT third-party providers on 18 November 2025.

Can ISO 27001 help with both NIS2 and DORA?
Yes. An ISO 27001 information security management system covers much of the risk management, access control, incident handling and supplier security that both laws expect. It will not cover everything, such as DORA’s register of information, threat-led penetration testing or specific reporting templates, but it gives you a common control base to map both laws to.

Bringing NIS2 and DORA into one programme

NIS2 and DORA were designed to work together, not to be run as separate projects. For financial entities, DORA sets the rules; for their ICT providers and non-financial group companies, NIS2 often does. The most efficient approach is to classify each entity, build one mapped control set and keep reporting routes and supplier records clear for each regime. Our DORA compliance page explains how that works in practice.

If you would like to discuss mapping DORA and NIS2 across your group, contact us or book a demo or start your 14-day free trial of Enactia’s AI-powered GRC platform.

This article is for general information and is not legal advice.