NIS2 for the Financial Sector: Understanding the DORA Relationship

NIS2 and DORA for financial sector: understand how cybersecurity frameworks overlap for banks, payment institutions, and investment firms.

Daniel Grigorovich
Daniel Grigorovich
Founder · 22 May 2026 · 8 min read
NIS2
NIS2 for the Financial Sector: Understanding the DORA Relationship

Who should read this: Financial Services Leaders, Compliance Officers, Risk Officers, Banking IT Leaders.

The financial sector occupies a unique position in the NIS2 and broader EU regulatory landscape. Financial institutions are simultaneously subject to NIS2 (as essential service providers designated in Annex I, Sector 4) and to the Digital Operational Resilience Act (DORA), a sector-specific regulation addressing operational resilience in banking and finance.

This dual regulatory regime is intentional: NIS2 establishes a broad baseline for cybersecurity across critical sectors, whilst DORA provides more prescriptive, sector-specific requirements reflecting the systemic importance of financial markets and the need for coordinated regulatory response to financial sector cyber risk.

For compliance officers and risk leaders in financial services, understanding the NIS2-DORA relationship is essential. The two regimes have overlapping requirements (incident reporting, governance, risk management) but also distinct requirements (DORA specifies particular testing, third-party concentration limits, and operational resilience requirements). This post unpacks the NIS2-DORA relationship, clarifies their scope and interaction, and provides practical guidance on designing a compliance framework satisfying both.

NIS2 Designation: Financial Sector as Critical Infrastructure

Annex I, Sector 4 of NIS2 designates financial institutions as essential service providers. The sector includes:

  • Credit institutions (banks).
  • Investment firms.
  • Payment institutions.
  • Electronic money institutions.
  • Certain crypto-asset service providers.
  • Insurance companies (in some Member States).

The rationale for designation is clear: financial services are essential to the functioning of the EU economy. Disruption to banking systems, payment systems, or markets cascades rapidly through the economy. A ransomware attack affecting a major bank affects customers, businesses, and other financial institutions depending on the bank’s services.

As essential service providers, financial institutions are subject to NIS2’s core obligations: implementing proportionate cybersecurity measures, establishing governance, managing incident response, reporting significant incidents, and managing third-party cybersecurity risk (Articles 21-22).

DORA: Sector-Specific Operational Resilience

The Digital Operational Resilience Act (DORA), which began applying in 2023 and is being phased in through 2025, establishes comprehensive operational resilience requirements for financial entities. DORA’s scope is narrower than NIS2 (it applies only to regulated financial entities) but its requirements are more prescriptive.

DORA requires financial entities to:

Identify critical or important functions (CIFs): Functions that, if disrupted, would substantially affect the entity’s or the financial system’s operations.

Implement operational resilience measures protecting CIFs: Measures addressing people, processes, technology, and infrastructure.

Test operational resilience through advanced threat-led penetration testing (TLPT): Simulating adversary-led attacks to identify vulnerabilities and test response procedures.

Manage third-party operational resilience risk: With particular attention to concentration risk (dependence on a small number of providers) and to critical or important function outsourcing.

Report incidents, with distinct categories (operational or security incidents) and specific reporting timelines.

DORA’s requirements are more specific than NIS2’s. For example, DORA mandates TLPT annually (with some exemptions for smaller entities), whilst NIS2 uses the language of “proportionate” testing without prescribing particular methodologies.

Scope Overlap and Relationship

The relationship between NIS2 and DORA is hierarchical with some interplay:

All DORA-regulated entities (credit institutions, investment firms, payment institutions, and others) are also NIS2-designated essential service providers. A bank is subject to both NIS2 and DORA.

DORA is more prescriptive: it specifies particular requirements (TLPT, defined incident categories, third-party concentration limits) that NIS2 does not mandate. In areas where DORA is more prescriptive, DORA standards apply.

NIS2 has broader scope: it applies to financial institutions and also to other essential service providers (energy, healthcare, transport) not subject to DORA. For financial entities, NIS2 provides a baseline; DORA adds sector-specific requirements.

In practice, financial entities implement a compliance programme satisfying both frameworks. This is efficiently done: the programmes overlap substantially, so the incremental burden of satisfying both is manageable.

Governance and Board Accountability

Both NIS2 and DORA require board-level governance and senior management accountability for cybersecurity and operational resilience.

NIS2 requires that senior management establish cybersecurity governance structures, with clear accountability for risk management and incident response.

DORA requires that the board of directors approve, at least annually, an operational resilience strategy, that senior management implement the strategy, and that specific board-level oversight mechanisms address operational resilience. DORA also requires that the board receives regular reports on cyber incidents and testing results.

For financial institutions, these requirements are complementary. A single governance structure should address both cybersecurity (NIS2) and operational resilience (DORA), with board oversight of both.

Risk Assessment and Management

Both regimes require risk assessment and proportionate controls.

NIS2 (Article 21) requires implementation of proportionate technical and organisational measures based on risk assessment.

DORA requires identification of critical and important functions, assessment of dependencies and vulnerabilities affecting those functions, and implementation of resilience measures protecting them. DORA is more specific: it requires testing of resilience and documentation of assumptions underlying resilience measures.

For financial entities, risk assessment should map critical functions to underlying IT and operational systems, identify threats and vulnerabilities to those systems, and implement controls protecting critical functions. Proportionality, under both frameworks, depends on the criticality of the function: more critical functions receive more intensive testing and monitoring.

Incident Reporting: Distinct Categories Under DORA

An important distinction between NIS2 and DORA is in incident reporting:

NIS2 requires notification of “significant” incidents (meeting criteria in Article 23(3)) within 24 hours to competent authorities and CSIRTs.

DORA requires reporting of “operational or security incidents” with distinct thresholds and timelines. DORA defines “major incidents” (affecting critical functions, or meeting defined financial or operational impact thresholds) and requires reporting within specific timeframes (4 hours for some incidents).

For financial entities, the incident classification frameworks are distinct. An incident might be significant under NIS2’s criteria but not meet DORA’s major incident threshold, or vice versa. Both reporting obligations might be triggered by a single incident.

Financial entities should establish integrated incident response procedures that:

  • Assess incidents against both NIS2 and DORA criteria.
  • Determine which regulatory notifications are required.
  • Coordinate notification with regulators (ensuring that a single incident is not reported redundantly or contradictorily to different authorities).

Third-Party Risk Management and Concentration Risk

Both NIS2 and DORA require third-party risk management, but DORA adds specific provisions addressing concentration risk.

NIS2 (Article 22) requires that entities ensure third-party suppliers implement proportionate cybersecurity measures.

DORA requires detailed assessment of third-party operational resilience risk, with particular attention to:

Concentration risk: Where critical functions depend on a small number of providers. If a major cloud provider is compromised or fails, multiple financial institutions are affected. DORA requires that concentration risk be identified and, where possible, mitigated (e.g., through geographic diversity, service redundancy, or contractual concentration limits).

Critical or important function outsourcing: Where entities outsource critical functions (e.g., market data services, settlement systems), additional requirements apply, including prior authorisation and enhanced monitoring.

Subcontractor risk: Where third-party providers use subcontractors, concentration risk may cascade. DORA requires visibility into subcontractor arrangements.

For financial entities, a unified third-party management programme should address both NIS2 and DORA requirements. Vendor due diligence, contract requirements, and monitoring procedures should address both frameworks. Additionally, strategic decisions about which services to outsource, and to which providers, should account for concentration risk and operational resilience implications.

Testing and Operational Resilience Verification

DORA is more prescriptive about testing than NIS2. DORA requires:

Advanced threat-led penetration testing (TLPT): Annually (with exemptions for smaller entities), financial entities must conduct simulated attacks designed by external threat experts, testing the entity’s ability to detect and respond to advanced threats.

Scenario testing: Testing critical function resilience under defined scenarios (e.g., loss of a major provider, extended outages, cascading failures).

Incident response and recovery testing: Regular testing of incident response procedures and recovery processes.

NIS2 requires testing, but does not prescribe specific methodologies or frequencies. “Proportionate” testing might mean annual penetration testing for a large institution but quarterly testing for a smaller one.

For financial entities, DORA’s testing requirements set a floor. Entities should, at minimum, conduct DORA-required testing. Depending on size and risk profile, additional testing (e.g., more frequent penetration testing, cross-functional incident response drills) may be proportionate under NIS2.

Regulatory Oversight and Coordination

NIS2 and DORA are implemented through different regulatory channels:

NIS2 is implemented through national cybersecurity authorities, sectoral regulators, and competent authorities designated by Member States. Financial sector regulators (banking authorities, financial market authorities) often serve as competent authorities for NIS2 in the financial sector.

DORA is implemented through financial regulators: the European Central Bank (ECB) for banks within the Eurozone, the European Banking Authority (EBA) for payment institutions and investment firms, and other financial authorities.

There is significant overlap in regulators: a bank’s national regulator may serve as both the competent authority under NIS2 and the direct supervisor under DORA. This coordination is beneficial: a single regulator can assess compliance with both frameworks and coordinate oversight.

However, financial entities may receive requests from multiple regulatory bodies (NIS2 competent authority, CSIRT, DORA regulator, etc.). Clarifying which authority has authority over which aspects of compliance, and coordinating communication, is important.

Key Takeaways

  • Financial institutions are designated as essential service providers under NIS2 (Annex I, Sector 4) and are subject to more prescriptive requirements under DORA. All DORA-regulated entities are also NIS2-designated.
  • Both frameworks require governance, risk assessment, proportionate controls, incident reporting, and third-party risk management. NIS2 provides a baseline; DORA adds sector-specific requirements.
  • Incident reporting frameworks differ: NIS2 requires notification of significant incidents within 24 hours; DORA defines major incidents with distinct reporting timelines (e.g., 4 hours for certain incidents). Both may be triggered by a single incident.
  • DORA specifies testing requirements (annual TLPT, scenario testing) and concentration risk assessment more prescriptively than NIS2. These should be integrated into a comprehensive testing and operational resilience programme.
  • Third-party risk management should address both frameworks’ requirements, with particular attention to concentration risk under DORA (where critical functions depend on a small number of providers).
  • Board-level governance should address both cybersecurity (NIS2) and operational resilience (DORA), with integrated oversight procedures and regular reporting.
  • Regulatory oversight may be exercised by a single authority (the financial regulator serving as both NIS2 competent authority and DORA supervisor) or by multiple authorities. Coordination of regulatory communication is important.
Daniel Grigorovich

Daniel Grigorovich · Founder

I believe that no business should suffer from "compliance checklists" or navigating vague regulatory text. While I still stand by the principle that all software products should be reliable and secure, I want to give companies a way to overcome the challenges faced when implementing these requirements.