DORA: ICT Resilience for the Financial Sector Starting January 2025

TL;DR

• On January 17, 2025, the Digital Operational Resilience Act (DORA) will come into effect for financial institutions and key ICT service providers in the EU, establishing a mandatory framework for ICT risk management, incident handling, testing, and third-party risk.
• DORA complements the horizontal security framework of NIS2 as a specialized, sector-specific regulation for the financial sector—with stricter, more detailed requirements for governance, testing (including TLPT), and ICT third-party control.
• Threat-Led Penetration Testing (TLPT) according to TIBER-EU will become mandatory for large and systemically important financial actors, requiring structured, intelligence-led red teaming against real threat scenarios.
• ICT third-party risk takes center stage: A complete register, systematic due diligence, clear exit strategies, and contractually secured audit and control rights become core requirements of digital resilience.
• ayedo supports financial institutions with a DORA compliance workshop, ISO-27001-oriented operational models, Cloud-Native platform expertise, and concrete preparation for TLPT to pragmatically implement technical and organizational requirements.

DORA from January 2025: What Financial Institutions Can Expect

With Regulation (EU) 2022/2554, the EU is establishing a unified, binding framework for the digital operational resilience of financial institutions for the first time. DORA targets nearly all actors in the financial sector: credit institutions, payment service providers, insurers, investment firms, market infrastructures, and—most importantly—critical ICT third-party providers.

Formally, DORA has been in force since January 16, 2023. However, the crucial date for you is January 17, 2025, when the application obligation begins. From this date, supervisors and auditors will specifically ask how you manage ICT risks, report incidents, test your digital resilience, and manage your ICT third parties.

DORA does not view digital resilience as purely a technical task. It combines:

• Governance and board responsibility
• ICT risk management throughout the entire lifecycle
• Harmonized reporting of significant ICT incidents
• Systematic testing up to Threat-Led Penetration Testing
• Strict requirements for ICT third parties and their oversight at the EU level

This creates what has long been missing in the European financial sector: a coherent standard instead of a patchwork of national regulations. For technically responsible executives, this is an opportunity to finally place security, resilience, and regulatory compliance on a unified foundation.

DORA and NIS2: General Framework vs. Financial Sector-Specific Norm

With NIS2, the EU has established a horizontal minimum standard for cybersecurity in critical and important sectors—from healthcare to energy to digital infrastructures. DORA is the lex specialis for the financial sector.

Key points in the relationship between DORA and NIS2:

• Scope
  NIS2 addresses a wide range of critical sectors. DORA focuses exclusively on financial entities and their ICT third-party providers.

• Level of Detail
  NIS2 defines general requirements for risk management, incident reporting, and business continuity. DORA goes significantly deeper: specific requirements for financial supervision, reporting channels, digital resilience testing (including TLPT), and third-party risk.

• Application in Case of Conflict
  For financial institutions: Where DORA defines specific requirements, DORA takes precedence over NIS2. However, NIS2 remains relevant as a background framework—especially where DORA deliberately remains open or refers to other standards.

In practice, this means: If your institution has already started NIS2 preparations, many components (e.g., incident processes, BCP, basic ICT security measures) are reusable. DORA complements and sharpens these components for the financial context, especially in testing and third-party areas.

The Five Core Pillars of ICT Resilience According to DORA

DORA structures the requirements into five central pillars. For technically responsible individuals, it is worthwhile to plan and report precisely within these pillars.

1. ICT Risk Management as a Top Priority

DORA makes it clear: Responsibility lies with the board. ICT risk management must:

• define a documented strategy and risk tolerance,
• include a complete inventory of ICT assets, business processes, and dependencies,
• cover protection, detection, response, and recovery measures,
• be based on regular assessments, tests, and audits,
• be reported to management via defined KPIs/KRIs.

From a technical perspective, this means that topics such as asset transparency, network segmentation, access management, backup strategy, and monitoring are no longer just “best practice” but regulatory obligations—including traceable documentation.

2. Harmonized Incident Reporting

Previously, reporting obligations for ICT incidents were fragmented: data protection, supervision, national CERTs—often with different thresholds and formats. DORA harmonizes for the financial sector:

• Definition of a “major ICT incident” based on an EU-wide uniform criteria catalog,
• clear reporting channels to the competent authority,
• coordinated communication with CSIRTs, data protection, and law enforcement authorities,
• uniform taxonomy and minimum content of reports.

For your organization, this means: A consistent incident management process that brings together technical, operational, and regulatory requirements becomes mandatory. The interfaces between SOC, IT, compliance, and legal must be defined and practiced.

3. Digital Resilience Testing—from Scans to TLPT

DORA requires a graduated testing program that matches the size and criticality of your institution. This includes:

• regular vulnerability assessments and security tests,
• tests of business continuity and disaster recovery plans,
• targeted scenario tests (e.g., ransomware, cloud failure, supplier disruption),
• for large/systemically important institutions: Threat-Led Penetration Testing (TLPT) according to TIBER-EU methodology.

The systematic nature is crucial: Tests must be planned, documented, evaluated, and linked to clear actions and re-tests. “Once-a-year penetration test” will no longer meet the requirements.

4. ICT Third-Party Risk as a Core Component

Outsourcing does not mitigate responsibility—DORA explicitly emphasizes this. Core elements are:

• an ICT third-party strategy with clear principles and risk tolerance,
• a comprehensive register of all ICT service providers, including subcontractors,
• structured due diligence processes before contract conclusion,
• minimum contract contents (SLAs, security requirements, audit and access rights, exit clauses),
• regular assessment of concentration risks (e.g., strong dependence on a few hyperscalers).

This makes ICT third-party management a central component of ICT governance, not just a procurement issue.

5. EU Oversight for Critical ICT Providers

A novelty is the direct EU oversight of ICT third-party providers classified as “critical,” such as large cloud or infrastructure service providers:

• European supervisory authorities (EBA, EIOPA, ESMA) assume a “Lead Overseer” role.
• They receive investigative, inspection, and directive powers over these providers.
• Third-country providers must provide a sufficiently equipped EU subsidiary to ensure oversight and enforcement.

For financial institutions, this strengthens their position: Requirements for transparency, auditability, and exit capability can no longer be dismissed as “non-negotiable.”

Threat-Led Penetration Testing (TLPT) According to TIBER-EU

For large banks, market infrastructures, and other systemically important actors, Threat-Led Penetration Testing (TLPT) is a central component of DORA. Many institutions face a new quality of testing here.

Concept: Tests Along Real Attacker Profiles

TLPT is based on the TIBER-EU methodology of the ECB and aims to simulate real attackers as closely as possible. Core elements:

• Threat Intelligence: Relevant attacker groups, tactics, techniques, and procedures (TTPs) are analyzed.
• Critical Functions: The focus is on business processes and systems whose failure would endanger financial stability or critical services.
• Red-Teaming: A specialized team attempts to penetrate the defined targets along the identified TTPs, ideally without the defenders’ prior knowledge.

This shifts the focus from purely technical vulnerability scans to holistic resilience tests: Can attackers move laterally? Are they detected? How quickly is the response? Do the response processes work?

Typical Process of a TLPT Program

A practical TLPT typically follows several phases:

1. Scoping and Governance
   Determining the scope, critical functions, involved stakeholders, and governance structure. Supervision is also involved early on.

2. Threat Intelligence
   Gathering and analyzing current threat information for your specific profile: business model, technology stack, geographical presence.

3. Test Planning and Scenario Design
   Deriving specific attack paths and scenarios, aligned with risk appetite and regulatory requirements.

4. Conducting the Red-Team Test
   Carrying out the simulated attacks over a defined period, closely accompanied by a “White Team” circle ensuring security and abort criteria.

5. Evaluation, Remediation, and Re-Test
   Detailed reports, technical and procedural measures, prioritization by risk—and, if necessary, re-tests to verify effectiveness.

For cloud-native environments, this means: Container orchestration, service meshes, secrets management, and CI/CD pipelines become part of the test object. Without a clear understanding of architecture and assets, TLPTs become unnecessarily complex and risky.

ICT Third-Party Risk: Register, Due Diligence, Exit Strategies

The management of ICT third parties is one of the areas most affected by DORA. A mere contract and procurement dossier is no longer sufficient.

Comprehensive ICT Third-Party Register

DORA requires a central register of all ICT services, which must include at least:

• Service providers, including subcontractors and data center locations,
• the supported business processes and ICT systems,
• classification of criticality (e.g., “critical or important functions”),
• essential contract parameters, SLAs, durations, and exit arrangements.

This register forms the basis for:

• Risk assessments at the service provider and portfolio level,
• Concentration risk analyses (e.g., dependence on a single cloud provider),
• Structured reporting to the board and supervision.

Technically responsible executives should ensure that this register is closely linked to existing CMDBs, architecture overviews, and cloud accounts, rather than building an isolated Excel landscape.

Due Diligence as an Ongoing Process

Due diligence does not end with the signing of the contract. A continuous process is required:

• before contract conclusion: technical and organizational security assessments, compliance status (e.g., ISO 27001, SOC reports), resilience and recovery capabilities,
• during the term: regular reviews, reports, audits, penetration tests, proof of incident response capability,
• in case of significant changes: reassessment, such as platform migrations, operator changes, or changed operating models.