The Digital Operational Resilience Act (DORA) represents a fundamental shift in how the European Union regulates ICT risk management in the financial sector. With full application from 17 January 2025, financial entities across the EU must now demonstrate comprehensive digital operational resilience capabilities.
This guide provides a detailed overview of DORA requirements, helping financial institutions and their ICT service providers understand and implement the necessary measures for compliance.
What is DORA?
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) is an EU regulation that establishes uniform requirements for the security of network and information systems supporting the business processes of financial entities. It entered into force on 16 January 2023 and became fully applicable on 17 January 2025.
DORA creates a comprehensive framework for digital operational resilience across the EU financial sector, ensuring that all participants can withstand, respond to, and recover from ICT-related disruptions and threats.
Related: DORA complements NIS2 cybersecurity requirements for financial entities, creating overlapping obligations that require coordinated compliance efforts.
Why DORA Was Introduced
Before DORA, ICT risk management in the financial sector was addressed through fragmented national requirements and sector-specific guidelines. This led to:
- Inconsistent levels of digital resilience across EU member states
- Regulatory arbitrage opportunities
- Gaps in oversight of critical ICT third-party providers
- Insufficient harmonisation of incident reporting requirements
DORA addresses these challenges by creating a single, coherent regulatory framework applicable across all EU member states and financial sectors.
Key Objectives
DORA aims to achieve several critical goals:
- Harmonise ICT risk management - Establish consistent standards across all financial sectors
- Strengthen digital resilience - Ensure financial entities can withstand severe operational disruptions
- Improve incident response - Create unified incident classification and reporting requirements
- Manage third-party risk - Establish oversight framework for critical ICT service providers
- Promote information sharing - Enable voluntary sharing of cyber threat intelligence
Who Must Comply with DORA?
DORA applies to a broad range of financial entities and their critical ICT service providers.
Financial Entities in Scope
The regulation applies to 21 categories of financial entities:
Banking and Credit
- Credit institutions
- Payment institutions
- Electronic money institutions
- Account information service providers
Investment Services
- Investment firms
- Trading venues
- Central securities depositories
- Central counterparties
- Trade repositories
Insurance and Pensions
- Insurance undertakings
- Reinsurance undertakings
- Insurance intermediaries
- Institutions for occupational retirement provision (IORPs)
Asset Management
- Management companies
- Alternative investment fund managers (AIFMs)
Market Infrastructure
- Data reporting service providers
- Securitisation repositories
- Administrators of critical benchmarks
Crypto Assets
- Crypto-asset service providers (CASPs)
- Issuers of asset-referenced tokens
- Issuers of significant asset-referenced tokens
Credit Rating and Crowdfunding
- Credit rating agencies
- Crowdfunding service providers
ICT Third-Party Service Providers
DORA establishes an oversight framework for critical ICT third-party service providers (CTPPs). These are ICT providers that:
- Support critical or important functions of financial entities
- Are designated as critical by the European Supervisory Authorities (ESAs)
- Are subject to direct oversight by a Lead Overseer
Even non-critical ICT providers must comply with contractual requirements when serving financial entities.
Proportionality Principle
DORA applies proportionally based on:
- Size and overall risk profile of the entity
- Nature, scale, and complexity of services and activities
- Systemic importance
Microenterprises (fewer than 10 employees and annual turnover/balance sheet under EUR 2 million) benefit from a simplified ICT risk management framework.
The Five Pillars of DORA
DORA is structured around five key pillars that together create a comprehensive digital operational resilience framework.
Pillar 1: ICT Risk Management
Financial entities must establish and maintain a comprehensive ICT risk management framework that is:
- Documented and reviewed at least annually
- Approved by the management body
- Integrated into the overall risk management framework
Key Requirements
Governance and Organisation
- Management body bears ultimate responsibility for ICT risk management
- Dedicated ICT risk management function (independent for larger entities)
- Clear roles, responsibilities, and reporting lines
- Adequate resources and budget allocation
ICT Risk Management Framework Components
- ICT risk identification and assessment processes
- Protection and prevention measures
- Detection capabilities for anomalous activities
- Response and recovery procedures
- Learning and evolving mechanisms
- Communication strategies
ICT Asset Management
- Complete inventory of ICT assets (hardware, software, data)
- Classification by criticality and business function
- Regular review and update procedures
ICT Security Policies
- Information security policy approved by management body
- Policies covering access control, encryption, network security
- Data integrity, availability, and confidentiality measures
- Patch management and vulnerability remediation
Business Continuity Management
- ICT business continuity policy
- Business impact analysis for critical functions
- Recovery time and recovery point objectives
- Regular testing of continuity plans
Pillar 2: ICT-Related Incident Management and Reporting
DORA establishes harmonised requirements for detecting, managing, and reporting ICT-related incidents.
Incident Management Process
Financial entities must implement processes to:
- Detect and identify ICT-related incidents
- Classify incidents according to specified criteria
- Determine impact on critical functions
- Initiate response and recovery procedures
- Document lessons learned
Incident Classification Criteria
Incidents must be classified based on:
| Criterion | Considerations |
|---|---|
| Clients affected | Number and proportion of affected clients |
| Data impact | Data losses, integrity breaches, availability issues |
| Critical functions | Impact on critical or important functions |
| Economic impact | Direct and indirect financial losses |
| Duration | Length of service disruption |
| Geographical spread | Member states and third countries affected |
Major Incident Reporting
Major ICT-related incidents must be reported to competent authorities:
| Report Type | Timeline | Content |
|---|---|---|
| Initial notification | Within 4 hours of classification (24 hours for incidents not classified as major within 4 hours) | Basic incident details and initial assessment |
| Intermediate report | Within 72 hours of initial notification | Updated information and response status |
| Final report | Within 1 month of incident resolution | Root cause analysis, lessons learned, remediation actions |
Voluntary Significant Threat Notification
Financial entities may voluntarily notify authorities of significant cyber threats that could potentially impact:
- The financial system
- Service users
- Clients
- Counterparties
Pillar 3: Digital Operational Resilience Testing
DORA requires financial entities to establish, maintain, and review a sound and comprehensive digital operational resilience testing programme.
Testing Programme Requirements
The testing programme must:
- Be proportionate to size and business/risk profile
- Cover all critical ICT systems and applications
- Be documented and reviewed annually
- Include clear testing objectives and methodologies
Types of Testing Required
Basic Testing (All Entities)
- Vulnerability assessments and scans
- Open source analyses
- Network security assessments
- Gap analyses
- Physical security reviews
- Questionnaires and scanning software solutions
- Source code reviews (where feasible)
- Scenario-based tests
- Compatibility testing
- Performance testing
- End-to-end testing
- Penetration testing
Advanced Testing (Significant Entities)
- Threat-Led Penetration Testing (TLPT)
Threat-Led Penetration Testing (TLPT)
TLPT must be performed at least every three years by entities identified as significant. Requirements include:
- Based on realistic threat intelligence
- Cover critical or important functions
- Include live production systems
- Performed by qualified independent testers (internal or external)
- Use TIBER-EU framework or equivalent recognised standards
Testing of Third-Party Providers
When critical functions are supported by ICT third-party service providers:
- Include third-party systems in testing scope
- Ensure contractual rights to test or obtain test results
- Consider pooled testing arrangements
Pillar 4: ICT Third-Party Risk Management
DORA establishes comprehensive requirements for managing risks arising from ICT third-party dependencies.
General Principles
Financial entities must:
- Remain fully responsible for compliance regardless of outsourcing
- Manage ICT third-party risk as integral part of ICT risk framework
- Adopt strategy on ICT third-party risk approved by management body
Register of Information
Maintain a register containing information on all contractual arrangements for ICT services:
| Information Category | Required Details |
|---|---|
| Service provider identification | Name, registration, location, parent company |
| Contractual details | Contract date, duration, termination provisions |
| Services provided | Description, nature, criticality assessment |
| Subcontracting chain | Sub-contractors and their locations |
| Risk assessment | Criticality of function, substitutability |
Contractual Requirements
Contracts with ICT service providers must include:
Service Specifications
- Clear description of functions and services
- Quantitative and qualitative performance targets
- Service level agreements with remediation measures
Security Requirements
- Appropriate security measures
- Incident notification obligations
- Cooperation with competent authorities
Audit and Access Rights
- Unrestricted rights of access, inspection, and audit
- Right to take copies of relevant documentation
- On-site and remote access to premises
Exit Strategy Provisions
- Transition and termination clauses
- Appropriate transition periods
- Assistance obligations during exit
Data Protection
- Data location and processing requirements
- Data portability and return provisions
Critical ICT Third-Party Providers
The ESAs designate critical ICT third-party providers (CTPPs) based on:
- Systemic importance to financial entities
- Degree of substitutability
- Number of member states where services are provided
CTPPs are subject to direct oversight by a Lead Overseer with powers to:
- Request information and documentation
- Conduct general investigations and inspections
- Issue recommendations and require remediation plans
Pillar 5: Information Sharing Arrangements
DORA enables (but does not mandate) financial entities to exchange cyber threat information and intelligence.
Permitted Information Sharing
Financial entities may share:
- Indicators of compromise
- Tactics, techniques, and procedures
- Cybersecurity alerts and configuration tools
- Threat intelligence
Requirements for Sharing Arrangements
Information sharing arrangements must:
- Protect commercially sensitive information
- Maintain personal data protection
- Be conducted within trusted communities
- Follow guidelines issued by competent authorities
Benefits of Information Sharing
Participating in information sharing arrangements helps financial entities:
- Enhance threat awareness and detection capabilities
- Benefit from collective intelligence
- Improve incident response through shared experiences
- Strengthen sector-wide resilience
Implementation Roadmap
Step 1: Governance and Accountability
Establish Management Body Oversight
- Assign ultimate responsibility to management body
- Define roles and responsibilities for ICT risk
- Approve ICT risk management framework and policies
- Ensure adequate resources and training
Create ICT Risk Management Function
- Designate or establish independent ICT risk function
- Define reporting lines to management body
- Ensure appropriate staffing and expertise
Step 2: Gap Analysis and Planning
Assess Current State
- Map existing ICT risk management practices
- Inventory all ICT assets and dependencies
- Document current incident management processes
- Review existing third-party arrangements
Identify Gaps
- Compare current practices against DORA requirements
- Assess proportionality considerations
- Identify areas requiring enhancement
- Prioritise remediation activities
Develop Implementation Plan
- Set realistic timelines for remediation
- Allocate resources and budget
- Assign responsibilities for each workstream
- Establish progress monitoring mechanisms
Step 3: ICT Risk Management Framework
Develop Framework Documentation
- ICT risk management policy
- ICT security policies and procedures
- Business continuity and disaster recovery plans
- ICT asset management procedures
Implement Risk Management Processes
- Risk identification and assessment methodology
- Risk treatment and mitigation measures
- Continuous monitoring and review procedures
- Learning and improvement mechanisms
Step 4: Incident Management
Establish Incident Management Capability
- Define incident detection mechanisms
- Develop classification criteria and procedures
- Create incident response playbooks
- Establish escalation procedures
Prepare Reporting Mechanisms
- Map reporting templates to regulatory requirements
- Establish communication channels with authorities
- Define internal reporting workflows
- Test reporting procedures
Step 5: Resilience Testing Programme
Design Testing Programme
- Define testing objectives and scope
- Select appropriate testing methodologies
- Establish testing frequency and schedule
- Allocate testing resources
Implement Testing
- Conduct baseline testing activities
- Document test results and findings
- Track remediation of identified vulnerabilities
- Plan for advanced testing (TLPT) if applicable
Step 6: Third-Party Risk Management
Review Existing Arrangements
- Inventory all ICT third-party relationships
- Assess criticality of each provider
- Identify contractual gaps
- Evaluate concentration risk
Enhance Contracts
- Negotiate DORA-compliant contract terms
- Include required audit and access rights
- Establish exit strategy provisions
- Address subcontracting requirements
Establish Ongoing Monitoring
- Define monitoring and oversight procedures
- Implement performance tracking mechanisms
- Schedule regular provider assessments
- Develop escalation procedures
Step 7: Documentation and Reporting
Establish Register of Information
- Create comprehensive provider register
- Implement update and maintenance procedures
- Ensure accessibility for regulatory reporting
Prepare for Regulatory Engagement
- Understand reporting obligations
- Establish communication channels with authorities
- Prepare for potential supervisory reviews
DORA and Other Regulations
Relationship with NIS2
DORA is lex specialis to NIS2 for financial entities. This means:
- DORA requirements take precedence for in-scope entities
- NIS2 general provisions apply where DORA is silent
- Financial entities do not need to comply with NIS2 in areas covered by DORA
Relationship with GDPR
DORA complements GDPR:
- Personal data processing must comply with GDPR
- Incident notification under DORA does not replace GDPR breach notification
- Both regimes may apply to the same incident
Relationship with Sector-Specific Requirements
DORA harmonises ICT requirements across financial sectors:
- Replaces fragmented sectoral ICT guidelines
- Provides consistent baseline across all financial entities
- National authorities may impose additional requirements in specific circumstances
Penalties for Non-Compliance
Member states must establish penalties for DORA non-compliance. Potential consequences include:
Administrative Penalties
- Financial penalties proportionate to the breach
- Public statements identifying the entity
- Cease and desist orders
Management Liability
- Personal liability for management body members
- Potential temporary bans from management positions
Business Impact
- Reputational damage
- Increased regulatory scrutiny
- Potential restrictions on business activities
For Critical ICT Third-Party Providers
- Penalty payments up to 1% of average daily worldwide turnover
- Enhanced oversight measures
- Recommendations to financial entities to terminate arrangements
Key Dates and Timeline
| Date | Event |
|---|---|
| 16 January 2023 | DORA entered into force |
| Throughout 2023-2024 | ESAs developed Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) |
| 17 January 2025 | DORA became fully applicable |
| 17 January 2025 onwards | Financial entities must be compliant |
| 30 April 2025 | First submission of register of information to competent authorities |
| Every 3 years (significant entities) | TLPT must be performed |
Conclusion
DORA represents a significant advancement in regulating digital operational resilience within the EU financial sector. The regulation's comprehensive approach, covering ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing, creates a robust framework for ensuring financial entities can withstand and recover from ICT-related disruptions.
For financial entities, achieving DORA compliance requires:
- Strong governance and management body engagement
- Comprehensive ICT risk management capabilities
- Mature incident detection, response, and reporting processes
- Regular and rigorous resilience testing
- Robust oversight of ICT third-party providers
- Active participation in information sharing initiatives
The effort required for compliance is substantial, but the benefits extend beyond regulatory adherence. Organisations that implement DORA requirements effectively will be better positioned to:
- Protect against cyber threats and operational disruptions
- Maintain customer trust and confidence
- Ensure business continuity during crises
- Demonstrate resilience to regulators and stakeholders
Financial entities that have not yet achieved full compliance should prioritise remediation activities, focusing on the most critical gaps and highest-risk areas.
Related Articles
- NIS2 Compliance Checklist - Cybersecurity requirements that complement DORA
- MiFID II Guide - Investment services compliance
- AML Compliance Guide - Anti-money laundering requirements
Get Expert Help
Need support with DORA compliance? Vision Compliance helps financial entities navigate digital operational resilience requirements, from gap analysis through to implementation and testing.
- Financial Compliance Services - DORA, MiFID II, and AML support
- Cybersecurity Services - ICT risk management and resilience testing
- Contact us - Schedule a free consultation