DORA vs NIS2 financial-sector obligations and overlap

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.

A regulated financial entity usually starts with DORA for ICT risk obligations. A non-financial affiliate, cloud provider, managed service provider, or another group entity may still need a separate NIS2 scope decision.

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.

Essential and important entities notify significant incidents to the CSIRT or competent authority: early warning within 24 hours, incident notification within 72 hours, intermediate updates on request, and a final report not later than one month after the incident notification.

Run separate incident classifications. A single outage involving a financial entity and a managed service provider can create a DORA major-incident workflow for the financial entity and a NIS2 significant-incident workflow for the provider.

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 essential or important entity and whether its customer-facing services are protected.

Keep the DORA scope analysis, ICT risk-management framework, resilience strategy, critical-or-important-function map, ICT asset and information-asset inventories, incident classification records, major-incident reports, test plans and results, register-of-information templates, ICT provider contracts, subcontractor assessments, exit plans, audit records, and management approvals.

Keep NIS2 entity classification, sector and size analysis, Article 21 control mapping, risk assessments, incident-handling procedures, business-continuity and crisis-management evidence, supplier-security files, vulnerability handling, cyber hygiene and training records, access-control and asset-management evidence, significant-incident notifications, and authority correspondence.

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 can be overseen through a Lead Overseer and Joint Oversight Network.

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.

The clean reuse rule is: share the control artifact, separate the legal conclusion. One outage, contract, or control test can support both regimes only after both scope tests and reporting tests are documented.

Apply DORA when the entity is a DORA financial entity and the work concerns ICT risk management, major ICT-related incident handling, resilience testing, information sharing, or ICT third-party risk for financial services or critical or important functions.

Apply NIS2 when the entity is an essential or important entity outside the DORA displacement rule, or when a provider, affiliate, country implementation, CSIRT notification, or national registration obligation independently falls under NIS2.

For each product, supplier, incident, and group entity, record four answers: DORA scope, NIS2 scope, reporting route, and evidence reuse limits.