DORA: ICT Risk Management Requirements for Financial Entities

The Digital Operational Resilience Act became fully applicable across EU financial institutions in January 2025, establishing the most comprehensive ICT risk management framework the financial sector has seen. DORA applies to a broad range of entities: banks, investment firms, payment institutions, insurance companies, crypto-asset service providers, and — critically — the ICT third-party service providers that serve them.

For CISOs in the financial sector, DORA is not simply another compliance layer on top of existing frameworks. It establishes specific technical requirements, mandatory testing regimes, and a new oversight category for critical third-party ICT providers that changes the risk landscape for vendor management.

The Five Pillars of DORA

DORA organizes its requirements around five workstreams. Understanding the interplay between them is essential for program design.

1. ICT Risk Management

The foundational requirement is a comprehensive ICT risk management framework that is integrated into the organization’s overall risk management structure and approved at board level. This is not a technology function — DORA explicitly places responsibility on the management body, which must have sufficient understanding of ICT risk to provide effective oversight.

The ICT risk management framework must include: an ICT asset inventory with classification by criticality; a threat landscape assessment updated at least annually; documented risk tolerance and appetite; a set of ICT security policies covering network security, data management, access controls, and incident management; and formal procedures for change management, vendor management, and business continuity.

The testing requirement embedded in the risk management pillar is significant: all critical ICT systems and processes must be tested at least annually through baseline testing (vulnerability assessments, network security scans, gap analyses) and, for significant entities, through more advanced threat-led penetration testing (TLPT).

2. ICT-Related Incident Management, Classification, and Reporting

DORA introduces a mandatory incident classification framework. Financial entities must categorize ICT-related incidents as “major” based on criteria including the number of clients affected, the duration of the incident, geographic spread, economic impact, and reputational significance.

Major incidents trigger mandatory reporting to the relevant supervisory authority, with timelines that parallel and in some cases overlap with NIS2 reporting:

• Initial notification: within 4 hours of classification as major (and no later than 24 hours after becoming aware)
• Intermediate report: within 72 hours of the initial notification
• Final report: within one month of the incident being resolved

The classification process itself must be documented and consistently applied. Supervisors will scrutinize classification decisions — organizations that systematically classify incidents as non-major to avoid reporting obligations will face enforcement exposure.

A notable addition is the voluntary reporting of significant cyber threats. Even if an attack does not result in an incident, DORA encourages (and in some cases requires) notification where a threat was capable of causing significant disruption. This creates intelligence-sharing obligations that go beyond conventional incident reporting.

3. Digital Operational Resilience Testing

This pillar distinguishes DORA from most prior regulatory frameworks in terms of prescriptiveness. All financial entities must conduct baseline digital resilience testing annually. For significant entities — as defined by national competent authorities — DORA mandates Threat-Led Penetration Testing (TLPT) at least every three years.

TLPT under DORA follows the TIBER-EU framework, which requires engagement of an accredited threat intelligence provider and a licensed penetration testing firm to simulate advanced persistent threat scenarios against live production environments. This is not a standard penetration test — it involves a threat intelligence phase, a red team exercise targeting the organization’s actual crown jewels, and a purple team retrospective.

The TLPT obligation extends to critical ICT third-party providers: financial entities may be required to include their critical vendors in the scope of TLPT exercises. This creates new contractual and operational demands on vendor relationships.

4. ICT Third-Party Risk Management

Third-party risk management is arguably the most operationally significant pillar of DORA for most organizations. Financial entities must maintain a complete register of all ICT third-party service providers, with enhanced documentation for those supporting critical or important functions.

Contracts with ICT third-party providers supporting critical functions must include mandatory provisions: full service level descriptions, data location and security requirements, audit rights, incident notification obligations, business continuity and exit provisions, and sub-contracting disclosure requirements.

DORA introduces concentration risk as a regulatory concern. Financial entities must assess their exposure to single-provider dependencies and report concentration risks to supervisors. Where critical functions depend on a single ICT provider — particularly a single cloud provider — regulators will scrutinize the resilience implications.

Exit strategies are required for all critical ICT provider relationships. The strategy must be documented, tested, and feasible within a timeframe that does not compromise the continuity of critical functions. Given the practical difficulty of migrating away from major cloud and SaaS providers, this requirement is generating significant attention in the sector.

5. Information Sharing

DORA creates a legal basis for financial entities to participate in voluntary cyber threat intelligence sharing arrangements among themselves. Participation is encouraged and must be structured to protect confidential information while enabling meaningful exchange of threat indicators, attack patterns, and incident data.

Supervisory authorities may publish anonymized aggregate statistics based on reported incidents. This creates a feedback loop that is intended to improve sector-wide resilience over time.

The Critical Third-Party Provider Oversight Regime

One of DORA’s most novel elements is the establishment of direct supervisory oversight over ICT third-party providers designated as “critical.” The European Supervisory Authorities (EBA, EIOPA, ESMA) — acting through the Joint Oversight Network — can designate cloud providers, data analytics firms, and other ICT providers as critical and subject them to direct regulatory oversight.

Designated critical providers must: undergo audits and inspections by the Joint Oversight Network, comply with recommendations issued by supervisors, and potentially face penalties for non-compliance — even though they are not themselves financial entities regulated by financial supervisors.

This is a significant expansion of regulatory reach. Cloud providers and major SaaS vendors that serve the financial sector are now operating in a supervised environment, even if the supervision is indirect. Financial sector CISOs should track designation decisions as they are made, as they affect the compliance obligations of both the vendor and the financial entities using their services.

DORA and NIS2: Navigating the Overlap

Financial entities in the EU face both DORA and NIS2 requirements. The regulatory framework has established that where DORA provides sector-specific requirements that are at least as stringent as NIS2, DORA takes precedence — the lex specialis principle.

In practice, this means financial entities should structure their compliance programs primarily around DORA, using NIS2 as a reference for any areas where DORA does not provide equivalent specificity. The incident reporting timelines differ slightly (DORA’s 4-hour initial notification vs. NIS2’s 24-hour early warning), and DORA’s requirements should govern for entities subject to both.

For group structures with entities across multiple EU member states and sectors — financial holding companies with technology subsidiaries, for example — careful legal analysis is required to determine which requirements apply to which entities.

Implementation Priorities for 2026

Organizations that have been in DORA compliance mode since the January 2025 applicability date now need to shift from initial implementation to operational maturity. The areas most likely to attract supervisory scrutiny in 2026 examination cycles:

ICT incident classification and reporting. Early-stage implementation frequently reveals inconsistency in classification decisions. Supervisors will test whether organizations are applying the criteria rigorously and whether reporting timelines are being met.

Third-party register completeness. Many organizations discovered during initial DORA implementation that their vendor inventory was less complete than expected. The register must be maintained as a live document, not a point-in-time assessment.

TLPT scheduling. For significant entities, the three-year TLPT cycle is underway. Given the lead time required for TIBER-EU exercises — finding accredited providers, scoping, threat intelligence phase — organizations should be planning their first TLPT exercise now if they have not begun.

Exit strategy documentation. This remains one of the least mature areas across the sector. Realistic, tested exit strategies for critical cloud and SaaS dependencies require significant work that most organizations have deferred.

DORA has raised the floor for ICT risk management in the financial sector. CISOs who treat it as a compliance obligation will spend the next several years on the back foot with regulators. Those who use it as a framework for genuine operational resilience improvement will find that the board engagement, vendor management discipline, and testing requirements it mandates are good security practice regardless of the regulatory context.