DORA vs NIS2: Obligations for Dual-Scope Entities

For a financial entity that falls within both DORA and NIS2, DORA is the sector-specific EU rulebook for the overlapping ICT risk-management and major incident-reporting duties. DORA Article 1(2) and NIS2 Article 4 create that carve-out. The result is not two parallel sets of equivalent cyber controls for the same legal entity. It is a DORA-led operational program, with NIS2 still relevant where the carve-out does not reach.

That last part matters. "DORA replaces NIS2" is a useful shortcut until it becomes too blunt. Not every DORA entity is also a NIS2 entity, not every company in a financial group has the same scope, and an ICT provider can face DORA-related customer or oversight requirements while still carrying direct NIS2 duties of its own.

The practical job is therefore to map the legal entity first, then the obligation. Once that is done, most teams can run one control and evidence program without pretending the reporting routes or supervisory regimes are identical.

DORA vs NIS2 at a glance

The two laws overlap because NIS2 covers critical sectors broadly while DORA was written specifically for digital operational resilience in finance. This table shows the difference that matters when the same financial entity appears in both scopes.

Why do DORA and NIS2 overlap at all?

The overlap starts with scope. NIS2 names banking and financial market infrastructures among its high-criticality sectors. DORA, meanwhile, applies to a much broader list of financial entities, including credit institutions, payment institutions, investment firms, insurers, trading venues, central counterparties, and several other regulated financial businesses.

That means some legal entities can sit inside both regulatory perimeters. A credit institution is the obvious example. A trading venue or central counterparty can be another. But being "a fintech" or "a DORA company" does not automatically make an entity dual-scope under NIS2.

DORA itself resolves the collision. Article 1(2) says that, for financial entities that are identified as essential or important entities under national rules transposing NIS2, DORA is treated as a sector-specific Union legal act for NIS2 Article 4 purposes. The European Commission's Article 4 guidelines then explain the consequence: DORA's ICT risk management, incident management and reporting, resilience testing, and ICT third-party risk rules apply instead of the equivalent NIS2 provisions for those financial entities.

If you need the exact legal basis, the Commission Guidelines on NIS2 Article 4 are the clearest source because they explain the DORA carve-out directly rather than leaving the reader to reconcile the two laws article by article.

For the broader requirements behind each side of the comparison, see our DORA overview and NIS2 Requirements Guide.

Does DORA replace NIS2 for financial entities?

For the overlapping operational duties, yes. For the entire NIS2 framework in every situation, no.

NIS2 Article 4 is designed to prevent duplicate regulation where another EU law imposes cybersecurity risk management or incident reporting requirements that are at least equivalent in effect. DORA was written to meet that test for the financial entities covered by both laws.

The practical result is that a dual-scope bank should not build one ICT risk framework for DORA and a second, equivalent one for NIS2 Article 21. It should build the DORA framework properly, map the evidence, and document why that DORA control set is the operative one for the overlapping obligation.

The same logic applies to major ICT-related incident reporting. A financial entity does not need two parallel EU-level reporting clocks for the same displaced duty simply because NIS2 also contains an incident-notification article. DORA supplies the financial-sector-specific classification, reports, templates, and time limits.

The European Commission repeated this position in its 2026 report on DORA, describing DORA as the sector-specific regime that applies instead of the NIS2 risk-management and incident-reporting requirements for the relevant financial entities. The same report also makes an important counterpoint: NIS2 still matters to the wider cybersecurity cooperation and crisis-management system around the financial sector.

Which DORA obligations take the place of equivalent NIS2 duties?

The cleanest way to understand the carve-out is by operating area rather than by memorizing article numbers. These are the areas where a dual-scope financial entity should treat DORA as the working rulebook.

For the detailed NIS2 side of that comparison, our NIS2 Article 21 Measures: Full Breakdown explains the full NIS2 control picture without repeating those ten areas on this comparison page.

Where does NIS2 still need separate attention?

The carve-out solves duplication for a specific financial entity and specific categories of obligations. It does not turn every company connected to finance into a DORA-only organization. Four situations deserve a separate check.

1. A group can contain different regulatory entities

A banking group may contain a credit institution governed by DORA, a managed service company that falls directly under NIS2, and another subsidiary that is outside both frameworks. Applying one label to the entire group can hide those differences.

The safer model is legal-entity mapping: identify what each company does, which law covers it directly, and which shared controls or services support it.

2. Not every DORA entity is automatically a NIS2 entity

DORA covers many types of financial entities. NIS2 does not mirror that list. The main NIS2 financial-sector categories are banking and financial market infrastructures, while other DORA entities need a separate NIS2 scope reason before they become dual-scope.

This is why "we are under DORA; therefore, we are also under NIS2" is as unreliable as the reverse assumption.

3. ICT providers can sit in a different position from their financial customers

DORA creates obligations around ICT third-party risk and an oversight framework for critical ICT third-party service providers. But DORA Article 1(2) describes the NIS2 carve-out in relation to financial entities, not every ICT provider that serves them.

A cloud provider, data center provider, managed service provider, or managed security service provider can therefore face DORA-related contractual or oversight demands from the financial sector and still have direct NIS2 obligations if it independently falls within NIS2 scope.

4. National and EU-level NIS2 coordination does not disappear

The Commission's 2026 DORA report points out that NIS2 still contributes to wider preparedness and cross-border cyber crisis coordination for banking and financial market infrastructures. CSIRTs, national strategies, and EU cooperation mechanisms remain part of the surrounding system even where DORA governs the financial entity's operational duties.

For a company, this means the right question is narrower than "Does NIS2 still exist for us?" The useful question is "Which obligation are we trying to satisfy, for which legal entity, and through which authority?"

How do DORA and NIS2 differ on incident reporting?

Both frameworks impose fast incident reporting, but the triggers and clocks are not interchangeable. A dual-scope financial entity should use the DORA incident regime for the displaced reporting obligation rather than trying to run both frameworks side by side.

Under the current DORA technical standard, the initial notification is due as early as possible and, in any case, within four hours after the incident is classified as major and no later than 24 hours after the entity became aware of it. The intermediate report is due within 72 hours after the initial notification, and the final report is due no later than one month after the intermediate report or latest updated intermediate report.

NIS2 uses a different sequence for significant incidents: a 24-hour early warning, a 72-hour incident notification, and a final report no later than one month after the incident notification.

Those similarities make it tempting to merge the clocks. Do not. The legal triggers and report content are different.

You will find the complete NIS2 sequence in our NIS2 Incident Reporting Timeline: 24 Hours, 72 Hours, and One Month page.

How do the frameworks differ on third-party risk?

Both laws care about dependencies, but DORA is much more detailed for financial entities. NIS2 requires supply-chain security as part of the Article 21 risk-management measures. DORA builds a dedicated ICT third-party risk regime around financial entities, contractual arrangements, concentration risk, critical functions, and the Register of Information.

For a dual-scope financial entity, the DORA third-party framework therefore does the heavier legal work. That does not mean the organization should maintain separate vendor inventories for every law. One supplier inventory can support several regulatory purposes as long as the fields, ownership, and evidence needed by each obligation are preserved.

If the Register of Information is part of your current work, our DORA Register of Information Readiness page explains the data structure, submission logic, and readiness problems without turning the comparison page into a register guide.

For the underlying risk processes, see our DORA ICT Third-Party Risk Management guide and NIS2 Supplier Risk Assessment guide.

Three examples of DORA and NIS2 scope in practice

Entity examples make the Article 4 rule easier to use because the answer changes when the legal entity changes, even inside the same corporate group.

Example 1: an EU credit institution

The bank is a DORA financial entity and can also sit within the NIS2 banking sector. For the overlapping ICT risk management and major incident reporting duties, DORA is the operative regime. The bank should map DORA controls and evidence rather than running a duplicate NIS2 control program for the same obligation.

Example 2: a payment institution that is not otherwise in NIS2 scope

The payment institution can fall under DORA without automatically becoming a NIS2 essential or important entity. DORA therefore applies, but the "DORA vs NIS2" collision may never arise unless the entity has another activity or designation that independently puts it inside the NIS2 scope.

Example 3: a managed service provider serving banks

The provider may have DORA-related contractual duties because its financial customers must manage ICT third-party risk. If the provider is designated critical under DORA, it can also fall under the DORA oversight framework. Separately, a managed service provider can be directly within NIS2 scope. The provider should not assume that its customers' DORA regime removes its own NIS2 obligations.

How should a dual-scope organization build one compliance program?

The practical goal is one operating model with clear legal routing, not two copies of the same control library. Start with the entity and obligation map, then decide what can share evidence and what needs a separate trigger or submission path.

• Map each legal entity to DORA, NIS2, both, or neither. Do not classify the whole group from the parent company's status.
• For dual-scope financial entities, mark the DORA domains that replace equivalent NIS2 operational duties under Article 4.
• Build shared controls for activities such as asset management, access control, monitoring, resilience, supplier oversight, and evidence collection where the same control supports more than one requirement.
• Keep incident classification and regulatory reporting routes explicit. Shared detection does not mean a shared legal trigger.
• Keep provider and subsidiary scope separate. A service company can have direct NIS2 duties even when its financial customer uses DORA as the operative regime.
• Maintain a short legal-routing note for each mapped control so an auditor or regulator can see why DORA evidence is being used for the overlapping NIS2 requirement.

This is also where the European Compliance Guide for NIS2, DORA & GDPR is useful: it gives security and compliance teams a common starting point for incident ownership, evidence, and reporting across EU rules without pretending the legal regimes are identical.

A quick decision test for DORA vs NIS2

Before adding another control, policy, or reporting workflow, run the obligation through this short sequence. It usually reveals whether the team is dealing with real dual regulation or simply duplicate documentation.

• Which legal entity performs the regulated activity?
• Is that entity a DORA financial entity under Article 2?
• Is the same entity also an essential or important entity under NIS2 national law?
• Is the question about ICT risk management, major incident reporting, resilience testing, ICT third-party risk, or related supervision?
• If yes, does DORA provide the sector-specific rule for that obligation?
• Is there another NIS2 duty, national procedure, group entity, or ICT provider outside that carve-out that still needs separate treatment?

If the answer is "DORA governs this obligation," stop building duplicate NIS2 paperwork for the same legal duty. Keep the mapping that proves why. If the answer changes when you move to another entity or service, treat that as a scope boundary rather than forcing one rule across the group.

Final thoughts: The useful outcome is one mapped program, not two binders

A dual-scope financial entity should be able to point to one control, one owner, and one evidence trail for an overlapping operational requirement, then explain why DORA is the governing regime. The complexity belongs in the scope map and legal routing, not in duplicated security work.

That approach also exposes the places where the answer really does split: another subsidiary, an ICT provider, a national procedure, or an incident that needs a different regulatory route. Those are the boundaries worth documenting.

Frequently asked questions about DORA vs NIS2

Does DORA override NIS2?

For dual-scope financial entities, DORA takes priority for the equivalent cybersecurity risk-management and incident-reporting duties covered by NIS2 Article 4. It does not remove NIS2 from every entity, group company, provider, or EU cybersecurity coordination mechanism.

Can a company be subject to both DORA and NIS2?

Yes. A financial entity can sit within both scopes. DORA then acts as the sector-specific regime for the overlapping operational duties. Other group entities can still have separate NIS2 obligations.

Do banks need separate DORA and NIS2 control frameworks?

Usually not for equivalent ICT risk-management duties. A dual-scope bank can build the DORA control framework and map the evidence to the NIS2 overlap rather than maintaining a second copy of the same control set.

Does DORA replace NIS2 incident reporting?

For a financial entity covered by the Article 4 carve-out, DORA governs the displaced major ICT-incident reporting duty. DORA and NIS2 have different triggers and report structures, so teams should not merge the legal clocks.

Do ICT providers follow DORA instead of NIS2?

Not automatically. ICT providers can face DORA contractual or oversight requirements while still carrying direct NIS2 duties if they independently fall within the NIS2 scope. The DORA Article 1(2) carve-out is framed around financial entities.

What is the main difference between DORA and NIS2?

NIS2 sets a cross-sector cybersecurity baseline through national law. DORA is a directly applicable EU regulation for digital operational resilience in finance, with more detailed rules for ICT risk, testing, incidents, and ICT third-party risk.