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.
DORA Article 2 lists financial entities and ICT third-party service providers within its scope structure.
entities referred to in paragraph 1, points (a) to (t), shall collectively be referred to as ‘financial entities’
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.
NIS2 classifies entities as essential or important and uses annexed sector lists plus Member State identification and registration mechanisms.
essential entities and important entities
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.
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.
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.
DORA Article 6 requires a sound, comprehensive, and well-documented ICT risk-management framework.
sound, comprehensive and well-documented ICT risk management framework
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.
technical, operational and organisational measures
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.
DORA Article 19 requires major ICT-related incident reporting by financial entities and states that outsourced reporting does not transfer responsibility.
DORA incident classification uses criteria including affected clients, duration, geographical spread, data losses, critical services, and economic impact.
materiality thresholds for determining major incidents
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.
NIS2 Recital 28 expects DORA incident details to be transmitted or made immediately accessible to NIS2 bodies while DORA remains the financial-sector reporting route.
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.
The DORA register ITS requires standard register templates for ICT service contractual arrangements and subcontractors supporting critical or important functions.
maintain and update the register of information
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.
NIS2 Article 21 requires supply-chain security and consideration of supplier vulnerabilities and cybersecurity practices.
vulnerabilities specific to each direct supplier and service provider
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.
DORA Lead Overseer powers apply to critical ICT third-party service providers, including recommendations on security, service terms, and subcontracting.
NIS2 authorities may request documented cybersecurity policies, access to data and documents, and evidence of implementation.
requests for evidence of implementation
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.
DORA Article 5 assigns detailed governance duties to the financial entity management body.
define, approve, oversee and be responsible
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.
NIS2 Article 20 covers management-body approval, oversight, liability, and training.
can be held liable for infringements
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.
DORA Articles 46, 47, 34, and 35 describe financial competent authorities, cooperation with NIS2 bodies, the Joint Oversight Network, and Lead Overseer powers.
set up a JON to coordinate among themselves
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.
NIS2 Articles 31 to 33 describe supervision and enforcement for essential and important entities.
effectively supervise and take the measures necessary
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.
DORA expressly creates cooperation mechanisms with the NIS2 Cooperation Group, CSIRTs, and competent authorities.
consult and share information
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.
NIS2 preserves the DORA sector-specific route while maintaining information exchange with the financial sector.
maintain a strong relationship and the exchange of information
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.
NIS2 Recital 28 supports overlap handling: DORA applies instead for covered financial entities, while incident details and cyber-threat information can flow to NIS2 bodies.
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.
DORA provides the financial-sector operational resilience rule set for the left-side decision.
continued provision of financial services
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.
NIS2 provides the cross-sector cybersecurity rule set for essential and important entities outside the DORA replacement path.
high common level of cybersecurity
For each legal entity, supplier, and incident, record DORA scope, NIS2 national scope, the displaced and surviving provisions, reporting routes, and evidence-reuse limits.
DORA Article 47 keeps cooperation with NIS2 bodies visible when assigning the workstream.
effective and fast-response coordination mechanisms
Scope boundary
DORA
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.
DORA Article 2 lists financial entities and ICT third-party service providers within its scope structure.
entities referred to in paragraph 1, points (a) to (t), shall collectively be referred to as ‘financial entities’
NIS2
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.
NIS2 classifies entities as essential or important and uses annexed sector lists plus Member State identification and registration mechanisms.
essential entities and important entities
Operational implication
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.
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.
Cybersecurity risk controls
DORA
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.
DORA Article 6 requires a sound, comprehensive, and well-documented ICT risk-management framework.
sound, comprehensive and well-documented ICT risk management framework
NIS2
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.
technical, operational and organisational measures
Operational implication
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.
NIS2 ties cybersecurity measures to risks to network and information systems and service recipients.
prevent or minimise the impact of incidents
Incident classification and reporting
DORA
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.
DORA Article 19 requires major ICT-related incident reporting by financial entities and states that outsourced reporting does not transfer responsibility.
DORA incident classification uses criteria including affected clients, duration, geographical spread, data losses, critical services, and economic impact.
materiality thresholds for determining major incidents
NIS2
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.
NIS2 Recital 28 expects DORA incident details to be transmitted or made immediately accessible to NIS2 bodies while DORA remains the financial-sector reporting route.
immediate access to incident notifications
ICT third-party and supply-chain security
DORA
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.
The DORA register ITS requires standard register templates for ICT service contractual arrangements and subcontractors supporting critical or important functions.
maintain and update the register of information
NIS2
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.
NIS2 Article 21 requires supply-chain security and consideration of supplier vulnerabilities and cybersecurity practices.
vulnerabilities specific to each direct supplier and service provider
Operational implication
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.
DORA Lead Overseer powers apply to critical ICT third-party service providers, including recommendations on security, service terms, and subcontracting.
NIS2 authorities may request documented cybersecurity policies, access to data and documents, and evidence of implementation.
requests for evidence of implementation
Operational implication
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.
NIS2 evidence should remain tied to Article 21 and Article 23 compliance.
documented cybersecurity policies
Management accountability and board oversight
DORA
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.
DORA Article 5 assigns detailed governance duties to the financial entity management body.
define, approve, oversee and be responsible
NIS2
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.
NIS2 Article 20 covers management-body approval, oversight, liability, and training.
can be held liable for infringements
Operational implication
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.
NIS2 requires management training so leaders can identify risks and assess cybersecurity risk-management practices.
identify risks and assess cybersecurity risk-management practices
Enforcement
DORA
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.
DORA Articles 46, 47, 34, and 35 describe financial competent authorities, cooperation with NIS2 bodies, the Joint Oversight Network, and Lead Overseer powers.
set up a JON to coordinate among themselves
NIS2
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.
NIS2 Articles 31 to 33 describe supervision and enforcement for essential and important entities.
effectively supervise and take the measures necessary
Operational implication
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.
NIS2 requires cooperation between NIS2 authorities and DORA authorities for relevant incidents, cyber threats, and critical ICT third-party providers.
cooperate with the relevant competent authorities
Overlap and reuse
DORA
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.
DORA expressly creates cooperation mechanisms with the NIS2 Cooperation Group, CSIRTs, and competent authorities.
consult and share information
NIS2
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.
NIS2 preserves the DORA sector-specific route while maintaining information exchange with the financial sector.
maintain a strong relationship and the exchange of information
Operational implication
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.
NIS2 Recital 28 supports overlap handling: DORA applies instead for covered financial entities, while incident details and cyber-threat information can flow to NIS2 bodies.
transmit details of major ICT-related incidents
Practical decision rule
DORA
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.
DORA provides the financial-sector operational resilience rule set for the left-side decision.
continued provision of financial services
NIS2
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.
NIS2 provides the cross-sector cybersecurity rule set for essential and important entities outside the DORA replacement path.
high common level of cybersecurity
Operational implication
For each legal entity, supplier, and incident, record DORA scope, NIS2 national scope, the displaced and surviving provisions, reporting routes, and evidence-reuse limits.
DORA Article 47 keeps cooperation with NIS2 bodies visible when assigning the workstream.
effective and fast-response coordination mechanisms
Practical decision rule
How to decide which workstream owns the issue
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.
NIS2 provides the cross-sector basis for assigning essential and important entity cybersecurity and incident-reporting work.
essential and important entities
1
Section 1
The practical difference for financial entities
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 establishes the financial-sector framework for ICT risk management, incident reporting, resilience testing, information sharing, and ICT third-party risk.
digital operational resilience for the financial sector
NIS2 states that DORA is the sector-specific Union legal act for covered financial entities and keeps cooperation links with CSIRTs and NIS2 authorities.
should be considered to be a sector-specific Union legal act
Explains the DORA displacement for overlapping NIS2 risk-management, reporting, supervision, and enforcement provisions and identifies the NIS2 cooperation and crisis mechanisms that continue to apply.
2
Section 2
Incident reporting is not interchangeable
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.
This DORA RTS specifies incident-classification criteria and materiality thresholds, including client impact, downtime, geographical spread, data losses, critical services, and economic impact.
criteria for the classification of ICT-related incidents
NIS2 Article 23 sets the significant-incident notification sequence for essential and important entities.
without undue delay and in any event within 24 hours
3
Section 3
Third-party and supply-chain evidence differs
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.
This ITS sets standard templates for the DORA register of information and explains why register data supports entity risk management, supervision, and critical provider oversight.
standard templates for the register of information
NIS2 Article 21 includes supply-chain security, secure acquisition and maintenance, vulnerability handling, access control, asset management, and authentication measures.
supply chain security
4
Section 4
Management accountability and supervisory model
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.
NIS2 Article 20 covers management-body approval, oversight, liability, and training for essential and important entities.
approve the cybersecurity risk-management measures
Recommended next step
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.
Primary NIS2 legal text for essential and important entity scope, Article 21 cybersecurity measures, Article 23 incident reporting, management accountability, supervision, and the DORA overlap rule.
NIS2 states that DORA is the sector-specific Union legal act for covered financial entities and keeps cooperation links with CSIRTs and NIS2 authorities.
NIS2 Article 23 sets the significant-incident notification sequence for essential and important entities.
Show 20 more
NIS2 Article 21 includes supply-chain security, secure acquisition and maintenance, vulnerability handling, access control, asset management, and authentication measures.
NIS2 Article 20 covers management-body approval, oversight, liability, and training for essential and important entities.
NIS2 classifies entities as essential or important and uses annexed sector lists plus Member State identification and registration mechanisms.
NIS2 Recital 28 expects DORA incident details to be transmitted or made immediately accessible to NIS2 bodies while DORA remains the financial-sector reporting route.
NIS2 Article 21 requires supply-chain security and consideration of supplier vulnerabilities and cybersecurity practices.
NIS2 supervision can also apply to an ICT provider that is an essential or important entity in its own right.
NIS2 authorities may request documented cybersecurity policies, access to data and documents, and evidence of implementation.
NIS2 evidence should remain tied to Article 21 and Article 23 compliance.
NIS2 Article 20 covers management-body approval, oversight, liability, and training.
NIS2 requires management training so leaders can identify risks and assess cybersecurity risk-management practices.
NIS2 Articles 31 to 33 describe supervision and enforcement for essential and important entities.
NIS2 requires cooperation between NIS2 authorities and DORA authorities for relevant incidents, cyber threats, and critical ICT third-party providers.
NIS2 preserves the DORA sector-specific route while maintaining information exchange with the financial sector.
NIS2 Recital 28 supports overlap handling: DORA applies instead for covered financial entities, while incident details and cyber-threat information can flow to NIS2 bodies.
NIS2 provides the cross-sector cybersecurity rule set for essential and important entities outside the DORA replacement path.
NIS2 Recital 28 is the core overlap rule for covered financial entities.
NIS2 provides the cross-sector basis for assigning essential and important entity cybersecurity and incident-reporting work.
"high common level of cybersecurity across the Union"
More quoted passages
"should be considered to be a sector-specific Union legal act"
"without undue delay and in any event within 24 hours"
"supply chain security"
"approve the cybersecurity risk-management measures"
"essential entities and important entities"
"technical, operational and organisational measures"
"prevent or minimise the impact of incidents"
"a final report not later than one month"
"immediate access to incident notifications"
"vulnerabilities specific to each direct supplier and service provider"
"essential and important entities"
"requests for evidence of implementation"
"documented cybersecurity policies"
"can be held liable for infringements"
"identify risks and assess cybersecurity risk-management practices"
"effectively supervise and take the measures necessary"
"cooperate with the relevant competent authorities"
"maintain a strong relationship and the exchange of information"
Primary DORA legal text for financial-entity scope, ICT risk management, incident reporting, resilience testing, ICT third-party risk, supervision, and cooperation with NIS2 authorities.
DORA establishes the financial-sector framework for ICT risk management, incident reporting, resilience testing, information sharing, and ICT third-party risk.
DORA Articles 17 to 19 require incident management, classification, and reporting of major ICT-related incidents by financial entities.
Show 17 more
DORA Articles 28 to 30 cover ICT third-party risk principles, concentration risk, and key contractual provisions for ICT services.
DORA Article 5 assigns management-body responsibility for ICT risk governance and requires regular knowledge and skills to understand ICT risk.
DORA Article 2 lists financial entities and ICT third-party service providers within its scope structure.
DORA Article 6 requires a sound, comprehensive, and well-documented ICT risk-management framework.
DORA ties ICT risk controls to the financial entity's operational resilience and services.
DORA Article 19 requires major ICT-related incident reporting by financial entities and states that outsourced reporting does not transfer responsibility.
DORA Articles 28 to 30 cover ICT third-party risk principles, concentration risk, and written contractual provisions.
DORA Lead Overseer powers apply to critical ICT third-party service providers, including recommendations on security, service terms, and subcontracting.
DORA requires documented ICT risk management, incident records, testing, third-party controls, and authority-accessible information.
DORA evidence should remain tied to ICT risk and operational resilience duties.
DORA Article 5 assigns detailed governance duties to the financial entity management body.
DORA requires management-body knowledge and skills to understand ICT risk and its operational impact.
DORA Articles 46, 47, 34, and 35 describe financial competent authorities, cooperation with NIS2 bodies, the Joint Oversight Network, and Lead Overseer powers.
DORA expressly creates cooperation mechanisms with the NIS2 Cooperation Group, CSIRTs, and competent authorities.
DORA provides the financial-sector operational resilience rule set for the left-side decision.
DORA Article 47 keeps cooperation with NIS2 bodies visible when assigning the workstream.
DORA provides the financial-sector basis for assigning ICT risk, incident, testing, and third-party work to the financial entity workstream.
"digital operational resilience for the financial sector"
More quoted passages
"Financial entities shall record all ICT-related incidents and significant cyber threats"
"management of ICT third-party risk"
"bear the ultimate responsibility for managing the financial entity’s ICT risk"
"entities referred to in paragraph 1, points (a) to (t), shall collectively be referred to as ‘financial entities’"
"sound, comprehensive and well-documented ICT risk management framework"
"ensure a high level of digital operational resilience"
"the financial entity remains fully responsible"
"full contract shall include the service level agreements"
"critical ICT third-party service providers"
"documented and reviewed at least once a year"
"provide complete and updated information"
"define, approve, oversee and be responsible"
"sufficient knowledge and skills to understand and assess ICT risk"
"set up a JON to coordinate among themselves"
"consult and share information"
"continued provision of financial services"
"effective and fast-response coordination mechanisms"
DORA ITS source for the register-of-information templates used to document ICT third-party service arrangements.
This ITS sets standard templates for the DORA register of information and explains why register data supports entity risk management, supervision, and critical provider oversight.
The DORA register ITS requires standard register templates for ICT service contractual arrangements and subcontractors supporting critical or important functions.
Show 1 more
The register ITS specifies standard data structures for ICT third-party contractual arrangements.
"standard templates for the register of information"
More quoted passages
"maintain and update the register of information"
"complete all data elements in the register of information"
Official Commission guidance on sector-specific Union acts, including the provisions displaced by DORA and the NIS2 cooperation, CSIRT, cyber-crisis, and EU-CyCLONe mechanisms that continue to apply.
Explains the DORA displacement for overlapping NIS2 risk-management, reporting, supervision, and enforcement provisions and identifies the NIS2 cooperation and crisis mechanisms that continue to apply.
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 RTS source for classifying major ICT-related incidents and significant cyber threats.
This DORA RTS specifies incident-classification criteria and materiality thresholds, including client impact, downtime, geographical spread, data losses, critical services, and economic impact.
DORA incident classification uses criteria including affected clients, duration, geographical spread, data losses, critical services, and economic impact.
"classification of ICT-related incidents"
More quoted passages
"criteria for the classification of ICT-related incidents"
"materiality thresholds for determining major incidents"