DORA vs NIS2: understanding the overlap for financial firms

Two frameworks, one compliance question

Financial firms operating in the EU are subject to two overlapping cybersecurity and operational resilience frameworks that both became applicable in 2025. The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, has applied in full since 17 January 2025. The Network and Information Security Directive (NIS2), Directive (EU) 2022/2555, required transposition into national law by 17 October 2024, with a two-year implementation period running to October 2026.

Both frameworks impose governance obligations, risk management requirements, incident reporting obligations, and third-party oversight expectations. For compliance teams at financial firms, the natural question is whether these frameworks require separate compliance programmes, or whether meeting one satisfies the other.

The answer is that DORA takes precedence where the two frameworks overlap, but does not eliminate all NIS2 obligations. Understanding where that boundary sits, and what remains after it, is the practical compliance problem this article addresses.

For background on how DORA’s core requirements work in practice, see DORA compliance checklist for financial entities. For context on the broader EU regulatory landscape, see EU financial regulation in 2026: what it covers, who it affects, and why horizon scanning matters.

This article is for informational purposes only and does not constitute legal advice. Consult a qualified legal professional for advice specific to your situation.

What each framework covers

DORA is a regulation, not a directive. It applies directly and uniformly across all EU member states from 17 January 2025 without requiring national transposition. It covers 21 categories of financial entities, including credit institutions, investment firms, payment institutions, electronic money institutions, crypto-asset service providers (CASPs), insurance and reinsurance undertakings, pension funds, central counterparties, and trading venues. It also creates direct oversight obligations for ICT third-party service providers designated as critical by the European Supervisory Authorities (ESAs).

DORA’s subject matter is digital operational resilience: the ability of financial entities to withstand, respond to, and recover from ICT-related disruptions. It is prescriptive. It specifies in detail what an ICT risk management framework must contain, how incidents must be classified and reported, what testing methodologies are acceptable, what must be in ICT third-party contracts, and what oversight of those providers must look like.

NIS2 is a directive. Each EU member state was required to transpose it into national law by 17 October 2024, which means the specific rules vary slightly by jurisdiction, though the objectives are harmonised. NIS2 covers a wide range of critical sectors, including energy, transport, health, water, digital infrastructure, and financial services, among others. Within financial services, it applies to credit institutions, financial market infrastructure operators, and operators of certain digital services.

NIS2 is less prescriptive than DORA. It sets objectives and principles around cybersecurity risk management, incident reporting, supply chain security, and governance accountability, but leaves significant implementation discretion to entities and member states.

The lex specialis principle and what it means in practice

Article 1(2) of DORA explicitly states that it constitutes a lex specialis to NIS2 for entities within its scope. Lex specialis is a legal principle: the more specific rule takes precedence over the more general rule on the same subject matter.

For financial entities that are subject to both frameworks, this means that where DORA and NIS2 address the same topic, DORA’s requirements are the binding ones. A financial firm that is fully compliant with DORA’s ICT risk management requirements does not need to separately satisfy NIS2’s equivalent risk management obligations. DORA’s requirements are more detailed and in most areas more demanding. Meeting the stricter standard satisfies the less strict one.

This is not an exemption from NIS2. It is a displacement mechanism. NIS2 still applies to financial entities in principle; it simply yields to DORA on the specific areas where their requirements overlap. On matters that DORA does not address, NIS2 may still create obligations.

The practical implication is that financial entities should not maintain two parallel compliance programmes. A single compliance framework built around DORA’s requirements will, in most cases, satisfy the equivalent NIS2 obligations. What requires attention is the residual gap: the areas where NIS2 adds obligations that DORA does not cover.

Where the frameworks align

The overlap between DORA and NIS2 is substantial. Both frameworks require:

Governance and senior management accountability. Both impose direct accountability on management bodies for cybersecurity and resilience governance. Under DORA, the management body must approve the ICT risk management framework and bear responsibility for its adequacy. NIS2 similarly requires senior management to approve risk management measures and imposes personal liability for compliance failures.

ICT and cybersecurity risk management. Both require a documented risk management framework covering identification, protection, detection, response, and recovery. DORA’s version is significantly more detailed, with specific requirements on asset inventories, access control, business continuity planning, and the format of the framework itself.

Incident reporting. Both require notification of significant incidents to the relevant authority. The specific timelines and thresholds differ, but the underlying obligation is the same. DORA requires initial notification of major ICT-related incidents within four hours of classification, an intermediate report within 72 hours, and a final report within one month. NIS2 requires an early warning to the Computer Security Incident Response Team (CSIRT) within 24 hours, a full notification within 72 hours, and a final report within one month.

Third-party and supply chain risk. Both require entities to manage the cybersecurity risks arising from their dependence on third-party providers. DORA is substantially more prescriptive, requiring a formal register of ICT third-party arrangements, mandatory contractual provisions, ongoing monitoring, and documented exit strategies. NIS2 requires appropriate measures to manage supply chain risk but leaves implementation much more open.

Resilience testing. Both frameworks expect regular testing of systems and controls. DORA specifies the types of testing required, including vulnerability assessments, network security assessments, and threat-led penetration testing (TLPT) for systemically significant entities. NIS2 expects testing as part of risk management but does not define the methodology in equivalent detail.

In each of these areas, a DORA-compliant programme will satisfy the equivalent NIS2 obligation. The reverse is not true. NIS2-level compliance does not meet DORA’s requirements.

Where NIS2 adds obligations DORA does not cover

The lex specialis principle does not eliminate all NIS2 obligations for financial entities. There are areas where NIS2 addresses matters that fall outside DORA’s scope.

National CSIRT coordination. NIS2 creates an explicit reporting and coordination relationship with national CSIRTs. DORA’s incident reporting runs to the national competent authority (the financial regulator), not the CSIRT. Financial entities subject to both frameworks may face parallel reporting obligations to different authorities on the same incident, on different timelines. The DORA initial notification (four hours) is faster than the NIS2 early warning (24 hours), so a single incident process that triggers the DORA timeline will generally satisfy both, but the routing to different recipients requires deliberate process design.

Physical security elements. NIS2 includes provisions relating to physical and environmental security that DORA does not address in equivalent detail. The extent to which these create additional obligations in practice depends on the nature of the entity’s operations and the national implementing legislation.

Non-financial activities. A financial entity that also operates infrastructure or services that fall under NIS2’s essential or important entity classifications in a non-financial context may face NIS2 obligations on those activities that DORA does not address. Large, diversified financial groups may need to map this carefully.

ICT providers that are not financial entities. DORA regulates financial entities and imposes contractual requirements on their ICT third-party providers. It directly supervises providers designated as critical by the ESAs, a list that covered 19 providers as of late 2025. ICT providers that serve financial entities but are not themselves financial entities are subject to NIS2 directly as digital infrastructure entities or managed service providers, in addition to the contractual obligations that flow through their financial entity customers. These providers face both frameworks independently and cannot rely on the lex specialis principle that applies to financial entities.

The incident reporting problem

The most operationally significant area of complexity is incident reporting. A single ICT incident at a financial entity may simultaneously trigger:

• DORA initial notification: within four hours of classification as major, to the national competent authority
• NIS2 early warning: within 24 hours, to the national CSIRT
• GDPR breach notification: within 72 hours of becoming aware, to the data protection authority

These obligations run on different timelines to different recipients and use different classification criteria. The DORA classification test turns on factors including the number of clients affected, the duration of the disruption, the geographic spread, and the data impact. The NIS2 threshold is whether the incident has a significant impact on the provision of services. The GDPR trigger is a personal data breach.

The practical response is to design a single incident management process that evaluates all three thresholds at the point of detection, runs parallel notifications where required, and maintains documentation of the classification decisions for each framework. The DORA timeline drives the pace: an incident that may be a DORA major incident must be assessed within four hours. Waiting to assess GDPR and NIS2 implications after the DORA notification is sent is a workable sequence, provided the process captures the right information at detection.

What financial entities should do

For most financial entities, the starting point is confirming whether they fall within DORA’s scope. The 21 entity categories in Article 2(1) of DORA are broad, but not universal. If an entity is within DORA’s scope, it should treat DORA as the primary compliance framework for ICT risk, incident reporting, testing, and third-party oversight.

The second step is conducting a gap analysis against the residual NIS2 obligations that DORA does not address: national CSIRT reporting, physical security provisions relevant to the entity’s operations, and the national implementing legislation in each member state where the entity operates. NIS2 is a directive, and national implementation varies. An entity operating across multiple EU jurisdictions needs to understand how each member state has implemented NIS2 and whether any jurisdiction-specific requirements add to what DORA mandates.

The third step is designing a single integrated incident process that covers DORA, NIS2, and GDPR in sequence, with clear triggers, timelines, and routing for each notification obligation.

For ICT providers that serve financial entities but are not themselves financial entities, the analysis is different. These firms cannot rely on the lex specialis principle. They face DORA contractual obligations through their financial entity customers, and they face NIS2 obligations independently. Both compliance workstreams are required.

What to watch

NIS2 transposition is incomplete across EU member states as of early 2026. Not every member state had implemented NIS2 into national law by the October 2024 deadline, and national implementations vary in how they handle the interaction with DORA. The European Commission has been monitoring transposition progress, and enforcement timelines differ by jurisdiction.

DORA enforcement is also developing. The full application period began in January 2025, and national competent authorities are at different stages of readiness to conduct DORA-specific supervisory assessments. Supervisory guidance on the interaction between DORA and NIS2 continues to develop at both the ESA level and the national level.

For entities that are genuinely uncertain whether they fall under both frameworks or only one, the answer is jurisdiction-specific and entity-specific. The lex specialis principle is clear as a matter of EU law, but its practical application to specific situations requires legal advice, not a general explainer.

Forseti monitors DORA and NIS2 implementation developments, enforcement guidance, and national transposition progress continuously, anchored to verified official sources. Start for free.