DORA vs NIS2: 2026 Comparison for EU Financial Entities

In this article ↓

Short answer
DORA vs NIS2 at a glance
Fast decision tree
The legal relationship: lex specialis
Scope comparison
Entity mapping for fintech groups
Incident reporting: DORA vs NIS2
One incident workflow, two decision points
Control overlap
Obligation owner matrix
What financial entities should do first
1. Map entities and activities
2. Decide which regime owns each obligation
3. Build one incident workflow
4. Reuse evidence where possible
5. Confirm local authority routes
Evidence matrix for DORA and NIS2
Where DORA is more specific
Where NIS2 still matters
DORA vs NIS2 for suppliers
Common mistakes
Mistake 1: Assuming DORA removes all NIS2 relevance
Mistake 2: Running duplicate incident workflows
Mistake 3: Treating NIS2 as an EU Regulation
Mistake 4: Using NIS2 controls as DORA evidence without mapping
Mistake 5: Ignoring non-financial affiliates
Mistake 6: Assuming supplier NIS2 compliance is enough
Mistake 7: Using one group policy without entity mapping
Practical 30-day implementation plan
FAQ
Does DORA replace NIS2 for banks, payment institutions and EMIs?
Does NIS2 apply directly like DORA?
Should an EU fintech build separate DORA and NIS2 controls?
Are CASPs covered by DORA or NIS2?
Do DORA incident reports go to the same authority as NIS2 reports?
Can supplier NIS2 compliance satisfy DORA third-party risk?
Related reading
Primary sources
Bottom line

Last reviewed: 29 April 2026

Key takeaways

DORA is the sector-specific ICT resilience framework for in-scope financial entities; NIS2 is the broader cybersecurity directive.
For EU financial entities, DORA normally anchors the operating model where ICT risk, incidents, testing and third-party risk overlap.
NIS2 can still matter for group structures, non-financial affiliates, ICT providers and national reporting context.
Fastest path: map each legal entity -> separate DORA and NIS2 triggers -> keep one control base with distinct evidence views.

Short answer

DORA and NIS2 are both EU cyber-resilience laws, but they do different jobs.

DORA — Regulation (EU) 2022/2554 — is the financial-sector digital operational resilience regulation. It applies directly and has applied since 17 January 2025.
NIS2 — Directive (EU) 2022/2555 — is the broader EU cybersecurity directive for essential and important entities across critical sectors. Member States had to transpose it into national law by 17 October 2024.

For financial entities, the practical rule is: DORA is the sector-specific framework for ICT risk and digital operational resilience. NIS2 can still matter for group structures, non-financial affiliates, ICT providers and national cybersecurity context, but DORA is the main operating framework for regulated financial entities where the obligations overlap.

The wrong question is “DORA or NIS2?” The better question is: which legal entity, activity, system, supplier and incident path is governed by which regime?

DORA vs NIS2 at a glance

Topic	DORA	NIS2
Legal form	EU Regulation	EU Directive
Status in 2026	Applies directly since 17 January 2025	Transposition deadline was 17 October 2024; national implementation varies
Main scope	Financial entities and ICT third-party risk in the financial sector	Essential and important entities across critical sectors
Main objective	Digital operational resilience of financial entities	High common level of cybersecurity across the Union
Supervisors	Financial competent authorities and ESAs	National cybersecurity authorities, CSIRTs, ENISA coordination
Incident focus	Major ICT-related incidents and significant cyber threats	Significant incidents affecting network and information systems
Third-party focus	ICT third-party service providers, critical or important functions, Register of Information	Supply-chain security and cybersecurity risk-management measures
Testing	Digital operational resilience testing, TLPT for identified entities	Cybersecurity risk-management measures; national detail varies
Best owner	Compliance + risk + security + technology under financial governance	Security + legal + operations under national cybersecurity governance
Best evidence model	Financial entity evidence mapped to DORA chapters and local competent authority	Entity evidence mapped to national NIS2 law and reporting channel

Fast decision tree

Use this as a practical triage before going into legal detail.

Question	If yes	If no
Is the entity a financial entity listed in DORA Article 2?	Start with DORA as the primary ICT resilience framework	Continue NIS2 / sector analysis
Is the entity an ICT provider to financial entities?	Check DORA contractual, Register of Information and possible critical ICT provider relevance	Continue NIS2 / customer-contract analysis
Is the entity in a NIS2 essential or important sector under national law?	Map NIS2 obligations and national authority route	NIS2 may not apply directly, but customer requirements may still flow down
Is the group mixed: financial entity + technology company + non-financial affiliates?	Map each legal entity separately	A single DORA analysis may be sufficient only for the financial entity
Does an incident affect a regulated financial service?	Assess DORA major ICT-related incident criteria	Assess other contractual, customer or NIS2 triggers
Does an incident affect a NIS2 entity or service?	Assess national NIS2 significant-incident trigger	Keep internal incident evidence and customer notification checks

This decision tree does not replace legal analysis. It prevents the most common operational mistake: treating the whole group as either “DORA” or “NIS2” without entity-level mapping.

The legal relationship: lex specialis

NIS2 recognises that sector-specific Union legal acts can take precedence where they impose requirements at least equivalent in effect. DORA is the sector-specific financial-services regime for digital operational resilience.

For a financial entity, this means the operating analysis should start with DORA for:

ICT risk management;
major ICT-related incident reporting;
digital operational resilience testing;
ICT third-party risk;
Register of Information;
financial-sector supervisory evidence.

NIS2 is still relevant where:

the group has non-financial entities in NIS2 sectors;
the entity provides digital infrastructure or ICT services outside financial-sector scope;
a technology provider is itself an essential or important entity under NIS2;
national cybersecurity law creates additional procedures or coordination expectations;
group cyber governance needs one common baseline across DORA and NIS2 entities.

The practical implication is not “ignore NIS2”. It is “do not build a duplicate NIS2 programme for obligations already governed by DORA without checking the specific entity and national law.”

Scope comparison

Question	DORA answer	NIS2 answer
Does it target financial entities?	Yes, specifically	Yes, but as part of wider critical sectors
Does it apply directly?	Yes, as a Regulation	No, through national transposition
Does it cover payment institutions and EMIs?	Yes, where in DORA Article 2 scope	Potentially under financial market infrastructure / national scope, but DORA is the specific regime
Does it cover CASPs?	Yes, MiCA-authorised CASPs are in DORA scope	Potentially through national cybersecurity rules depending on activity
Does it cover cloud providers?	DORA creates oversight for critical ICT third-party providers designated under DORA	NIS2 covers certain digital infrastructure / ICT service management providers
Does it apply to non-financial subsidiaries?	Not unless they are DORA financial entities or ICT providers in scope	Potentially, if they fall in NIS2 sectors and size/scope rules
Does it create board or management accountability?	Yes, for the financial entity's ICT risk framework and resilience oversight	Yes, through national NIS2 management-body obligations
Does it define one EU reporting portal?	No, financial entities still use competent-authority channels	No, reporting channels depend on Member State implementation

The first practical task for a group is therefore entity mapping. Do not assume one legal entity's DORA status answers the NIS2 position for the whole group.

Entity mapping for fintech groups

Many fintech groups are not a single clean legal entity. They may include an EMI or PI, a technology development company, a holding company, local branches, outsourced support entities and SaaS vendors.

Entity or activity	DORA relevance	NIS2 relevance	Practical action
EU payment institution or EMI	Usually in DORA scope	Check national financial-sector implementation, but DORA is primary for ICT resilience	Build DORA operating model and local NCA reporting route
MiCA-authorised CASP	In DORA scope	Check national cybersecurity law and group activities	Map DORA evidence to CASP systems and suppliers
Group technology company	May be an ICT provider to the financial entity	May be in NIS2 if it provides covered digital or managed services	Treat as supplier / affiliate with clear services and contracts
Holding company	Usually not the operating DORA entity	Usually not NIS2 unless it performs covered services	Do not use holding-level policies as the only evidence
Cloud / hosting provider	ICT third-party under DORA, possibly critical if designated	Potentially NIS2 digital infrastructure / ICT service management	Capture contract, resilience, incident and subcontractor evidence
Managed security provider	ICT third-party under DORA	Potentially NIS2 ICT service management	Include monitoring, notification and evidence obligations in contract
Non-financial affiliate in another sector	Not automatically DORA	Potentially NIS2 if sector and size criteria apply	Run separate NIS2 scope analysis

For a fintech SMB, the highest-risk gap is often informal intra-group service provision. If the licensed entity depends on a sister technology company, that relationship should be visible in ICT third-party risk, continuity and incident evidence.

Incident reporting: DORA vs NIS2

DORA and NIS2 both require incident reporting, but the triggers, authorities and timelines are not identical.

Topic	DORA	NIS2
Reporting object	Major ICT-related incidents	Significant incidents
Trigger logic	DORA classification criteria and financial-sector impact	NIS2 significant-incident criteria under national implementation
Authority	Financial competent authority / local DORA channel	CSIRT or national cybersecurity authority
Initial timing	DORA technical standards: initial notification after classification as major	NIS2 sets staged notification obligations, with national implementation detail
Follow-up	Intermediate and final report	Early warning, incident notification, final report depending on implementation
Evidence needed	Detection time, classification time, affected services, remediation	Incident impact, severity, cause, mitigation and national reporting records
Internal owner	Incident manager + ICT risk/compliance owner	Incident manager + national cybersecurity/legal owner

For a financial entity, the clean model is one incident workflow with separate DORA and NIS2 decision points where the group has both obligations.

Not sure where DORA stops and NIS2 still matters?

A 15-minute call can map entity scope, incident triggers and evidence views - no pitch, just the practical split.

Book a free 15-min call →

One incident workflow, two decision points

Do not create a separate DORA incident process and a separate NIS2 incident process. Create one intake and triage workflow, then branch into reporting decisions.

Workflow step	DORA decision	NIS2 decision	Evidence to keep
Detect event	Is it an ICT-related incident affecting the financial entity?	Is a NIS2 entity or service affected?	Detection time, source, systems, first responder
Assess service impact	Does it affect critical or important functions, clients, transactions or market confidence?	Does it significantly affect service provision under national criteria?	Affected services, duration, users, geography
Classify	Major ICT-related incident, significant cyber threat or internal-only event	Significant incident, early warning or no NIS2 report	Classification log and rationale
Notify	Use financial competent authority route if reportable	Use CSIRT / national authority route if reportable	Submission timestamp, forms, recipients
Manage communications	Coordinate regulatory, customer, partner-bank and supplier communications	Coordinate national cybersecurity and customer communications	Approved messages and decision log
Close	Intermediate/final reports and remediation evidence	Final report / lessons learned where required	Root cause, remediation, control updates

The main control is timestamp discipline. Detection time, classification time, notification time and decision rationale should be recorded in one place.

Control overlap

DORA and NIS2 are not identical, but they overlap in practical control areas.

Control area	DORA evidence	NIS2 evidence
Governance	ICT risk framework, management-body oversight	Management accountability, cybersecurity governance
Risk management	ICT risk register, control owners, remediation	Cybersecurity risk-management measures
Incident handling	DORA incident classification and reporting workflow	Significant incident reporting process
Business continuity	BCDR plans, RTO/RPO evidence, tests	Crisis management, backup and recovery measures
Supply chain	Register of Information, ICT third-party risk, Article 30 clauses	Supply-chain security measures
Testing	Resilience test reports, TLPT where identified	Security testing and risk-based measures
Training	Board / staff DORA awareness	Cybersecurity hygiene and training
Vulnerability management	ICT asset, patching and remediation evidence	Vulnerability handling and risk-management measures
Access control	Identity, privileged access and segregation controls	Access control and asset protection measures

The right implementation model is not “DORA programme” plus “NIS2 programme” in isolation. It is one control base with different regulatory views.

Obligation owner matrix

For an EU financial entity, ownership should be explicit. Otherwise DORA/NIS2 overlap becomes a meeting topic rather than an operating model.

Workstream	Primary owner	DORA lens	NIS2 lens
Entity scope	Legal / compliance	Confirm financial entity scope and NCA	Confirm national NIS2 entity scope
ICT risk register	Risk / security / technology	Core DORA evidence	Cybersecurity risk evidence where relevant
Incident reporting	Incident manager + compliance	Major ICT incident classification and NCA reporting	Significant incident assessment and CSIRT / authority route
Supplier oversight	Procurement / risk / technology	Register of Information, criticality, contract clauses	Supply-chain security and provider assurance
Board reporting	CEO / COO / risk owner	Management-body ICT risk oversight	Management accountability and cybersecurity governance
Testing	Security / technology	Resilience testing programme and TLPT where applicable	Security testing and risk-based measures
Business continuity	COO / operations	BCDR, recovery and communication plans	Crisis management, backup and recovery evidence
Training	Compliance / security	DORA awareness for management and staff	Cyber hygiene and management training

This matrix can sit inside the governance pack. It helps avoid a common failure mode: everyone agrees that DORA and NIS2 overlap, but nobody owns the overlap.

What financial entities should do first

1. Map entities and activities

Create a group-level map showing:

regulated financial entities;
non-financial subsidiaries;
ICT service provider entities;
EU Member States of operation;
relevant financial competent authorities;
possible NIS2 competent authorities or CSIRT contacts.

2. Decide which regime owns each obligation

For regulated financial entities, DORA should usually be the primary operating framework for ICT risk. For non-financial entities in the same group, NIS2 may be the primary framework.

3. Build one incident workflow

The incident workflow should include:

DORA major ICT-related incident assessment;
NIS2 significant incident assessment where relevant;
customer / partner / contractual notifications;
evidence capture;
final remediation tracking.

4. Reuse evidence where possible

Most control evidence can support both regimes if it is well structured:

ICT risk register;
business continuity test reports;
incident logs;
supplier risk assessments;
board reporting;
training records;
remediation tracker.

5. Confirm local authority routes

DORA is an EU Regulation, but reporting channels and supervisory access still run through competent authorities. NIS2 is implemented through Member State law. The operating model should therefore include:

local financial competent authority route;
NIS2 competent authority or CSIRT route where relevant;
contact owners;
portal access and backup submitters;
evidence retention for each submission.

For financial-sector country routing, start with the DORA National Competent Authorities selected-jurisdiction hub.

Evidence matrix for DORA and NIS2

Evidence artefact	Supports DORA	Supports NIS2	Practical note
ICT risk framework	Yes	Often, as cybersecurity governance evidence	Map to the legal entity it governs
ICT risk register	Yes	Yes, if mapped to cybersecurity risks	Include owner, treatment, status and review date
Incident classification log	Yes	Yes, if NIS2 triggers are included	Keep timestamps and decision rationale
Register of Information	Yes	Partly, for supply-chain visibility	Do not treat it as a full NIS2 supplier file
Supplier criticality map	Yes	Yes	Link suppliers to services and business functions
BCDR test reports	Yes	Yes	Record findings and remediation, not just test completion
Board reporting	Yes	Yes	Show decisions, challenge and risk acceptance
Security awareness training	Yes, where linked to ICT risk	Yes	Keep audience, date, content and attendance
Remediation tracker	Yes	Yes	Separate accepted risk from overdue work
Authority contact list	Yes	Yes	Keep portal access and backup submitters current
Contract clause tracker	Yes, especially for ICT services supporting critical or important functions	Yes, for supply-chain obligations	Track renewal dates and gaps

The evidence should identify which legal entity and regulatory regime it supports. A group-level document without entity mapping is often hard to defend.

Where DORA is more specific

DORA is more prescriptive for financial entities in several areas:

ICT risk management framework;
major ICT-related incident classification and reporting;
digital operational resilience testing;
threat-led penetration testing for identified entities;
ICT third-party risk lifecycle;
Register of Information;
contractual provisions for ICT services supporting critical or important functions;
oversight of critical ICT third-party providers.

That specificity is why financial entities should not treat NIS2 as a substitute for DORA.

Where NIS2 still matters

NIS2 still matters for a financial group where:

a non-financial entity provides digital, managed security or ICT services;
an affiliate operates in a NIS2 sector such as digital infrastructure, health, energy or transport;
the group wants a common cybersecurity baseline;
national cybersecurity authorities issue requirements that affect group-level incident coordination;
suppliers are themselves NIS2 essential or important entities.

For vendor management, NIS2 can also improve the quality of supplier assurance because more ICT and digital infrastructure providers may be subject to formal cybersecurity obligations.

DORA vs NIS2 for suppliers

Financial entities should not only ask whether they are in scope. They should ask how supplier obligations change evidence quality.

Supplier type	DORA relevance for the financial entity	NIS2 relevance for the supplier	Contract / assurance point
Cloud provider	ICT third-party service supporting systems or functions	Potentially digital infrastructure / cloud service provider	Incident notice, resilience, location, subcontracting, audit and exit evidence
Managed security provider	ICT third-party service and possible incident evidence source	Potentially managed security service provider	Detection, escalation, logs, reporting support and conflicts
Core banking / payment processor	Critical ICT dependency for financial services	May be digital or ICT service provider depending on activity and national law	Availability, incident cooperation, testing and continuity evidence
SaaS compliance or finance tool	ICT supplier if used for regulated operations or evidence	Usually depends on service and size/scope	Data, access control, backups, availability and subcontractors
Intra-group technology entity	Affiliate ICT provider to the licensed entity	Could be in NIS2 depending on activity	Treat as a real service relationship, not an informal internal arrangement

NIS2 does not remove the need for DORA contract work. A supplier's own NIS2 status can help assurance, but the financial entity still needs DORA-relevant contractual rights, reporting support and exit planning.

Common mistakes

Mistake 1: Assuming DORA removes all NIS2 relevance

DORA is the financial-sector framework, but group structures and ICT provider roles can still create NIS2 exposure.

Mistake 2: Running duplicate incident workflows

Duplicate workflows create inconsistent timestamps and decisions. Use one incident process with DORA and NIS2 triggers.

Mistake 3: Treating NIS2 as an EU Regulation

NIS2 is a Directive. National transposition matters. Check the Member State implementation relevant to the entity.

Mistake 4: Using NIS2 controls as DORA evidence without mapping

Generic cybersecurity controls help, but DORA requires financial-sector-specific evidence: Register of Information, ICT third-party risk, DORA incident classification and resilience testing.

Mistake 5: Ignoring non-financial affiliates

A licensed financial entity may be mainly DORA-driven, while a group technology company, data centre entity or managed service provider may need separate NIS2 analysis.

Mistake 6: Assuming supplier NIS2 compliance is enough

A supplier's NIS2 status does not automatically give the financial entity DORA evidence. The contract still needs notification, access, audit, subcontracting, business continuity and exit rights where relevant.

Mistake 7: Using one group policy without entity mapping

Group cybersecurity policies are useful, but supervisors and authorities usually need to understand which legal entity owns which obligation, system, supplier and incident route.

Practical 30-day implementation plan

Week	Action	Output
Week 1	Map legal entities, regulated activities, services and Member States	DORA/NIS2 scope map
Week 2	Map systems, critical functions, suppliers and intra-group services	Dependency and supplier map
Week 3	Add DORA and NIS2 decision points into one incident workflow	Unified incident triage and reporting process
Week 4	Build evidence index and governance owner matrix	Board-ready DORA/NIS2 evidence pack

This is not the full compliance programme. It is the first operating layer that makes later legal, technical and supervisory work coherent.

FAQ

Does DORA replace NIS2 for banks, payment institutions and EMIs?

Where DORA and NIS2 obligations overlap for a financial entity, DORA is the sector-specific operational-resilience framework. But NIS2 can still matter for non-financial group entities, ICT provider activities and national cybersecurity coordination.

Does NIS2 apply directly like DORA?

No. DORA is an EU Regulation and applies directly. NIS2 is a Directive and works through Member State transposition, so national law and local authority routes matter.

Should an EU fintech build separate DORA and NIS2 controls?

Usually no. Build one control base and map it to DORA and NIS2 where relevant. Separate programmes create duplicate evidence, inconsistent incident timestamps and unclear ownership.

Are CASPs covered by DORA or NIS2?

MiCA-authorised CASPs are within DORA scope. NIS2 may still be relevant depending on group structure, technology-provider activities and national implementation.

Do DORA incident reports go to the same authority as NIS2 reports?

Not necessarily. DORA reporting is to the relevant financial competent authority route. NIS2 reporting is usually through a CSIRT or national cybersecurity authority route under national implementation.

Can supplier NIS2 compliance satisfy DORA third-party risk?

No, not by itself. It can support supplier assurance, but the financial entity still needs DORA-specific ICT third-party evidence, contract terms, criticality assessment and exit planning.

Primary sources

Bottom line

DORA and NIS2 are complementary, but they should not be treated as interchangeable.

For EU financial entities, DORA is the primary operational-resilience framework. NIS2 remains relevant for group mapping, non-financial affiliates, ICT provider exposure and national cybersecurity coordination.

The best operating model is one evidence base with clear regulatory mapping: DORA where the entity is a financial entity, NIS2 where the entity or group activity falls under national NIS2 implementation.

Andrey Gubarev

Related reading