Last updated: March 29, 2026
Quick Summary: DORA at a Glance
| Aspect | Details | Source |
|---|---|---|
| Legal basis | Regulation (EU) 2022/2554 (DORA) | EUR-Lex |
| Type | EU Regulation (directly applicable, no transposition needed) | Art. 288 TFEU |
| Application date | January 17, 2025 (fully mandatory) | Art. 64, DORA |
| Financial entities in scope | 22,000+ across the EU | European Commission DORA FAQ |
| Entity types covered | 21 categories of financial entities | Art. 2(1), DORA |
| ICT third-party providers | Oversight framework for critical providers | Arts. 31-44, DORA |
| Staff training required | Mandatory ICT security awareness and resilience training | Art. 13(6), DORA |
| Management body training | Management must undertake specific ICT risk training | Art. 5(4), DORA |
Reading time: 29 min read
Need to build a DORA-compliant training programme? Browse our financial services compliance courses or contact us for tailored DORA training.
Executive Summary
The Digital Operational Resilience Act (DORA) (Regulation (EU) 2022/2554) is the European Union's comprehensive framework for ensuring that financial entities can withstand, respond to, and recover from ICT-related disruptions and threats. It has been fully applicable since January 17, 2025, meaning every financial entity in scope must already be compliant.
DORA is a regulation, not a directive — it applies directly in all EU member states without the need for national transposition. This means there is no ambiguity about deadlines, no variation in national implementation, and no excuse for delay.
The scope is sweeping. DORA covers 21 categories of financial entities — from banks and insurance companies to crypto-asset service providers and crowdfunding platforms — and introduces an EU-level oversight framework for critical ICT third-party service providers (including major cloud providers). The European Commission estimates that over 22,000 financial entities across the EU are directly in scope.
Critically for compliance professionals, DORA contains explicit training obligations. Article 5(4) requires management body members to "maintain sufficient knowledge and skills to understand and assess ICT risk." Article 13(6) mandates ICT security awareness programmes for all staff. These are not aspirational goals — they are binding legal requirements with enforcement consequences.
"DORA fundamentally changes the conversation about ICT risk in financial services. For too long, operational resilience was treated as an IT problem. DORA makes it a governance obligation — owned by the management body, embedded in risk management, and subject to the same supervisory scrutiny as capital adequacy or conduct of business. Financial entities that treat DORA as a technology compliance exercise will find themselves failing both the letter and the spirit of the law."
— José Manuel Campa, Chairperson of the European Banking Authority (EBA), speaking at the EBA Conference on Digital Finance, November 2024
This guide provides a comprehensive analysis of DORA's requirements with particular emphasis on the training and competence obligations that compliance, risk, and learning and development professionals need to understand.
What Is DORA?
DORA is part of the EU's broader Digital Finance Strategy, adopted alongside the Markets in Crypto-Assets Regulation (MiCA) and the Digital Operational Resilience Act amending directive. It was formally adopted on November 28, 2022, published in the Official Journal on December 27, 2022, and entered into force on January 16, 2023, with a two-year implementation period ending January 17, 2025.
The Regulatory Gap DORA Fills
Before DORA, ICT risk management in EU financial services was governed by a patchwork of:
- EBA Guidelines on ICT and security risk management (EBA/GL/2019/04) — applicable to banks and investment firms
- EIOPA Guidelines on information and communication technology security and governance — applicable to insurers
- ESMA Guidelines on outsourcing to cloud service providers — applicable to fund managers
- National rules varying by member state
This fragmentation meant inconsistent standards, supervisory gaps, and no unified approach to third-party ICT risk — despite the financial sector's increasing concentration of critical operations in a small number of cloud and technology providers.
DORA's Objectives
| Objective | Mechanism |
|---|---|
| Harmonise ICT risk management | Single set of requirements replacing sectoral guidelines |
| Standardise incident reporting | Uniform classification and reporting to competent authorities |
| Mandate resilience testing | Threat-led penetration testing for significant entities |
| Address third-party concentration risk | EU oversight framework for critical ICT providers |
| Enable information sharing | Voluntary exchange of cyber threat intelligence |
Why DORA Was Needed: The ICT Risk Landscape in Financial Services
The Scale of ICT Dependence
Financial services is among the most digitally dependent sectors in the global economy. The sector's operational continuity depends on ICT infrastructure for payments processing, trading, risk management, regulatory reporting, and customer services.
| Statistic | Figure | Source |
|---|---|---|
| Financial sector IT spending (EU, 2024) | EUR 76 billion | ECB Financial Stability Review, November 2024 |
| Cloud adoption in EU banking | 78% of EU banks use cloud services | EBA Report on Cloud Outsourcing, 2024 |
| Cyber incidents reported to ECB | 2,800+ significant incidents in 2024 | ECB Annual Report on Supervisory Activities 2024 |
| Average cost of data breach (financial sector) | $6.08 million | IBM Cost of a Data Breach Report 2024 |
| Third-party ICT concentration | 3 cloud providers serve 72% of EU financial entities | ESRB Report on Cloud Concentration, 2023 |
| Ransomware targeting financial sector | 64% increase 2022-2024 | ENISA Threat Landscape 2024 |
High-Profile Incidents That Shaped DORA
Several major ICT incidents in the financial sector demonstrated the systemic risk that DORA was designed to address:
- The 2023 ION Trading cyberattack disrupted derivatives clearing across multiple EU markets, demonstrating how a single third-party provider failure can cascade through the financial system.
- The CrowdStrike global IT outage (July 2024) caused widespread disruptions in banking, payments, and insurance — affecting millions of customers and illustrating concentration risk in ICT supply chains.
- Ongoing ransomware campaigns targeting financial institutions, including state-affiliated attacks, underscored the need for standardised incident reporting and resilience testing.
Who Does DORA Apply To? The 21 Categories
DORA's scope is defined in Article 2(1), which lists 21 categories of financial entities:
| # | Entity Type | Primary Supervisor |
|---|---|---|
| 1 | Credit institutions (banks) | ECB/SSM and national competent authorities |
| 2 | Payment institutions | National competent authorities |
| 3 | Account information service providers | National competent authorities |
| 4 | Electronic money institutions | National competent authorities |
| 5 | Investment firms | National competent authorities / ESMA |
| 6 | Crypto-asset service providers (under MiCA) | National competent authorities |
| 7 | Issuers of asset-referenced tokens | National competent authorities / EBA |
| 8 | Central securities depositories | National competent authorities / ESMA |
| 9 | Central counterparties (CCPs) | National competent authorities / ESMA |
| 10 | Trading venues | National competent authorities / ESMA |
| 11 | Trade repositories | ESMA |
| 12 | Managers of alternative investment funds (AIFMs) | National competent authorities |
| 13 | Management companies (UCITS) | National competent authorities |
| 14 | Data reporting service providers | ESMA |
| 15 | Insurance and reinsurance undertakings | National competent authorities / EIOPA |
| 16 | Insurance intermediaries, reinsurance intermediaries, ancillary insurance intermediaries | National competent authorities |
| 17 | Institutions for occupational retirement provision (IORPs) | National competent authorities |
| 18 | Credit rating agencies | ESMA |
| 19 | Administrators of critical benchmarks | National competent authorities / ESMA |
| 20 | Crowdfunding service providers | National competent authorities |
| 21 | Securitisation repositories | ESMA |
Additionally: ICT Third-Party Service Providers
While not "financial entities" themselves, ICT third-party service providers that are designated as critical under DORA's oversight framework (Articles 31-44) are subject to direct EU-level oversight by a Lead Overseer (one of the European Supervisory Authorities — EBA, ESMA, or EIOPA). This is unprecedented — it means that major cloud providers, fintech infrastructure companies, and other critical ICT suppliers serving the financial sector can be directly supervised at the EU level.
The designation criteria for critical ICT third-party providers include:
- Systemic impact of a failure on financial stability or essential financial services
- Degree of substitutability — fewer alternatives means higher criticality
- Number and significance of financial entities relying on the provider
- Degree of dependency of specific financial entities on the provider
Proportionality and Microenterprises
Article 4 establishes a proportionality principle: entities must implement DORA requirements "in a manner proportionate to their size and overall risk profile, and to the nature, scale and complexity of their services, activities and operations." Microenterprises (fewer than 10 employees and turnover/balance sheet under EUR 2 million) benefit from a simplified ICT risk management framework under Article 16.
The Five Pillars of DORA
DORA is structured around five interconnected pillars, each addressing a distinct dimension of digital operational resilience.
Pillar 1: ICT Risk Management Framework
Requirements (Articles 5-16)
DORA requires every financial entity to establish, maintain, and regularly review an ICT risk management framework that is comprehensive, documented, and integrated into the overall risk management system.
Management Body Responsibility (Article 5)
This is the governance foundation of DORA. Article 5 places ultimate responsibility for ICT risk management on the management body (board of directors, executive committee, or equivalent):
| Responsibility | Description |
|---|---|
| Define and approve the digital operational resilience strategy | Including risk appetite for ICT risk |
| Approve and oversee the ICT risk management framework | Regular review and update |
| Approve the ICT business continuity policy and response/recovery plans | Including testing schedules |
| Approve ICT audit plans and reviews | Internal and external |
| Allocate adequate budget for ICT security and digital resilience | Including training |
| Approve and review arrangements with ICT third-party service providers | Including critical providers |
| Stay informed about ICT risks and ICT-related incidents | Regular reporting from management |
| Undergo specific training on ICT risk | Required by Article 5(4) |
ICT Risk Management Components
The framework must include, at minimum:
Identification (Article 8):
- Identify and classify all ICT-supported business functions, roles, and responsibilities
- Map all ICT assets, information assets, and their interdependencies
- Identify all sources of ICT risk, including internal and external threats
Protection and Prevention (Article 9):
- Security policies governing access, encryption, network security, and data protection
- Vulnerability management and patching
- Change management and configuration control
- Physical and environmental security for ICT infrastructure
Detection (Article 10):
- Mechanisms and processes for promptly detecting anomalous activities and ICT-related incidents
- Multiple layers of control, including alerting thresholds and criteria for incident detection
Response and Recovery (Article 11):
- ICT business continuity policy
- ICT response and recovery plans for all critical ICT services
- Switchover to backup systems and rollback procedures
- Communication protocols for internal and external stakeholders
Learning and Evolving (Article 13):
- Post-incident reviews and root cause analysis
- Continuous improvement of ICT risk management
- Integration of lessons from resilience testing, incidents, and threat intelligence
- Staff training and awareness programmes (Article 13(6))
Pillar 2: ICT-Related Incident Reporting
Requirements (Articles 17-23)
DORA establishes a harmonised incident reporting framework that replaces the fragmented national approaches that existed before.
Incident Classification
Financial entities must classify ICT-related incidents based on criteria specified in Article 18:
| Classification Criteria | Description |
|---|---|
| Number of clients/counterparties affected | Scale of impact on users |
| Duration of the incident | How long service was disrupted |
| Geographical spread | Cross-border impact |
| Data losses | Personal data, financial data, confidentiality breaches |
| Criticality of services affected | Impact on critical or important functions |
| Economic impact | Direct and indirect financial costs |
Reporting Obligations for Major Incidents
| Report | Deadline | Content |
|---|---|---|
| Initial notification | Within 4 hours of classification as major (no later than 24 hours after detection) | Basic information about the incident |
| Intermediate report | Within 72 hours of initial notification | Updated information, severity, root cause hypothesis |
| Final report | Within 1 month of incident resolution | Root cause analysis, remediation, lessons learned |
Significant Cyber Threats
In addition to major incidents, financial entities must report significant cyber threats on a voluntary basis (Article 19) — or on a mandatory basis where required by national competent authorities.
The European Supervisory Authorities (EBA, ESMA, EIOPA) have developed joint regulatory technical standards (RTS) specifying the detailed classification criteria, reporting templates, and thresholds for major incidents and significant threats.
Pillar 3: Digital Operational Resilience Testing
Requirements (Articles 24-27)
DORA mandates a structured testing programme to validate the effectiveness of ICT risk management measures.
Basic Testing (All Financial Entities)
Article 25 requires all financial entities to establish and maintain a testing programme that includes, as appropriate:
| Test Type | Purpose |
|---|---|
| Vulnerability assessments | Identify security weaknesses |
| Open-source analyses | Assess risks from open-source components |
| Network security assessments | Evaluate network-level controls |
| Gap analyses | Compare current state to required standards |
| Physical security reviews | Assess data centre and infrastructure security |
| Questionnaires and scanning software | Automated vulnerability identification |
| Source code reviews (where feasible) | Identify application-level vulnerabilities |
| Scenario-based tests | Simulate specific threat scenarios |
| Compatibility testing | Validate interoperability |
| Performance testing | Assess system capacity and resilience under load |
| End-to-end testing | Validate complete business process chains |
| Penetration testing | Active testing by internal or qualified external testers |
Advanced Testing: Threat-Led Penetration Testing (TLPT)
Article 26 introduces mandatory threat-led penetration testing (TLPT) for certain financial entities identified by competent authorities. TLPT is based on the TIBER-EU framework and requires:
- Testing at least every 3 years
- Conducted by qualified external testers (independence required)
- Based on current threat intelligence relevant to the entity
- Testing must cover critical or important functions and their supporting ICT services
- Results must be reported to the competent authority and validated
- ICT third-party service providers supporting critical functions must be included in the scope
TLPT is the most demanding element of DORA and applies primarily to systemically important financial entities — significant credit institutions, large insurers, central counterparties, and other entities identified by supervisory authorities.
Pillar 4: ICT Third-Party Risk Management
Requirements (Articles 28-44)
DORA's third-party risk provisions are among its most consequential innovations, addressing the systemic risk created by financial sector concentration in a small number of ICT providers.
Contractual Requirements (Article 30)
All contracts between financial entities and ICT third-party service providers must include, at minimum:
| Required Contractual Element | Description |
|---|---|
| Clear service descriptions | Functions supported, service levels, locations of data processing |
| Data protection | Provisions on availability, integrity, and confidentiality |
| Data access and return | Right to access data, right to data return on termination |
| Cooperation with authorities | Obligation for provider to cooperate with financial entity's competent authority |
| Audit rights | Financial entity's right to audit the provider (or use pooled audits/third-party certifications) |
| Exit strategy | Transition plans for termination, ensuring continuity |
| Subcontracting conditions | Restrictions and transparency regarding subcontracting |
| Service levels and remediation | Performance targets and consequences for breach |
The Oversight Framework for Critical ICT Providers
Articles 31-44 establish an EU-level oversight framework that is unique in European financial regulation:
- Designation: The ESAs (EBA, ESMA, EIOPA) jointly designate critical ICT third-party providers based on systemic importance criteria.
- Lead Overseer: One of the three ESAs is appointed as Lead Overseer for each critical provider.
- Oversight powers: The Lead Overseer can conduct general investigations, inspections, request information, issue recommendations, and — if recommendations are not followed — request financial entities to restrict or terminate arrangements with the provider.
- Oversight fees: Critical ICT providers pay fees to fund the oversight.
This framework effectively brings major cloud providers (AWS, Microsoft Azure, Google Cloud), core banking system vendors, market data providers, and other critical technology suppliers under direct EU regulatory supervision — a first globally.
"The concentration of critical financial services operations in a small number of cloud providers creates systemic risk that cannot be addressed at the entity level alone. DORA's oversight framework is an acknowledgment that digital operational resilience in financial services is not just about individual firms — it is about the resilience of the infrastructure that underpins the entire sector."
— Verena Ross, Chair of ESMA (European Securities and Markets Authority), at the ESMA Annual Conference, January 2025
Pillar 5: Information Sharing
Requirements (Article 45)
DORA explicitly enables — and encourages — financial entities to share cyber threat intelligence and information about ICT vulnerabilities, tactics, techniques, and procedures (TTPs) with each other and with competent authorities.
Key provisions:
- Financial entities may participate in information-sharing arrangements
- Shared information must be protected (confidentiality obligations)
- Sharing can occur through trusted communities or ISACs (Information Sharing and Analysis Centres)
- Competent authorities must be notified of participation in such arrangements
- Information sharing about threat intelligence does not create liability for the sharing entity (safe harbour)
DORA Training Requirements: What the Law Demands
DORA contains two distinct, legally binding training obligations that financial entities must satisfy.
Obligation 1: Management Body ICT Risk Training (Article 5(4))
"Members of the management body of the financial entity shall, on a regular basis, follow specific training to gain and keep up to date sufficient knowledge and skills to understand and assess ICT risk and its impact on the operations of the financial entity."
— Article 5(4), Regulation (EU) 2022/2554
This is not discretionary. Board members and senior management must:
| Requirement | Description |
|---|---|
| Receive regular training | Not one-time — ongoing and updated |
| Gain sufficient knowledge | Must understand ICT risk, not just receive briefings |
| Understand the impact on operations | Connect ICT risk to business impact |
| Keep up to date | Training must evolve as threats and technology change |
What the training should cover for management bodies:
- ICT risk landscape — current threats and trends
- The entity's ICT risk management framework — how it works, what it covers
- Critical and important functions and their ICT dependencies
- Third-party ICT risk — concentration, resilience, contractual protections
- Incident reporting obligations and management's role
- Resilience testing programme and results
- Regulatory expectations and supervisory developments
- DORA's specific requirements and the management body's responsibilities
Obligation 2: ICT Security Awareness for All Staff (Article 13(6))
"Financial entities shall develop ICT security awareness programmes and digital operational resilience training as a module in their staff training schemes. Those programmes and training shall be applicable to all employees and to senior management staff, and shall have a level of complexity commensurate to the remit of their functions. Where appropriate, financial entities shall also include ICT third-party service providers in their relevant training schemes in accordance with Article 30(2), point (i)."
— Article 13(6), Regulation (EU) 2022/2554
Key elements of this obligation:
| Element | Description |
|---|---|
| All employees | Not just IT or security teams — everyone |
| Senior management | Explicitly included (reinforcing Article 5(4)) |
| Commensurate complexity | Training must be appropriate to the role |
| ICT third-party providers | Should be included where appropriate |
| Digital operational resilience | Not just cybersecurity — resilience is broader |
| Part of staff training schemes | Integrated into the entity's overall training programme |
Building a DORA-Compliant Training Programme
Framework: Four-Layer Approach
Based on DORA's requirements and the regulatory technical standards published by the ESAs, a compliant training programme should be structured in four layers:
Layer 1: All-Staff ICT Security Awareness
Target: Every employee in the financial entity
Frequency: At onboarding + annual refresher + ad hoc updates
Content:
| Topic | Description |
|---|---|
| Phishing and social engineering | Recognise and report suspicious communications |
| Password and authentication hygiene | Strong passwords, MFA, credential management |
| Data handling and classification | How to handle sensitive financial and personal data |
| Device security | Secure use of laptops, mobile devices, removable media |
| Incident recognition and reporting | What constitutes an ICT-related incident and how to report it |
| Remote working security | VPN, secure connectivity, physical security when remote |
| DORA basics | What DORA is, why it matters, and the entity's obligations |
| Acceptable use policies | ICT systems, email, internet, cloud services |
Layer 2: Role-Specific Operational Resilience Training
Target: Staff in ICT, security, risk management, compliance, and business continuity roles
Frequency: At onboarding + semi-annual refresher
Content:
| Topic | Description |
|---|---|
| ICT risk management framework | Detailed understanding of the entity's framework and their role |
| Incident classification and reporting | How to classify incidents against DORA criteria, reporting timelines |
| Business continuity and recovery | BCP/DRP procedures, switchover, failback, communication |
| Vulnerability management | Patching, scanning, assessment, prioritisation |
| Third-party risk management | Due diligence, monitoring, contractual requirements |
| Resilience testing | Participation in testing programmes, interpreting results |
| Change management | Secure change processes for ICT systems |
Layer 3: Management Body Training
Target: Board members, C-suite, senior management
Frequency: At appointment + annual refresher + ad hoc (major incident, regulatory change)
Content:
| Topic | Description |
|---|---|
| ICT risk landscape | Current and emerging threats to the financial sector |
| DORA requirements | Management body's legal responsibilities under Articles 5 and 13 |
| Digital operational resilience strategy | The entity's strategy, risk appetite, and investment |
| Third-party concentration risk | Critical ICT provider dependencies and oversight |
| Incident reporting governance | Management's role during and after major incidents |
| Resilience testing results | Interpretation and strategic response |
| Regulatory expectations | Supervisory focus areas and examination trends |
| Personal liability | Consequences of non-compliance for management body members |
Layer 4: Specialist Technical Training
Target: ICT security team, CISO, SOC analysts, incident responders, TLPT testers
Frequency: Continuous (certifications, conferences, exercises)
Content:
| Topic | Description |
|---|---|
| Advanced threat detection and response | SIEM, EDR, threat hunting, forensics |
| Penetration testing and TLPT | Methodology, execution, reporting |
| Cloud security | Securing cloud infrastructure and services |
| Cryptography and key management | Encryption standards, PKI, key lifecycle |
| Network security architecture | Segmentation, zero trust, secure design |
| Incident command and communication | Leading incident response, regulatory communication |
Documentation Requirements
DORA compliance requires that training programmes are documented and auditable:
- Training policy specifying objectives, scope, content, and frequency
- Training records with participant details, dates, and content delivered
- Assessment results demonstrating comprehension (not just attendance)
- Programme review records showing how content is updated based on incidents, testing, and threat intelligence
- Third-party provider training records where applicable
DORA and the Proportionality Principle
Article 4 requires that DORA obligations be implemented proportionately. This means different types of financial entities have different practical obligations:
Simplified ICT Risk Management Framework (Article 16)
The following entity types may apply the simplified framework:
- Small and non-interconnected investment firms
- Payment institutions exempted under PSD2
- Institutions exempted under CRD
- Small electronic money institutions
- Small IORPs
The simplified framework maintains core requirements but with reduced complexity in areas such as governance, testing, and third-party management.
Practical Proportionality by Entity Size
| Dimension | Large/Systemic Entity | Medium Entity | Microenterprise |
|---|---|---|---|
| ICT risk management | Full framework, dedicated CISO, comprehensive documentation | Full framework, proportionate documentation | Simplified framework (Art. 16) |
| Incident reporting | Full multi-stage reporting for major incidents | Full reporting | Simplified reporting |
| Resilience testing | Basic + TLPT (if designated) | Basic testing | Proportionate testing |
| Third-party management | Comprehensive, concentration risk analysis | Proportionate due diligence | Proportionate |
| Training | Four-layer programme, TLPT specialists | Three-layer programme | Basic awareness + management training |
DORA vs NIS2: How They Interact
Financial entities are covered by both DORA and NIS2 (Directive (EU) 2022/2555). However, DORA is the lex specialis (specialist law) for the financial sector.
Article 4 of NIS2 and Recital 28 of DORA make clear that where DORA provides sector-specific requirements equivalent to or more stringent than NIS2, the DORA provisions prevail.
| Aspect | NIS2 | DORA | Which Applies to Financial Entities? |
|---|---|---|---|
| ICT risk management | Article 21 (10 minimum measures) | Articles 5-16 (comprehensive framework) | DORA |
| Incident reporting | 24h/72h/1 month | 4h-24h/72h/1 month | DORA (stricter) |
| Resilience testing | Not specified | Articles 24-27 (basic + TLPT) | DORA |
| Third-party risk | Supply chain security (Art. 21(2)(d)) | Articles 28-44 (detailed, oversight framework) | DORA (more detailed) |
| Management liability | Article 20 (personal liability) | Article 5 (management body responsibility) | Both (complementary) |
| Training | Article 21(2)(g) (cyber hygiene + training) | Articles 5(4) + 13(6) (specific training obligations) | DORA (more specific) |
| Penalties | EUR 10M / 2% (essential) | Determined by national financial services legislation | Varies by member state |
Key point for financial entities: DORA is your primary compliance framework for digital operational resilience. NIS2 obligations are satisfied by DORA compliance in areas of overlap. However, financial entities should ensure that any NIS2 obligations not covered by DORA (if any arise from national transposition) are also addressed.
Enforcement and Penalties
Supervisory Powers
DORA's enforcement is conducted by the existing financial supervisory framework:
- ECB/SSM for significant credit institutions in the Banking Union
- National competent authorities for all other financial entities
- ESAs (EBA, ESMA, EIOPA) for cross-sectoral coordination and oversight of critical ICT providers
Supervisory authorities have broad powers including:
| Power | Description |
|---|---|
| Information requests | Demand documentation, records, and explanations |
| On-site inspections | Inspect premises, systems, and records |
| Audit powers | Require internal or external audits |
| Remediation orders | Direct entities to address deficiencies |
| Supervisory measures | Range of corrective measures under existing financial services law |
| Administrative penalties | Determined by national law implementing DORA's penalty framework |
Penalties
DORA's penalty framework (Article 50) requires member states to establish "effective, proportionate and dissuasive" administrative penalties and remedial measures. Unlike NIS2, DORA does not specify minimum fine amounts — these are determined by national transposition of the penalty provisions.
However, financial entities should note:
- Existing financial services penalty frameworks already include substantial fines (e.g. CRD fines for banks can reach 10% of turnover)
- DORA non-compliance may be treated as a governance failure under existing prudential requirements
- Supervisory review processes (SREP for banks) may incorporate DORA compliance assessments, affecting capital requirements
- Personal liability for management body members failing to comply with Article 5 obligations
The Regulatory Technical Standards
The ESAs have published extensive regulatory technical standards (RTS) and implementing technical standards (ITS) that provide detailed specifications for DORA compliance:
| Standard | Description | Authority |
|---|---|---|
| RTS on ICT risk management framework | Detailed requirements for the ICT risk management framework | Joint ESAs |
| RTS on ICT-related incident classification | Criteria and thresholds for major incident classification | Joint ESAs |
| RTS on major incident reporting | Templates and content requirements | Joint ESAs |
| RTS on TLPT | Requirements for threat-led penetration testing | Joint ESAs |
| RTS on ICT third-party risk | Detailed requirements for third-party risk management | Joint ESAs |
| RTS on subcontracting | Requirements for monitoring subcontracted ICT services | Joint ESAs |
| ITS on incident reporting templates | Standardised reporting forms | Joint ESAs |
These RTS/ITS are binding and provide the operational detail that financial entities need to implement DORA's principles-based requirements.
Conclusion: Operational Resilience as Competitive Advantage
DORA is the most comprehensive digital operational resilience framework in the world. For the EU's 22,000+ financial entities, it is not optional, not aspirational, and not a future obligation — it is law, enforceable now.
But organisations that view DORA purely as a regulatory burden are missing the strategic opportunity. Financial entities with robust digital operational resilience:
- Experience fewer and less severe ICT disruptions, reducing customer impact and financial loss
- Recover faster from incidents that do occur, maintaining market confidence
- Manage third-party risk proactively, avoiding concentration vulnerabilities before they materialise
- Attract and retain customers who increasingly demand evidence of operational resilience
- Satisfy supervisory expectations, reducing regulatory friction and supporting access to markets
Training is the human foundation of all of this. Technology controls and governance frameworks are essential, but they are only as effective as the people who implement, operate, and oversee them. DORA recognises this by making training a legal obligation — not an afterthought.
Ready to Build Your DORA Training Programme?
CompliQuest provides financial services compliance training designed for DORA's specific requirements — from all-staff ICT security awareness to management body governance training.
Browse Our Financial Services Courses · Contact Us for DORA Training
Frequently Asked Questions
What is DORA?
DORA — the Digital Operational Resilience Act (Regulation (EU) 2022/2554) — is an EU regulation that establishes a comprehensive framework for the digital operational resilience of the financial sector. It requires financial entities to implement ICT risk management frameworks, report ICT-related incidents, conduct digital resilience testing, manage third-party ICT risk, and share cyber threat intelligence. It was adopted in November 2022 and has been fully applicable since January 17, 2025. As a regulation (not a directive), it applies directly in all EU member states without the need for national transposition.
Who does DORA apply to?
DORA applies to 21 categories of financial entities listed in Article 2(1), including credit institutions (banks), payment institutions, electronic money institutions, investment firms, crypto-asset service providers, insurance and reinsurance undertakings, pension funds, central counterparties, trading venues, fund managers, credit rating agencies, and crowdfunding platforms. The European Commission estimates over 22,000 financial entities are directly in scope. Additionally, critical ICT third-party service providers (such as major cloud providers) are subject to an EU-level oversight framework under Articles 31-44.
When did DORA take effect?
DORA was published in the Official Journal on December 27, 2022, entered into force on January 16, 2023, and became fully applicable on January 17, 2025 after a two-year implementation period (Art. 64). All financial entities in scope must be compliant as of that date. The European Supervisory Authorities (EBA, ESMA, EIOPA) have published regulatory technical standards (RTS) and implementing technical standards (ITS) providing detailed specifications for compliance.
What are DORA's main requirements?
DORA is built on five pillars: (1) ICT risk management — a comprehensive framework for identifying, protecting, detecting, responding to, and recovering from ICT risks; (2) ICT-related incident reporting — classification and multi-stage reporting of major incidents (initial notification within 4-24 hours, intermediate report within 72 hours, final report within 1 month); (3) Digital operational resilience testing — basic testing for all entities plus threat-led penetration testing (TLPT) for systemically important entities; (4) ICT third-party risk management — contractual requirements and an EU oversight framework for critical providers; and (5) Information sharing — voluntary exchange of cyber threat intelligence among financial entities.
Does DORA require training?
Yes, explicitly. DORA contains two distinct training obligations. Article 5(4) requires management body members to "follow specific training to gain and keep up to date sufficient knowledge and skills to understand and assess ICT risk." Article 13(6) requires financial entities to develop ICT security awareness programmes and digital operational resilience training applicable to all employees and senior management staff, with complexity commensurate to the remit of their functions. Third-party ICT service providers should be included where appropriate. These are binding legal requirements, not recommendations.
What are the penalties for DORA non-compliance?
DORA's penalty framework (Article 50) requires member states to establish "effective, proportionate and dissuasive" penalties. Unlike NIS2, DORA does not specify minimum fine amounts — these are determined by national implementation. However, existing financial services penalty frameworks are substantial (e.g. CRD bank fines can reach 10% of annual turnover). DORA non-compliance may also be assessed as a governance failure in supervisory reviews, with implications for capital requirements and authorisations. Most significantly, management body members can be held personally liable for failure to comply with their Article 5 obligations to approve and oversee ICT risk management.
Related Insights
- Cybersecurity Awareness Training: The Complete Guide for 2026 — Building security awareness programmes that satisfy DORA Article 13(6).
- NIS2 Directive: Who Must Comply? — How NIS2 and DORA interact for financial entities.
- BSA/AML Risk Assessment: Complete Guide 2026 — Financial crime compliance alongside operational resilience.
- CISO Roles and Responsibilities: Complete Guide 2026 — The security leadership role central to DORA governance.
Our Financial Services & Compliance Courses
- Compliance & Regulatory Training — Financial services, cybersecurity, and operational resilience training programmes.
- Contact us for DORA training programme design and implementation support.