DORA vs NIS2 financial-sector obligations and overlap
This comparison helps separate DORA duties for EU financial entities from NIS2 cybersecurity risk-management and incident-reporting duties for essential and important entities.
For a financial entity within both regimes, DORA is the sector-specific operational-resilience framework. NIS2 remains relevant to cooperation, CSIRTs, crisis structures, non-financial group entities, and ICT providers independently in scope.
DORA has applied since 17 January 2025. NIS2 required Member States to apply their transposing measures from 18 October 2024, so national law determines the operative NIS2 duties and authority route. When a DORA financial entity is also an under NIS2 national law, DORA is the sector-specific Union act for the overlapping cybersecurity risk-management, incident-reporting, supervision, and enforcement provisions. Other NIS2 mechanisms and separately covered group companies or providers still need their own analysis.
Side-by-side comparison
DORA vs NIS2: what changes in practice
Use these rows to decide which regime owns the obligation, where evidence can be shared, and where the same incident or supplier needs separate handling.
Directly applicable EU regulation for financial entities, focused on digital operational resilience, ICT risk, major ICT-related incidents, resilience testing, and ICT third-party risk.
Second framework
NIS2
EU directive for essential and important entities across listed sectors, focused on cybersecurity risk-management measures, significant-incident reporting, national supervision, CSIRTs, and cooperation.
Covers listed financial entities such as credit institutions, payment institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, insurers and reinsurers, insurance intermediaries, pension institutions, credit rating agencies, benchmark administrators, crowdfunding service providers, securitisation repositories, and ICT third-party service providers for DORA oversight purposes.
Covers essential and important entities in Annex I and Annex II sectors, with size-cap rules, specific entity categories, jurisdiction rules, and Member State lists or registration mechanisms. The annexes include sectors such as energy, transport, banking, financial market infrastructures, health, digital infrastructure, ICT service management, public administration, space, postal services, waste, chemicals, food, manufacturing, digital providers, and research.
Test each legal entity separately. A DORA financial entity uses the sector-specific rule only if it is also within the NIS2 national scope; a non-financial affiliate, cloud provider, managed service provider, or other group entity may have an independent NIS2 status.
Requires a documented ICT risk-management framework, governance and control arrangements, protection of information and ICT assets, business continuity, response and recovery, incident management, digital operational resilience testing, information sharing, and ICT third-party risk management.
Requires appropriate and proportionate technical, operational, and organisational cybersecurity measures based on an all-hazards approach, including risk analysis, incident handling, business continuity, supply-chain security, secure acquisition and maintenance, vulnerability handling, effectiveness assessment, cyber hygiene, cryptography, access control, asset management, and authentication.
A shared control library can support both, but DORA evidence must prove financial operational resilience and critical-or-important-function protection; NIS2 evidence must prove Article 21 cybersecurity risk-management measures for the NIS2 entity.
Financial entities report major ICT-related incidents to the relevant DORA competent authority using DORA templates and time limits. DORA also allows voluntary notification of significant cyber threats and requires client communication when a major ICT-related incident affects clients' financial interests.
Under NIS2 Article 23, essential and important entities notify significant incidents to the CSIRT or competent authority: an early warning within 24 hours after awareness, an incident notification within 72 hours after awareness, intermediate updates on request, and a final report no later than one month after the incident notification. An ongoing incident instead requires a progress report at that point and a final report within one month after handling ends.
Run separate classifications for each entity. One outage can create a DORA major-incident workflow for the financial entity and a NIS2 significant-incident workflow for its provider, with different awareness records, thresholds, forms, recipients, and clocks.
Requires financial entities to manage ICT third-party risk across the contract lifecycle, maintain and update a register of information for ICT service arrangements, assess concentration risk, include key contractual provisions, and address subcontracting for critical or important functions. Critical ICT third-party providers can be designated for Union-level oversight by a Lead Overseer.
Requires essential and important entities to address supply-chain security, direct supplier and service-provider relationships, secure development and maintenance, vulnerability handling, and overall supplier cybersecurity practices as part of Article 21 measures.
For a cloud, managed service, or security provider, DORA asks whether the provider supports a financial critical or important function; NIS2 asks whether the provider itself is an and whether its customer-facing services are protected.
A single evidence repository is useful only if every document is tagged by regime, entity, country, obligation, owner, source, review date, and incident or supplier relationship.
The financial entity management body defines, approves, oversees, and is responsible for the implementation of ICT risk-management arrangements. It bears ultimate responsibility for ICT risk, approves resilience strategy, continuity and recovery plans, ICT audit plans, third-party policies, budgets, training, and reporting channels.
Member States must ensure management bodies of essential and important entities approve Article 21 measures, oversee implementation, can be held liable for infringements, and follow training; NIS2 also encourages employee training.
Use separate board packs: DORA board evidence should focus on financial operational resilience and ICT third-party exposure; NIS2 board evidence should focus on Article 21 cybersecurity measures and significant-incident readiness.
Uses financial-sector competent authorities listed by financial entity type, plus DORA cooperation with the ESAs, ECB, ENISA, CSIRTs, single points of contact, and NIS2 competent authorities. Critical ICT third-party providers are overseen by a Lead Overseer, while the Joint Oversight Network coordinates the Lead Overseers' oversight activities.
Uses Member State competent authorities, CSIRTs, single points of contact, the Cooperation Group, the CSIRTs network, and EU-CyCLONe. Essential entities are subject to proactive supervision; important entities are subject to ex post supervision when there is evidence, indication, or information of non-compliance.
Route supervisory evidence to the authority that owns the obligation. Do not assume a CSIRT notification, DORA competent-authority report, or provider oversight request satisfies another regime unless the source expressly supports that flow.
DORA can reuse NIS2-style security controls, CSIRT coordination, supplier security evidence, incident taxonomies, and crisis-exercise outputs, but the DORA legal file must still show financial-entity scope, DORA classification, critical-function impact, DORA reporting, and financial-supervisor routes.
NIS2 can reuse DORA evidence from a financial group where it proves Article 21 or Article 23 obligations for a NIS2 entity, but it must still show NIS2 scope, significant-incident assessment, national authority or CSIRT route, and Member State implementation requirements.
Share the control artifact and separate the legal conclusion. One outage, contract, or control test can support both regimes only after the entity scope, national law, statutory test, accountable owner, and reporting route are documented for each.
Apply DORA to its listed financial entities. Where the same entity is also essential or important under NIS2 national law, use the DORA sector-specific rule for the overlapping risk-management, reporting, supervision, and enforcement provisions.
Apply NIS2 where an falls outside that displacement, and keep the NIS2 cooperation and crisis mechanisms that continue to cover the financial sector. Providers, affiliates, registrations, and national procedures require separate country-level checks.
For each legal entity, supplier, and incident, record DORA scope, NIS2 national scope, the displaced and surviving provisions, reporting routes, and evidence-reuse limits.
Covers listed financial entities such as credit institutions, payment institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, insurers and reinsurers, insurance intermediaries, pension institutions, credit rating agencies, benchmark administrators, crowdfunding service providers, securitisation repositories, and ICT third-party service providers for DORA oversight purposes.
Covers essential and important entities in Annex I and Annex II sectors, with size-cap rules, specific entity categories, jurisdiction rules, and Member State lists or registration mechanisms. The annexes include sectors such as energy, transport, banking, financial market infrastructures, health, digital infrastructure, ICT service management, public administration, space, postal services, waste, chemicals, food, manufacturing, digital providers, and research.
Test each legal entity separately. A DORA financial entity uses the sector-specific rule only if it is also within the NIS2 national scope; a non-financial affiliate, cloud provider, managed service provider, or other group entity may have an independent NIS2 status.
Requires a documented ICT risk-management framework, governance and control arrangements, protection of information and ICT assets, business continuity, response and recovery, incident management, digital operational resilience testing, information sharing, and ICT third-party risk management.
Requires appropriate and proportionate technical, operational, and organisational cybersecurity measures based on an all-hazards approach, including risk analysis, incident handling, business continuity, supply-chain security, secure acquisition and maintenance, vulnerability handling, effectiveness assessment, cyber hygiene, cryptography, access control, asset management, and authentication.
A shared control library can support both, but DORA evidence must prove financial operational resilience and critical-or-important-function protection; NIS2 evidence must prove Article 21 cybersecurity risk-management measures for the NIS2 entity.
Financial entities report major ICT-related incidents to the relevant DORA competent authority using DORA templates and time limits. DORA also allows voluntary notification of significant cyber threats and requires client communication when a major ICT-related incident affects clients' financial interests.
Under NIS2 Article 23, essential and important entities notify significant incidents to the CSIRT or competent authority: an early warning within 24 hours after awareness, an incident notification within 72 hours after awareness, intermediate updates on request, and a final report no later than one month after the incident notification. An ongoing incident instead requires a progress report at that point and a final report within one month after handling ends.
Run separate classifications for each entity. One outage can create a DORA major-incident workflow for the financial entity and a NIS2 significant-incident workflow for its provider, with different awareness records, thresholds, forms, recipients, and clocks.
Requires financial entities to manage ICT third-party risk across the contract lifecycle, maintain and update a register of information for ICT service arrangements, assess concentration risk, include key contractual provisions, and address subcontracting for critical or important functions. Critical ICT third-party providers can be designated for Union-level oversight by a Lead Overseer.
Requires essential and important entities to address supply-chain security, direct supplier and service-provider relationships, secure development and maintenance, vulnerability handling, and overall supplier cybersecurity practices as part of Article 21 measures.
For a cloud, managed service, or security provider, DORA asks whether the provider supports a financial critical or important function; NIS2 asks whether the provider itself is an and whether its customer-facing services are protected.
A single evidence repository is useful only if every document is tagged by regime, entity, country, obligation, owner, source, review date, and incident or supplier relationship.
The financial entity management body defines, approves, oversees, and is responsible for the implementation of ICT risk-management arrangements. It bears ultimate responsibility for ICT risk, approves resilience strategy, continuity and recovery plans, ICT audit plans, third-party policies, budgets, training, and reporting channels.
Member States must ensure management bodies of essential and important entities approve Article 21 measures, oversee implementation, can be held liable for infringements, and follow training; NIS2 also encourages employee training.
Use separate board packs: DORA board evidence should focus on financial operational resilience and ICT third-party exposure; NIS2 board evidence should focus on Article 21 cybersecurity measures and significant-incident readiness.
Uses financial-sector competent authorities listed by financial entity type, plus DORA cooperation with the ESAs, ECB, ENISA, CSIRTs, single points of contact, and NIS2 competent authorities. Critical ICT third-party providers are overseen by a Lead Overseer, while the Joint Oversight Network coordinates the Lead Overseers' oversight activities.
Uses Member State competent authorities, CSIRTs, single points of contact, the Cooperation Group, the CSIRTs network, and EU-CyCLONe. Essential entities are subject to proactive supervision; important entities are subject to ex post supervision when there is evidence, indication, or information of non-compliance.
Route supervisory evidence to the authority that owns the obligation. Do not assume a CSIRT notification, DORA competent-authority report, or provider oversight request satisfies another regime unless the source expressly supports that flow.
DORA can reuse NIS2-style security controls, CSIRT coordination, supplier security evidence, incident taxonomies, and crisis-exercise outputs, but the DORA legal file must still show financial-entity scope, DORA classification, critical-function impact, DORA reporting, and financial-supervisor routes.
NIS2 can reuse DORA evidence from a financial group where it proves Article 21 or Article 23 obligations for a NIS2 entity, but it must still show NIS2 scope, significant-incident assessment, national authority or CSIRT route, and Member State implementation requirements.
Share the control artifact and separate the legal conclusion. One outage, contract, or control test can support both regimes only after the entity scope, national law, statutory test, accountable owner, and reporting route are documented for each.
Apply DORA to its listed financial entities. Where the same entity is also essential or important under NIS2 national law, use the DORA sector-specific rule for the overlapping risk-management, reporting, supervision, and enforcement provisions.
Apply NIS2 where an falls outside that displacement, and keep the NIS2 cooperation and crisis mechanisms that continue to cover the financial sector. Providers, affiliates, registrations, and national procedures require separate country-level checks.
For each legal entity, supplier, and incident, record DORA scope, NIS2 national scope, the displaced and surviving provisions, reporting routes, and evidence-reuse limits.
Identify the legal entity and test DORA scope and NIS2 national scope separately.
If the entity is within both regimes, use DORA for the overlapping cybersecurity risk-management, incident-reporting, supervision, and enforcement provisions identified by NIS2 Article 4 and the Commission Guidelines.
If the entity is a non-financial group company, cloud provider, managed service provider, public administration body, digital infrastructure operator, or other Annex I or Annex II entity, apply the NIS2 sector, size, special-category, jurisdiction, and national-law tests.
If an incident affects both a financial entity and a NIS2-covered provider, run both incident classifications and keep separate notifications, forms, recipients, and customer-communication decisions.
Keep CSIRT, national cyber-crisis, EU-CyCLONe, and authority information-sharing mechanisms visible even where DORA displaces the entity-facing NIS2 risk and reporting duties.
For a DORA financial entity that is also an under NIS2 national law, the Commission's Article 4 Guidelines identify DORA as the sector-specific regime for ICT risk management, ICT incident management and reporting, resilience testing, information sharing, and ICT third-party risk. Member States should not apply the corresponding NIS2 cybersecurity risk-management, reporting, supervision, and enforcement provisions to that financial entity.
This does not remove the financial sector from NIS2 cooperation and crisis structures. CSIRTs can still cover the sector; DORA authorities exchange information with NIS2 bodies; national cyber crisis frameworks and EU-CyCLONe still apply. A non-financial affiliate or ICT provider can also be independently subject to NIS2 even when its financial customer uses DORA.
Use DORA first when the entity is both a DORA financial entity and an under the applicable NIS2 national law.
Use NIS2 for essential or important entities outside the DORA displacement, including relevant digital infrastructure, cloud, data-centre, managed service, and managed security service providers when they meet the NIS2 scope rules.
Do not merge reports: DORA major ICT-related incidents and NIS2 significant incidents use different statutory tests and recipients.
Check the transposing law in each relevant Member State for entity status, registration, authority, procedure, and any national requirements.
DORA requires financial entities to detect, manage, classify, record, and report major ICT-related incidents to the relevant financial competent authority. Its classification starts from DORA criteria such as affected clients or financial counterparts, duration and downtime, geographical spread, data loss, affected critical services, and economic impact, with further thresholds in Delegated Regulation (EU) 2024/1772.
NIS2 requires essential and important entities to notify significant incidents to the CSIRT or competent authority through an early warning, incident notification, intermediate updates on request, and a final report. A NIS2 significant incident turns on severe operational disruption, financial loss, or considerable material or non-material damage to others.
A DORA financial entity should classify and report its major ICT-related incident under DORA. Whether that entity would otherwise be an essential or important NIS2 entity depends on NIS2 and the applicable national law.
A cloud, managed service, telecom, energy, transport, health, or other NIS2 entity in the same fact pattern may still have its own NIS2 significant-incident clock.
Shared incident rooms should track separate legal clocks, recipients, forms, root-cause records, customer communications, and cross-border impact notes.
Where DORA reports are forwarded or made accessible to NIS2 bodies, record that as the DORA/NIS2 information-sharing mechanism, not as a separate NIS2 filing by the financial entity.
DORA is unusually specific about ICT third-party risk for financial entities. It requires written ICT service contracts, policies for ICT third-party arrangements, concentration-risk assessment, registers of information, contractual clauses, subcontracting oversight, and a Union oversight framework for ICT third-party service providers designated as critical.
NIS2 supply-chain security is broader and less financial-sector-specific. Article 21 requires essential and important entities to address supply-chain security, direct supplier and service-provider relationships, secure acquisition, vulnerability handling, access control, asset management, and other cybersecurity measures. A provider can therefore be a DORA ICT third-party in one relationship and a NIS2 entity for its own services.
For DORA, preserve the register-of-information row, function mapping, critical-or-important-function assessment, contract reference, provider identifiers, subcontractor trail, exit provisions, audit rights, and management approvals.
For NIS2, preserve the entity scope analysis, Article 21 control evidence, supplier-security assessment, vulnerability handling process, business-continuity evidence, access-control records, and incident-reporting procedures.
When the same supplier supports a financial critical or important function and also provides NIS2-covered services, keep both supervisory routes visible.
DORA makes the financial entity management body responsible for defining, approving, overseeing, and implementing ICT risk-management arrangements. It also requires management attention to business continuity, response and recovery plans, audit plans, third-party arrangements, budget, training, and reporting channels for ICT third-party changes and major ICT-related incidents.
NIS2 requires Member States to ensure that management bodies of essential and important entities approve cybersecurity risk-management measures, oversee implementation, can be held liable for infringements of Article 21, and receive training. Supervision differs: DORA uses financial-sector competent authorities and Lead Overseers for critical ICT third-party providers, while NIS2 uses national competent authorities, CSIRTs, single points of contact, and differentiated supervision for essential and important entities.
Board reporting under DORA should show ICT risk tolerance, resilience strategy, incident impacts, corrective actions, ICT third-party changes, and critical-function dependencies.
Board reporting under NIS2 should show Article 21 measures, significant-incident readiness, supplier-security decisions, management training, and remediation of authority findings.
For overlapping groups, route escalation to the financial supervisor for DORA issues and to the NIS2 national authority or CSIRT for NIS2 entity issues.
Build a comparison record that regulators and control owners can follow
Sorena can help map which entities, suppliers, incidents, controls, registers, and board approvals belong to DORA, NIS2, or both without collapsing the obligations into one generic cyber program.
Clarifies that the DORA sector-specific rule concerns financial entities that fall within both DORA and NIS2 and identifies the overlapping NIS2 provisions that Member States should not apply.
DORA incident classification uses criteria including affected clients, duration, geographical spread, data losses, critical services, and economic impact.
"materiality thresholds for determining major incidents"