DORA and NIS2 were adopted within weeks of each other, both deal with cybersecurity and resilience, and both reach far beyond the organizations they name. It is no surprise that teams ask which one applies to them, and sometimes assume the answer is "whichever our customers mention most".
The answer depends on what you are, not on who asks. A bank, a cloud provider and a SaaS company selling to both can each land in a different place: under DORA, under NIS2, under one directly and the other through contracts, or under neither in their own right.
This article sets out how the two laws differ in form and scope, how the EU resolves the overlap for financial entities, where ICT providers end up, and a sequence of questions that gets you to an answer.
Two different kinds of law
The first difference is legal form, and it shapes everything else.
DORA is Regulation (EU) 2022/2554. A regulation applies directly in every member state, in the same words. DORA has applied since 17 January 2025.
NIS2 is Directive (EU) 2022/2555. A directive sets objectives that each member state must transpose into its own national law. The transposition deadline was 17 October 2024, but national laws arrived at different times, and they differ in detail. NIS2 replaced the original NIS Directive.
For you, this means DORA questions can be answered from one text and its technical standards. NIS2 questions have to be answered from the national law of each member state where you are subject to it, with the directive as the common baseline.
Who each one covers
DORA covers financial entities, listed in its Article 2: credit institutions, payment and electronic money institutions, investment firms, crypto-asset service providers, insurers, market infrastructure, fund managers and others. It also provides an oversight regime for ICT third-party providers designated as critical.
NIS2 covers entities in sectors listed in its two annexes. Annex I lists sectors of high criticality, including energy, transport, banking, financial market infrastructures, health, drinking water, digital infrastructure, ICT service management, public administration and space. Annex II lists other critical sectors, including postal services, waste management, chemicals, food, manufacturing, digital providers and research. As a general rule, NIS2 applies to medium-sized and large entities in those sectors, with some types covered regardless of size.
Banking and financial market infrastructures appear in both. That overlap is the first thing the two laws resolve.
How the overlap resolves for financial entities
NIS2 has a rule for sector-specific EU laws. Article 4 provides that where a sector-specific EU act requires entities to adopt cybersecurity risk management measures or to notify significant incidents, with effect at least equivalent to NIS2, the corresponding NIS2 provisions do not apply to those entities.
NIS2's recitals identify DORA as such an act for financial entities. The effect is that DORA's rules on ICT risk management, incident management and reporting, resilience testing, information sharing and ICT third-party risk apply in place of NIS2's equivalents. A bank in DORA's scope follows DORA for those subjects, not NIS2.
The overlap is not erased entirely. A financial group can contain entities that DORA does not cover, and those may fall under NIS2 on their own facts. The financial sector also remains part of national cybersecurity strategies and of cooperation between authorities. Confirm how your member state has handled this with counsel.
The two side by side
| DORA | NIS2 | |
|---|---|---|
| Instrument | Regulation, directly applicable | Directive, transposed into national law |
| Applies from | 17 January 2025 | Date set by each national law |
| Who is in scope | Financial entities in Article 2; critical ICT providers through oversight | Medium and large entities in Annex I and II sectors, plus some types regardless of size |
| Risk management | ICT risk management framework, Articles 5 to 16 | Cybersecurity risk management measures, Article 21 |
| Incident reporting | Major ICT-related incidents to the financial supervisor: initial notification, intermediate report, final report | Significant incidents to the CSIRT or competent authority: early warning, incident notification, final report |
| Testing | Yearly testing program; threat-led penetration testing for entities selected by supervisors | No TLPT equivalent; policies to assess the effectiveness of measures |
| Third parties | Register of information, mandatory contract terms, oversight of critical providers | Supply chain security as one of the Article 21 measures |
| Management | Management body bears ultimate responsibility for ICT risk | Management bodies approve and oversee measures, can be held liable, and must follow training |
The table hides real detail on each row. DORA's reporting deadlines are set in technical standards, as covered in our article on DORA incident reporting. NIS2's are in the directive itself and repeated, sometimes with variations, in national law.
Where ICT providers land
This is where most of the confusion lives. An ICT provider can be affected by both laws at once, through different mechanisms.
Through DORA, indirectly. If your customers are financial entities, DORA reaches you through their contracts, their register of information and their testing obligations. You do not carry their obligations, but you must support them. The mechanics are in DORA explained for ICT service providers and DORA contract requirements for ICT services.
Through NIS2, directly. NIS2's Annex I includes digital infrastructure and ICT service management. Cloud computing service providers, data center service providers, content delivery networks, managed service providers and managed security service providers are named types. If you are one of them and meet the size threshold, NIS2 applies to you in your own right, under national law.
Through NIS2, indirectly. Even if you are out of NIS2's scope, your in-scope customers must manage supply chain security. Their questionnaires and contract terms will reflect that.
Through DORA, directly. Only if you are designated as a critical ICT third-party service provider. Few providers are.
The two direct regimes do not cancel each other. A cloud provider in NIS2's scope that serves banks follows NIS2 for its own risk management and incident reporting, and meets its bank customers' DORA contract requirements on top. The two reporting duties go to different authorities, on different triggers and clocks, so one incident can lead to a NIS2 report from you and a DORA report from each affected customer.
Working out which applies
Answer these in order, and write the answers down with your reasoning:
Are you a financial entity listed in DORA's Article 2? If yes, DORA applies for its subjects. Check whether any group entities fall outside it.
Do any of your activities match a sector or entity type in NIS2's annexes? Look at what you do, not how you describe it in marketing. A SaaS company may or may not be a cloud computing service provider under the directive's definitions.
Do you meet the size threshold, or are you a type covered regardless of size? NIS2 uses the EU's definition of medium-sized enterprises.
Which member states have jurisdiction? For most entities it is where they are established. Certain digital providers fall under the member state of their main establishment in the EU.
Do your customers fall under either law? If so, expect indirect requirements regardless of your own status.
Has any authority designated or identified you? Designation as a critical ICT provider under DORA, or identification under national NIS2 law, changes your position.
The result is often "both, in different ways". That is workable. Most of the underlying controls, such as risk assessment, access control, backups, incident response and supplier management, serve both regimes. The differences sit in governance records, reporting procedures and contract terms. Our DORA and NIS2 framework pages summarize each regime's structure.
How TrustLynce helps
TrustLynce's control mapping maps one set of controls to DORA and NIS2 requirements, so shared evidence is collected once and reused for both. The readiness dashboard shows gaps per framework, which keeps the regime-specific work visible.