DORA Compliance 2025: Complete Guide for Financial Entities

DORA — Regulation (EU) 2022/2554 — has been directly applicable across all EU Member States since 17 January 2025. For financial entities, this means a binding, harmonised framework for ICT risk management, incident reporting, resilience testing and third-party oversight. This guide focuses on Articles 17–23, the incident management and reporting obligations that require immediate operational changes.

What is DORA and who must comply?

DORA is a sector-specific regulation that replaces the patchwork of national and sectoral guidelines on ICT risk that existed before 2025. Prior to DORA, a bank operating across three EU member states could face three different national frameworks for ICT incident reporting. DORA eliminates this fragmentation.

The regulation applies to:

• Credit institutions (banks, building societies)
• Payment institutions and e-money institutions
• Investment firms and market operators
• Insurance and reinsurance undertakings
• Crypto-asset service providers (CASPs) under MiCA
• Central counterparties (CCPs) and trade repositories
• Management companies (UCITS and AIFMs)
• Institutions for occupational retirement provision (IORPs)
• Credit rating agencies and benchmark administrators
• Crowdfunding service providers
• Critical ICT third-party service providers (CTPPs) — directly supervised by ESAs

Micro-enterprises (fewer than 10 employees, annual turnover or balance sheet below €2 million) benefit from proportionality provisions — they apply DORA with lighter obligations in several areas.

The five pillars of DORA compliance

DORA is structured around five interconnected pillars. Understanding the full scope is essential even when your immediate priority is Art. 17–23.

Art. 17–19: ICT incident classification, management and reporting

Articles 17 to 19 are the operational core of DORA for most compliance teams. They govern how you detect, classify, escalate and report ICT-related incidents to competent authorities.

Art. 17: The incident management process

Every in-scope financial entity must have a formal ICT-related incident management process that includes:

• Detection and logging: all ICT-related incidents must be detected promptly and recorded in a dedicated incident log
• Classification: each incident must be classified using the criteria in Art. 18 to determine whether it is "major" (triggering reporting) or not
• Escalation procedures: clear internal escalation paths from IT operations to the management body
• Root cause analysis: post-incident review with identification of root causes and corrective actions
• Communication protocols: internal and external communication (clients, counterparties, media) managed under predefined procedures

Art. 18: Classifying incidents — what makes an incident "major"?

The EBA, ESMA and EIOPA have published Regulatory Technical Standards (RTS) under DORA that specify exactly how to classify incidents. An incident is classified as "major" if it meets materiality thresholds in at least one of these dimensions:

Cyber threats that have not yet materialised as incidents can be voluntarily notified under Art. 23 (covered below). Do not wait for full exploitation before assessing classification — Art. 17 requires you to classify promptly once you become aware of the incident.

Art. 19: The three-stage reporting obligation

When a major ICT-related incident is confirmed, three mandatory reports must be submitted to the competent authority:

Art. 20–22: Harmonised reporting and the centralised EU Hub

One of DORA's most operationally significant features is the move toward harmonised reporting templates across all financial sectors and member states.

Art. 20: Implementing Technical Standards (ITS) for templates

The Joint Committee of EBA, ESMA and EIOPA has developed Implementing Technical Standards specifying the exact format, content and submission procedures for all three reporting stages. These ITS are binding — using your own format is not compliant.

Key requirements from the ITS:

• Machine-readable submission format (XML/JSON for automated processing)
• Mandatory fields for each report stage — partial reports are not accepted
• Reference numbers that link all three reports for the same incident
• Specific fields for cross-border impact assessment

Art. 21: Delegating incident reporting within a group

Financial groups (parent + subsidiaries) may designate a single entity within the group to submit consolidated incident reports on behalf of all in-scope entities. This avoids duplication where a group-level IT incident triggers reporting obligations in multiple subsidiaries simultaneously.

Critical point: the original entity remains legally responsible. Delegation does not transfer liability. The group-level reporting arrangement must be formally documented and the competent authority of each subsidiary's home member state must be informed of the arrangement.

Art. 22: The centralised EU Hub

The EBA operates a centralised EU Hub that receives incident reports from all in-scope entities across all sectors. For cross-border groups, this avoids submitting the same report to five different national competent authorities. The Hub distributes reports to the relevant national authorities automatically.

The Hub is particularly relevant for: pan-European banks, cross-border payment institutions, and CASPs operating across multiple member states under MiCA.

Art. 23: Significant cyber threats — voluntary notification

Art. 23 creates a framework for voluntarily notifying competent authorities of significant cyber threats that have not yet materialised into incidents. This is distinct from the mandatory reporting of Art. 19 — it covers active threats that are being mitigated before they cause service disruption.

Why notify voluntarily?

• Competent authorities can share anonymised threat intelligence with other financial entities in the sector
• Demonstrates a proactive compliance posture — relevant in supervisory reviews
• Where a cyber threat involves a critical third-party provider, notification can trigger oversight action against the CTPP
• No penalty risk for voluntary disclosure (unlike failing to report a major incident)

The notification must include: description of the threat, systems targeted, mitigations applied, and an assessment of whether the threat could qualify as a major incident if it materialises.

Third-party ICT risk: what Art. 28–44 demands from your vendor contracts

DORA's third-party requirements are among the most complex to implement. Every ICT service contract with a provider that supports a critical or important function must include a mandatory set of provisions.

Mandatory contractual clauses include:

• Full description of all services provided, including subcontracting chains
• Service levels (SLAs) with availability and performance metrics
• Incident response and notification obligations of the ICT provider
• Audit and inspection rights — both by the financial entity and by competent authorities
• Right to terminate on regulatory grounds without financial penalty
• Data portability and transition assistance requirements
• Business continuity provisions and testing cooperation obligations

For contracts with cloud providers (AWS, Azure, Google Cloud), the standard terms of service are not sufficient for DORA compliance without a bespoke addendum. Most major cloud providers now offer DORA-specific addenda — ensure yours is signed and current.

Additionally, every financial entity must maintain a register of all ICT third-party contracts, classified by criticality. This register must be made available to the competent authority on request.

DORA testing requirements: basic vs advanced (TLPT)

DORA mandates two levels of resilience testing:

Basic testing applies to all in-scope entities and must be conducted annually (or more frequently if the risk profile warrants it). It includes vulnerability assessments, network security scanning, gap analyses, physical security reviews and scenario-based testing.

Threat-Led Penetration Testing (TLPT) is required for significant financial entities — typically large banks, central counterparties and major payment institutions designated by competent authorities. TLPT must:

• Be conducted at least every 3 years
• Cover live production systems (not test environments)
• Use external testers who are independent of the entity
• Follow the TIBER-EU framework or national equivalents (CBEST in the UK, TIBER-NL in the Netherlands)
• Include critical ICT third-party providers in scope if they support critical functions

TLPT results are shared with the competent authority. Significant findings must be remediated within defined timeframes. The TLPT certificate issued after successful completion provides a period of regulatory credit — the entity does not need to repeat testing within that window unless a major incident occurs.

Penalties for non-compliance with DORA

DORA itself does not set harmonised fines — penalties are implemented by each member state's national competent authority. However, the ESAs (EBA, ESMA, EIOPA) have supervisory powers over critical third-party providers that include fines of up to 1% of average daily worldwide turnover of the CTPP for each day of infringement, up to a maximum of 6 months.

For financial entities, national penalties vary by jurisdiction but are aligned with existing sectoral frameworks. In practice, the most significant consequences of DORA non-compliance are:

• Formal supervisory action and remediation plans
• Suspension or restriction of the authorisation to provide services
• Public disclosure of the infringement (reputational damage)
• Personal liability for members of the management body

Art. 19 failures (late or absent incident reporting) are treated with particular severity — supervisors expect near-real-time notification for major incidents and have made clear that reporting delays will be subject to enforcement action from 2025 onwards.

How to build your DORA Art. 17–23 compliance roadmap

Most financial entities that are behind on DORA need to prioritise Art. 17–23 first because the reporting obligations are the most time-sensitive and the ones supervisors are actively checking.

A practical six-week sprint to reach basic compliance with Art. 17–23:

1. Week 1: Designate a DORA incident response owner (CISO or equivalent) and map current ICT incident log to DORA Art. 18 classification criteria
2. Week 2: Gap analysis — which current incidents would have triggered major classification? Identify missed reports
3. Week 3: Draft updated ICT incident response procedure with DORA-compliant classification tree and 4h/72h/1mo reporting triggers
4. Week 4: Implement Art. 19 ITS-compliant reporting templates in your incident management system (ServiceNow, Jira, or purpose-built)
5. Week 5: Train incident response team, first responders and the management body on the new classification and reporting procedures
6. Week 6: Tabletop exercise simulating a major incident — test the 4-hour notification pathway end to end

The tabletop exercise in week 6 consistently reveals procedural gaps that documents miss. Run it before your competent authority requests it in a supervisory review. See also our guide on DORA ICT compliance: complete guide for financial entities for the full five-pillar framework.

Does DORA apply to my company if we are headquartered outside the EU?

Yes, if you provide services to EU financial entities or operate within the EU financial system. DORA has explicit extraterritorial reach — the same logic as GDPR. If you are a non-EU CTPP providing cloud services to EU banks, you are directly subject to the DORA oversight framework under Art. 31–44.

What is the difference between a DORA major incident report and a GDPR breach notification?

They are separate and can be triggered simultaneously. A data breach involving personal data triggers GDPR Art. 33 (notification to data protection authority within 72 hours) and GDPR Art. 34 (notification to affected individuals if high risk). If the breach results from an ICT incident that meets DORA Art. 18 thresholds, it also triggers DORA Art. 19 reporting. The two reports go to different authorities and use different templates — do not conflate them or assume one report satisfies both obligations.

How do micro-enterprises apply DORA differently?

Micro-enterprises (under 10 employees, under €2M turnover/balance sheet) benefit from simplified requirements in several areas: they can adopt a simplified ICT risk management framework under Art. 16, are exempt from TLPT under Art. 26, and have lighter third-party contract requirements under Art. 28. However, they are still fully subject to Art. 17–23 incident reporting — there is no size-based exemption from major incident notification.

What counts as an "ICT third-party service provider" under DORA?

Any undertaking that provides digital and data services on an ongoing basis, including cloud computing, software (SaaS, PaaS), data analytics, data centres, and hardware provision that underpins critical or important functions. Payment card network operators, CLS, and interbank messaging providers are all in scope. Internal group entities providing ICT services to other group entities are also covered if they support critical or important functions.

Can a cyber incident qualify as both a major ICT incident and a reportable operational risk event under CRR?

Yes. A significant cyber attack on a credit institution may simultaneously trigger: DORA Art. 19 (ICT incident reporting), CRR/Basel III operational risk event recording, GDPR Art. 33/34 if personal data is affected, and national central bank reporting in some jurisdictions. Your incident response procedure should map each regulatory trigger and assign a clear owner for each reporting obligation.

How does DORA interact with NIS2?

DORA is lex specialis with respect to NIS2 for in-scope financial entities. Recital 16 of DORA clarifies that financial entities subject to DORA are exempt from the NIS2 incident reporting obligations when an ICT incident also qualifies as a significant cyber threat under NIS2. The DORA competent authority (EBA, ESMA or EIOPA, or national equivalent) coordinates with NIS2 authorities to avoid duplication. In practice, file under DORA and inform your DORA competent authority — they handle coordination with the NIS2 national authority.