DORA Compliance Guide for Financial Services: ICT Risk, Incident Reporting & Third-Party Risk

DORA became applicable on January 17, 2025, making it live regulation — not a future deadline to prepare for. If your firm is in scope and hasn't completed its ICT risk management framework, supplier contract review, or incident classification procedures, you are operating out of compliance today.

This guide covers what DORA actually requires, the deadlines that matter, and the ongoing monitoring challenge that most compliance teams underestimate.

Who DORA Applies To

DORA's scope is broader than most financial regulation. It covers:

• Credit institutions (banks)
• Payment institutions and e-money institutions
• Investment firms
• Crypto-asset service providers (CASPs) authorized under MiCA
• Insurance and reinsurance undertakings
• Pension funds
• Credit rating agencies
• Central counterparties (CCPs) and trading venues
• Data reporting service providers
• Crowdfunding service providers

Critically, DORA also creates a direct supervisory regime for critical ICT third-party providers (CTPPs) — cloud providers, software vendors, and data service firms that are designated as systemically important by the European Supervisory Authorities (ESAs). These firms face direct ESA oversight even if they aren't financial entities themselves.

"DORA doesn't just regulate financial firms — it reaches into the technology supply chain. Any vendor providing ICT services to multiple financial entities can find itself under direct ESA supervision, regardless of where it's incorporated."

There are proportionality provisions for microenterprises (fewer than 10 employees, under €2M turnover), which get simplified requirements. But the core obligations — ICT risk management, incident reporting, and third-party risk management — apply to all in-scope entities.

The Five DORA Pillars

DORA is organized around five areas of obligation. Understanding how they fit together matters more than treating them as isolated checklists.

1. ICT Risk Management — Financial entities must maintain an ICT risk management framework as part of their overall risk management system. This isn't optional documentation — it must be embedded in governance, with board-level accountability. The framework must cover: risk identification and assessment, protection and prevention, detection, response and recovery, and learning and evolving.

2. ICT-Related Incident Management — Entities must implement a process to detect, manage, classify, and report ICT-related incidents. The classification methodology distinguishes between "major" and "non-major" incidents based on criteria including client impact, geographic spread, data losses, criticality of affected services, and duration.

3. Digital Operational Resilience Testing — All in-scope entities must conduct annual testing of ICT systems. Significant financial entities (those meeting size thresholds defined by ESAs) must also conduct Threat-Led Penetration Testing (TLPT) every three years, using accredited testers against live production systems.

4. ICT Third-Party Risk Management — Entities must manage risks arising from ICT service providers throughout the contract lifecycle. This includes pre-contract due diligence, mandatory contractual provisions, ongoing monitoring, and exit planning.

5. Information and Intelligence Sharing — DORA explicitly permits (and encourages) financial entities to share cyber threat intelligence among themselves through trusted community arrangements. This is a notable departure from the usual regulatory posture — regulators are actively incentivizing collective defense.

ICT Risk Management Requirements in Practice

The ICT risk management framework requirement has specific operational implications that go beyond policy documentation.

Your management body (board or equivalent) must approve the framework and is accountable for its implementation. In practice, this means board-level reporting on ICT risk — not just delegation to the CTO or CISO. Many firms are discovering that their existing governance structures weren't designed for this.

The framework must include a digital operational resilience strategy — a documented approach to how the firm handles ICT risk, including its risk appetite, key dependencies on ICT, and how resilience objectives are defined and measured.

Asset management is a concrete requirement: entities must maintain an inventory of all ICT assets (hardware, software, data, ICT services) and identify dependencies between those assets and the business functions they support. This mapping underpins everything else — you can't manage the risk of assets you haven't catalogued.

"The ICT asset inventory is where most firms discover their real problem: they don't know what they have. DORA forces the uncomfortable exercise of mapping every production system, every vendor dependency, every data flow — and then assigning accountability for each."

Incident Reporting: The Deadlines That Matter

DORA's incident reporting regime is the area where the compliance clock ticks most visibly. The three-tier reporting structure creates real operational pressure.

The critical issue is the classification decision. The 4-hour clock starts when your firm classifies an incident as "major" — not when the incident first occurs. This creates an incentive to delay classification, which is exactly what regulators are watching for. The ESAs' regulatory technical standards (RTS) specify materiality thresholds for classification, removing discretion on genuinely serious incidents.

Classification criteria include: number of clients affected, geographic spread, data integrity losses, duration of the incident, service criticality, and economic impact. Your incident management process must have pre-defined procedures for assessing these criteria quickly, under operational stress.

Third-Party Risk: The Contract Review Challenge

DORA's third-party risk provisions require financial entities to ensure that contracts with ICT service providers include specific provisions. For many firms, the practical challenge is that they have hundreds of existing vendor contracts that predate DORA and don't contain these provisions.

Required contractual provisions include:

• Full and unambiguous description of services and service levels
• Locations where data will be processed and stored
• Data security, confidentiality, and integrity provisions
• Audit rights and access to information (for the entity and its competent authority)
• Termination rights and exit strategies, including minimum notice periods
• Subcontracting provisions and restrictions
• Business continuity obligations
• Participation in ICT security testing (where relevant)

Negotiating these provisions into existing contracts with large technology vendors — cloud providers in particular — is a significant operational exercise. Major cloud providers have published DORA-specific addenda, but smaller vendors may require custom negotiation. The ESAs have flagged concentration risk in cloud provision as a systemic concern: if most European financial firms use the same three cloud providers, a single outage becomes a system-wide event.

Entities must also maintain a register of ICT third-party providers and report it to competent authorities. This register must include all providers, their classification (critical or non-critical), and the ICT services they provide to the entity.

Digital Operational Resilience Testing

Annual testing obligations apply to all in-scope entities. The scope must cover at least the ICT systems and services supporting critical functions.

For firms meeting the significance thresholds (set by ESAs based on size, systemic importance, and risk profile), Threat-Led Penetration Testing (TLPT) is required every three years. TLPT is not a standard penetration test — it uses real threat intelligence to simulate realistic attacks against live production systems. Testing must be conducted by accredited external testers (or internal teams with external validation for smaller entities).

The ESAs published joint regulatory technical standards on TLPT (the TIBER-EU framework provides the technical basis). Financial entities in multiple member states can conduct pooled TLPT — a single test recognized by multiple supervisors — which reduces the operational burden of multi-jurisdiction compliance.

The Ongoing DORA Monitoring Challenge

DORA itself is stable — it's a regulation, not guidance that changes frequently. But the regulatory technical standards, implementing technical standards, and supervisory guidelines issued under DORA are a continuous stream. The ESAs published significant volumes of secondary legislation in 2024 and 2025, with more expected through 2026 as the regime matures.

What compliance teams need to track on an ongoing basis:

• ESA regulatory technical standards (RTS) — covering incident classification, testing criteria, third-party oversight, and more
• ESA implementing technical standards (ITS) — standardized templates for incident reporting, register formats
• EBA, EIOPA, and ESMA guidelines — sector-specific guidance for banks, insurers, and investment firms respectively
• National competent authority guidance — supervisors in each member state may publish implementation guidance, Q&As, or expectations that go beyond ESA-level documents
• Critical TPP designations — ESA decisions on which ICT providers are designated as critical, triggering enhanced oversight

The practical problem: DORA-related publications come from at least five ESA bodies plus 27 national supervisors, in multiple languages, with no single consolidated repository. Firms relying on manual monitoring — checking EBA, ESMA, and EIOPA websites periodically — will miss documents.

Building Your DORA Compliance Programme

For firms still building out their DORA programme, the priority sequence matters:

Immediate (if not already done):

• Complete your ICT asset inventory — you cannot build anything else without it
• Classify your ICT incidents against the DORA criteria and establish your classification procedure
• Map your ICT third-party providers and begin the register

Near-term:

• Audit existing vendor contracts against DORA's mandatory provisions; prioritize critical providers
• Establish your incident reporting workflow, including the 4-hour notification capability
• Determine whether you meet TLPT thresholds and plan accordingly

Ongoing:

• Set up monitoring for ESA publications and national supervisory guidance
• Track CTPP designation decisions — if your key providers are designated, the oversight requirements change
• Annual testing programme execution and documentation