DORA for the Financial Sector: What Comes After NIS2?

TL;DR

DORA (Digital Operational Resilience Act) is an EU regulation that has been directly applicable since January 17, 2025, and covers the entire financial sector: banks, insurers, investment firms, payment service providers, and their critical ICT service providers.
DORA is sector-specific and takes precedence over NIS2 as lex specialis. Financial entities must comply with DORA, not NIS2, though the underlying principles overlap significantly.
The five pillars of DORA are: ICT risk management, incident reporting, resilience testing (including TLPT), third-party risk management, and information sharing.
Third-party risk management is particularly demanding: financial entities must maintain a complete register of all ICT service providers and identify and manage critical dependencies.
Threat-Led Penetration Testing (TLPT) based on the TIBER-EU framework is mandatory for systemically important financial entities every three years and requires significant resources.

DORA and NIS2: Why the financial sector needs its own regulation

If you work in the financial sector, you've experienced two major regulatory waves in recent years: NIS2 and DORA. Both address cybersecurity and operational resilience, but they do so in different ways and with different levels of detail.

NIS2 is a directive that must be transposed into national law by member states. It targets organizations across industries in critical and important sectors, including the financial sector. NIS2 defines minimum requirements for cybersecurity, reporting obligations, and governance.

DORA is a regulation that applies directly and uniformly across all EU member states, without national transposition. It targets exclusively the financial sector and is significantly more detailed than NIS2. DORA defines not only "what" must be implemented, but in many areas also "how."

The relationship between the two is clearly defined: DORA takes precedence as lex specialis (sector-specific law) over NIS2 (general law). Financial entities that fully implement DORA automatically meet the sector-specific requirements that NIS2 would impose on them. So you don't need to implement both frameworks in parallel — focus on DORA.

Why does the financial sector need its own regulation at all? Because the financial sector's dependency on information and communication technology (ICT) is so great that a failure or compromise can have far-reaching consequences for financial stability. A major bank whose core banking system goes down for three days causes not only economic damage to itself but can trigger a chain reaction that disrupts the entire payment system. DORA addresses this systemic risk with a level of detail that NIS2, as a cross-industry regulation, cannot provide.

Who is affected by DORA?

DORA covers virtually the entire EU financial sector. Article 2 of the regulation lists 21 categories of financial entities:

Credit institutions (banks and savings banks)
Payment institutions and e-money institutions
Investment firms
Central securities depositories
Central counterparties (CCPs)
Trading venues
Trade repositories
Managers of alternative investment funds and UCITS management companies
Insurance and reinsurance undertakings
Insurance intermediaries
Institutions for occupational retirement provision
Credit rating agencies
Crowdfunding service providers
Crypto-asset service providers
Administrators of critical benchmarks

Additionally, DORA covers the ICT third-party service providers that work for financial entities. If your company provides IT services to banks, insurers, or other financial entities, you are indirectly affected by DORA because your clients must pass DORA requirements on to you.

An important exception: simplified requirements apply to small and less complex financial entities in certain areas. The exact delineation depends on the size, risk profile, and complexity of the entity.

The five pillars of DORA

DORA is structured around five thematic pillars that together form a comprehensive framework for digital operational resilience.

Pillar 1: ICT risk management (Articles 5 to 16)

The first and most extensive pillar defines the requirements for managing ICT risks. It requires a comprehensive, documented, and regularly updated ICT risk management framework.

Governance. The management body (board of directors, executive management) bears overall responsibility for ICT risk management. They must approve and oversee the ICT risk management framework, allocate sufficient resources, define the ICT strategy, and be regularly informed about ICT risks. This goes beyond what NIS2 requires in terms of governance and holds senior management accountable to a greater degree.

Identification. Financial entities must identify, classify, and document all ICT-supported business functions, ICT assets, data holdings, and dependencies. This includes a complete inventory of all ICT assets mapped to business functions and risk assessments.

Protection. DORA requires a comprehensive set of protective measures: access control, network security, cryptography, data security, physical security, and personnel security. Many of these requirements correspond to ISO 27001 Annex A, but DORA specifies them with sector-specific expectations.

Detection. Financial entities must implement mechanisms for detecting anomalous activities, including ICT-related incidents. DORA explicitly requires automated detection mechanisms and regular testing of detection capabilities.

Response and recovery. DORA requires business continuity plans for ICT-related disruptions, including recovery objectives (RTO and RPO), regular testing, and a crisis communication strategy. The requirements for backup and restore are significantly more detailed than in ISO 27001.

Learning and evolution. Financial entities must learn from ICT incidents and tests and continuously improve their measures. DORA requires post-incident reviews and the incorporation of findings into ICT risk management.

Pillar 2: ICT-related incident reporting (Articles 17 to 23)

DORA defines a unified reporting process for major ICT-related incidents.

Incident classification. Financial entities must classify ICT-related incidents according to defined criteria: number of affected clients, duration of the outage, geographic spread, data loss, impact on critical services, and economic damage. Incidents that exceed certain thresholds are classified as "major" and must be reported.

Reporting obligations. Major ICT-related incidents must be reported to the competent supervisory authority. The reporting process comprises three stages: an initial notification within four hours of classification as major (no later than 24 hours after detection), an intermediate report within 72 hours, and a final report within one month.

The reporting deadlines are tighter than under NIS2. The four-hour deadline after classification in particular requires that the incident classification process works quickly and reliably. An organization that takes half a day to decide whether an incident is major is already in breach of the reporting obligation.

Voluntary reporting of cyber threats. DORA also enables voluntary reporting of significant cyber threats to the supervisory authority, even if no incident has yet occurred.

Pillar 3: Digital operational resilience testing (Articles 24 to 27)

DORA requires a comprehensive testing program for digital operational resilience.

Basic testing. All financial entities must regularly conduct basic tests: vulnerability scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews (where possible), scenario-based tests, compatibility tests, performance tests, and end-to-end tests. The frequency and scope depend on the entity's risk profile.

Threat-Led Penetration Testing (TLPT). For systemically important financial entities, DORA requires threat-led penetration testing every three years based on the TIBER-EU framework. TLPT differs fundamentally from a standard penetration test: it simulates a realistic attack on the entity's production systems, based on current threat intelligence and conducted by specialized red team providers.

A TLPT comprises three phases: In the threat intelligence phase, a specialized provider creates a threat profile based on real threat actors that could target the entity. In the red team phase, an independent red team attempts to compromise the entity's critical functions based on this profile. In the purple team phase, the red team and the internal blue team work together to analyze findings and derive improvements.

TLPT is costly (typically EUR 200,000 to 500,000 per engagement) and organizationally demanding. It requires involvement of the supervisory authority, which oversees the entire process.

Pillar 4: ICT third-party risk management (Articles 28 to 44)

The fourth pillar is the biggest challenge for many financial entities. DORA sets comprehensive requirements for managing risks arising from the use of ICT service providers.

Information register. Financial entities must maintain a complete register of all contractual arrangements with ICT third-party service providers. The register must identify the service provider, describe the services provided, assess the criticality of the service, and document sub-outsourcing chains.

Due diligence and risk assessment. Before entering into a contract with an ICT third-party service provider, the financial entity must conduct due diligence, assess the risks, and ensure that the provider can meet the necessary security requirements.

Minimum contractual requirements. DORA defines detailed minimum requirements for contracts with ICT third-party service providers in Article 30. These include: service level descriptions, audit and access rights, cooperation obligations during incidents, data localization, exit strategies, and sub-outsourcing provisions.

Concentration risk. Financial entities must assess concentration risks: How dependent am I on a single ICT service provider? What happens if that provider fails? DORA requires financial entities to diversify their dependencies and maintain exit strategies.

Oversight framework for critical ICT third-party service providers. Particularly noteworthy is the new oversight framework for ICT third-party service providers classified as "critical" (typically large cloud providers and IT outsourcing providers that are systemically important for many financial entities). These providers are directly supervised by the European supervisory authorities (EBA, ESMA, EIOPA).

Pillar 5: Information sharing (Article 45)

DORA encourages financial entities to share information about cyber threats and vulnerabilities with each other and with supervisory authorities. This exchange should take place on trusted platforms and serves to collectively strengthen the cyber resilience of the financial sector.

Implementing DORA: The pragmatic approach

For most financial entities, implementing DORA is not a greenfield project. Most have already implemented regulatory requirements for IT security and operational resilience (BAIT, VAIT, KAIT, MaRisk, ISO 27001). The question is: what does DORA add, and where do gaps need to be closed?

Step 1: Conduct a gap analysis

Compare your existing measures, processes, and documentation against the DORA requirements. Identify the gaps. Typical areas where even well-prepared financial entities have catching up to do:

The complete ICT third-party register (often only an incomplete list exists)
Contractual requirements for ICT service providers (DORA-specific clauses are often missing)
Incident classification and reporting process per DORA criteria (often only generic)
Digital operational resilience testing program (often only vulnerability scans, not a comprehensive testing program)
TLPT readiness (for systemically important institutions)

Step 2: Adjust governance

Ensure that the management body knows and exercises its DORA responsibilities. This includes: approval of the ICT risk management framework, definition of the ICT strategy, regular reporting on ICT risks to the board, and ensuring sufficient resources and competencies.

Step 3: Update the ICT risk management framework

Revise your existing ICT risk management to cover DORA-specific requirements. This includes complete identification and classification of all ICT assets, assessment of dependencies between business functions and ICT systems, and definition of protective measures, detection mechanisms, and recovery processes.

Step 4: Build third-party risk management

The complete ICT third-party register is often the most resource-intensive task. Capture all contractual relationships, classify them by criticality, review the contractual provisions, and supplement missing DORA clauses. For critical ICT service providers, develop exit strategies and assess concentration risks.

Step 5: Implement the incident reporting process

Implement the three-stage reporting process with DORA-specific deadlines and classification criteria. In ISMS Lite, the incident reporting process can be mapped in a structured way so that the four-hour deadline doesn't fail due to missing documentation. Ensure the process also works outside business hours — ICT incidents don't stick to office hours.

Step 6: Set up a testing program

Create a multi-year testing program that covers the various test types (basic tests, advanced tests, TLPT) in a meaningful cadence. Start with a stocktake of tests already conducted and identify the gaps.

DORA and ISO 27001: Leveraging synergies

If you already operate an ISMS under ISO 27001, you have a solid foundation for DORA implementation. The overlap is estimated at 60 to 70 percent, depending on how mature your ISMS is.

What ISO 27001 already covers: ICT risk management fundamentals, protective measures (access control, cryptography, network security), incident management, business continuity, supplier management, and internal audits.

What DORA additionally requires: the detailed ICT third-party register, the specific reporting obligations and deadlines, the comprehensive testing program including TLPT, the explicit governance responsibility of the management body for ICT risks, and sector-specific detailed requirements in many areas.

The pragmatic strategy: use your existing ISMS as the foundation and supplement the DORA-specific requirements. You don't need to rebuild everything from scratch — close the gaps in a targeted manner.

Sanctions and supervision

DORA delegates oversight of compliance to the national financial supervisory authorities (in Germany primarily BaFin and the Bundesbank). The available sanctions include administrative measures and fines, the exact amounts of which are determined by member states through their national legislation.

What weighs heavier than fines: the supervisory authority can impose operational restrictions, such as prohibiting certain business activities or ordering the termination of contracts with ICT third-party service providers classified as a risk. For a financial entity, such an order can be existentially threatening.

The oversight framework for critical ICT third-party service providers is particularly noteworthy: the European supervisory authorities (EBA, ESMA, EIOPA) have the power to conduct direct examinations of critical ICT third-party service providers, issue recommendations, and impose sanctions for non-compliance. This primarily affects the major cloud providers (AWS, Azure, Google Cloud) that provide systemically important infrastructure for many financial entities.

Typical challenges in DORA implementation

The third-party register

For many financial entities, the complete ICT third-party register is the biggest operational challenge. The requirement sounds simple: capture all contractual relationships with ICT service providers. In practice, this means identifying every contract that has an ICT dimension, assessing criticality, documenting sub-outsourcing chains, and analyzing concentration risks.

A mid-market financial entity typically has 50 to 200 ICT service provider relationships. Many of these are known to central procurement or the IT department, but shadow IT (cloud services independently procured by business units) and indirect dependencies (subcontractors of your service providers) are often overlooked. Complete capture requires a systematic inventory involving all departments. It's not uncommon to also uncover shadow IT that had been flying under central IT's radar.

Exit strategies for critical service providers

DORA requires financial entities to maintain exit strategies for critical ICT service providers. This means: you must have a documented plan for how you can switch providers without materially impacting your business processes. For cloud migrations, this can mean ensuring multi-cloud capability, contractually agreeing on data portability, and regularly testing the feasibility of the exit strategy.

In practice, this is an enormous challenge for many financial entities, especially if they are deeply integrated into a single cloud provider's ecosystem. The exit strategy must be realistic and tested — a paper document describing a theoretical migration path is not sufficient.

Around-the-clock reporting processes

The four-hour deadline for the initial notification after classifying an incident as major requires that the incident response process works outside business hours as well. For mid-market financial entities without a 24/7 security operations center, this means: on-call duty, clear escalation paths, and pre-prepared reporting forms that can be quickly completed and submitted in an emergency.