DORA Compliance: The Complete Guide to the Digital Operational Resilience Act in 2026
October 16, 2025
Updated: February 22, 2026
28 min read
Financial Compliance
DORA (Digital Operational Resilience Act) is an EU regulation (2022/2554) that requires financial entities and their critical ICT providers to implement comprehensive digital resilience measures across five pillars: ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing.
Quick Reference — Key DORA Facts
Fact
Detail
Full name
Regulation (EU) 2022/2554 on Digital Operational Resilience
Full application
17 January 2025 (no transitional period)
Entities in scope
21 categories of financial entities + critical ICT providers
ECB, EBA, ESMA, EIOPA + national competent authorities
Key Takeaways
DORA is an EU regulation — it applies directly in all 27 member states without national transposition
It covers 21 types of financial entities and their critical ICT third-party providers
The regulation is built on five pillars: ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing
Major incidents must be reported within 4 hours of classification
Significant entities must conduct Threat-Led Penetration Testing (TLPT) every three years
DORA is lex specialis to NIS2 — for financial entities, DORA requirements take precedence
The Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — establishes uniform requirements for the security of network and information systems that support the business processes of financial entities across the European Union.
DORA was adopted on 14 December 2022, entered into force on 16 January 2023, and has been fully applicable since 17 January 2025 — with no transitional period.
The Problem DORA Solves
Before DORA, ICT risk management requirements for the financial sector were fragmented across member states and sectors. Each national regulator set different standards, and sector-specific guidelines (banking, insurance, investment) often overlapped or left gaps. This created:
Problem
Impact
Inconsistent protection levels
Uneven digital resilience across EU member states
Regulatory arbitrage
Entities choosing jurisdictions with weaker ICT rules
Oversight blind spots
No EU-wide framework for monitoring critical ICT providers
Fragmented incident reporting
Different timelines, formats, and thresholds across sectors
Why this matters: The 2020 SolarWinds supply chain attack affected financial institutions across multiple EU member states. The fragmented response and inconsistent disclosure demonstrated the need for a harmonised approach — a key driver behind DORA.
DORA's Five Objectives
Harmonise ICT risk management — Establish consistent standards across all financial sectors and member states
Strengthen digital resilience — Ensure entities can withstand, respond to, and recover from severe ICT disruptions
Improve incident response — Create unified incident classification, reporting timelines, and communication channels
Manage third-party risk — Establish an EU-level oversight framework for critical ICT service providers
Promote information sharing — Enable voluntary exchange of cyber threat intelligence across the sector
Who Must Comply with DORA?
DORA applies to a broad range of financial entities and their critical ICT service providers. The regulation covers 21 categories of financial entities — far more than any previous EU ICT regulation for the sector.
Financial Entities in Scope
Category
Examples
Typical Supervisor
Credit institutions
Banks, savings institutions
ECB / national central banks
Payment institutions
Payment service providers
National financial authorities
Electronic money institutions
E-money issuers
National financial authorities
Account information service providers
Account aggregators
National financial authorities
Investment firms
Brokers, asset managers
ESMA / national securities regulators
Trading venues
Stock exchanges, MTFs, OTFs
ESMA / national securities regulators
Central securities depositories
CSDs
ESMA / national authorities
Central counterparties
Clearing houses (CCPs)
ESMA / national authorities
Trade repositories
Transaction reporting entities
ESMA
Insurance undertakings
Life and non-life insurers
EIOPA / national insurance authorities
Reinsurance undertakings
Reinsurers
EIOPA / national insurance authorities
Insurance intermediaries
Insurance brokers (larger)
National insurance authorities
Institutions for occupational retirement provision
Pension funds (IORPs)
EIOPA / national authorities
Management companies
UCITS fund managers
National securities regulators
Alternative investment fund managers
AIFM managers
National securities regulators
Data reporting service providers
ARMs, APAs, CTPs
ESMA
Securitisation repositories
Securitisation data repositories
ESMA
Administrators of critical benchmarks
Benchmark administrators
National authorities
Crypto-asset service providers
Crypto exchanges, custodians (CASPs)
National financial authorities
Issuers of asset-referenced tokens
ART issuers
EBA / national authorities
Crowdfunding service providers
Crowdfunding platforms
National financial authorities
Credit rating agencies
Rating agencies
ESMA
Critical ICT Third-Party Service Providers (CTPPs)
The European Supervisory Authorities (EBA, ESMA, EIOPA) designate certain ICT providers as critical based on:
Systemic importance of the services to the financial sector
Degree of dependency of financial entities on those services
Substitutability — how easily the provider could be replaced
Number of member states where the provider's services are used
CTPPs face direct oversight by a Lead Overseer appointed by the ESAs, with powers to:
Request information and documentation
Conduct general investigations and on-site inspections
Issue recommendations requiring remediation plans
Impose periodic penalty payments of up to 1 % of average daily worldwide turnover for non-compliance
Practical note: In January 2025, the ESAs designated the first batch of critical ICT providers, including major cloud infrastructure providers serving the EU financial sector.
Proportionality Principle
DORA applies proportionally based on entity size, risk profile, and systemic importance:
Entity Type
ICT Risk Framework
Testing
TLPT Required?
Large / significant entities
Full framework
Comprehensive programme
Yes (every 3 years)
Medium entities
Full framework
Proportionate programme
Depends on designation
Small entities
Full framework (proportionate)
Basic testing
No
Microenterprises (fewer than 10 employees, turnover under EUR 2M)
Simplified framework
Basic testing
No
The Five Pillars of DORA
DORA is structured around five interconnected pillars that together form a comprehensive digital operational resilience framework:
Pillar
Subject
Key Requirement
1
ICT Risk Management
Comprehensive framework with management body oversight
Annual testing programme, TLPT for significant entities
4
ICT Third-Party Risk Management
Register of information, contractual requirements, exit strategies
5
Information Sharing
Voluntary exchange of cyber threat intelligence
Pillar 1: ICT Risk Management
Financial entities must establish, maintain, and continuously improve a comprehensive ICT risk management framework.
Management Body Responsibility
DORA places ultimate responsibility for ICT risk management on the management body (board of directors or equivalent). This is not delegable. Specific obligations include:
Obligation
Details
Approve ICT risk framework
Review and approve the framework at least annually
Allocate budget and resources
Ensure adequate funding for ICT security
Designate responsibility
Appoint a senior manager responsible for ICT risk
Undergo training
Members must receive regular training on ICT risks
Stay informed
Receive regular reports on ICT incidents, testing results, and third-party risks
Set risk appetite
Define and approve the entity's ICT risk tolerance levels
Key point: Management body members can face personal liability for non-compliance with DORA, including financial penalties and temporary bans from management positions.
ICT Risk Management Framework Components
The framework must include six interconnected elements:
Identification — Map all ICT assets, dependencies, and data flows. Maintain a complete, up-to-date inventory classified by criticality and business function.
Protection and Prevention — Implement security measures including access control, encryption, network segmentation, patch management, and vulnerability remediation.
Detection — Deploy capabilities to promptly detect anomalous activities, ICT-related incidents, and potential threats across all critical systems.
Response and Recovery — Establish procedures to respond to and recover from ICT incidents, including business continuity plans with defined RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for each critical function.
Learning and Evolving — Analyse incidents, testing results, and emerging threats to continuously improve the framework.
Communication — Define internal and external communication strategies, including reporting lines to the management body and notification procedures to regulators.
ICT Asset Management
Requirement
Specifics
Inventory scope
All hardware, software, data assets, and network components
Classification
By criticality, business function, and data sensitivity
Dependencies
Map all internal and external dependencies
Review frequency
At least annually, and after significant changes
Legacy systems
Identify and assess risks from legacy ICT systems
Business Continuity Management
Financial entities must maintain ICT business continuity policies covering:
Business Impact Analysis (BIA) for all critical and important functions
Defined RTO and RPO for each critical function
Disaster recovery plans with clear activation criteria
Crisis communication plans covering internal teams, clients, regulators, and the public
Regular testing of continuity and recovery plans (at least annually)
Overlap with ISO 27001: Many Pillar 1 requirements overlap with ISO 27001 controls. Entities with an existing ISMS have a significant head start, but DORA adds specific requirements — particularly around management body oversight, incident reporting timelines, and third-party risk — that go beyond ISO 27001.
Pillar 2: Incident Management and Reporting
DORA introduces a harmonised incident management and reporting regime across all EU financial sectors — replacing the patchwork of sector-specific requirements.
Incident Classification Criteria
All ICT-related incidents must be classified based on six criteria:
Criterion
What to Assess
Clients affected
Number and proportion of affected clients and financial counterparts
Data impact
Data losses, breaches of integrity, unauthorised access, or data unavailability
Critical functions
Whether critical or important functions are impacted
Economic impact
Direct and indirect financial losses, including remediation costs
Duration
Length of service disruption or degradation
Geographical spread
Member states and third countries affected
An incident qualifies as major when it meets defined thresholds across these criteria (specified in the Regulatory Technical Standards).
Major Incident Reporting Timelines
Report
Deadline
Required Content
Initial notification
4 hours from classification as major (or 24 hours if not immediately classified)
Basic incident details, initial impact assessment, notification of whether the incident is likely to be caused by an attack
Root cause analysis, lessons learned, remediation actions taken, total impact assessment
Critical warning: The 4-hour window for initial notification requires pre-established procedures, clear escalation paths, and trained on-call teams. Organisations that fail to prepare these in advance risk breaching DORA even when they successfully resolve the underlying incident.
Voluntary Cyber Threat Notification
Financial entities may voluntarily notify competent authorities of significant cyber threats — even if they do not result in an incident. This helps the sector collectively:
Improve early warning capabilities
Enhance threat detection across the financial ecosystem
Support the supervisory authority's situational awareness
Pillar 3: Digital Operational Resilience Testing
DORA requires financial entities to establish, maintain, and review a comprehensive digital operational resilience testing programme proportionate to their size and risk profile.
Basic Testing Programme (All Entities)
All financial entities must conduct the following tests, documented and reviewed annually:
Test Type
Description
Vulnerability assessments and scans
Automated scanning of systems for known vulnerabilities
Open source analysis
Review of open source components for security risks
Network security assessments
Testing of network architecture and security controls
Gap analysis
Comparison of current state against DORA requirements
Physical security reviews
Assessment of data centre and facility security
Source code reviews
Static analysis of critical application source code (where feasible)
Scenario-based testing
Simulation of realistic disruption scenarios
Compatibility testing
Verification of system interoperability
Performance testing
Load and stress testing under peak conditions
End-to-end testing
Validation of complete process chains
Penetration testing
Simulated attacks on ICT systems and infrastructure
Threat-Led Penetration Testing (TLPT)
Significant entities — as identified by competent authorities — must conduct TLPT at least every three years. TLPT is a far more rigorous exercise than standard penetration testing.
TLPT Requirement
Details
Threat intelligence
Based on realistic, current threat intelligence specific to the entity
Scope
Must cover critical or important functions, including live production systems
Testers
Qualified, independent testers (internal or external) meeting specific competency criteria
Framework
Must follow TIBER-EU or equivalent recognised standards
Red team
Use of red team techniques simulating actual adversary tactics
Purple teaming
Combined red/blue team exercises to maximise learning
Results
Shared with the competent authority and used to update the risk assessment
Expert tip: TLPT is not a standard pentest. It requires realistic adversary simulation based on genuine threat intelligence, involves live production systems, and demands specialised tester qualifications. Budget and plan accordingly — a typical TLPT engagement takes 6-12 months from scoping to final report.
Testing Third-Party Systems
When critical functions are supported by ICT third-party providers:
The testing programme must include third-party systems in scope
Contracts must include audit and testing rights (or the right to obtain test results)
Pooled testing arrangements are permitted where multiple financial entities share the same provider
Pillar 4: ICT Third-Party Risk Management
DORA establishes the most comprehensive third-party ICT risk management requirements in any EU regulation, reflecting the financial sector's growing dependency on cloud services, outsourced infrastructure, and technology vendors.
Core Principles
Full responsibility retained — Financial entities remain fully responsible for compliance regardless of outsourcing arrangements
Integrated risk management — Third-party ICT risk is an integral part of the overall ICT risk management framework
Board-level strategy — The management body must approve and review the ICT third-party risk strategy
Concentration risk — Entities must assess and manage concentration risk from excessive dependence on a single provider
Register of Information
One of DORA's most operationally demanding requirements is the register of information — a comprehensive, structured record of all ICT service arrangements.
Register Category
Required Information
Provider identification
Legal name, LEI, registration number, location, parent company, group structure
Contract details
Start date, duration, renewal terms, termination provisions, governing law
Services provided
Full description, nature, scope, criticality classification
Subcontracting chain
Sub-contractors, their locations, and their roles in the service delivery chain
Risk assessment
Criticality of the function supported, substitutability analysis, concentration risk assessment
Data processing
Data locations, data classification, personal data processing details
Audit rights
Contractual audit provisions, last audit date, findings
First submission deadline: Entities must submit their register of information to competent authorities by 30 April 2025.
Contractual Requirements
All contracts with ICT service providers must include:
Service Specifications
Clear description of all functions and services
Quantitative and qualitative performance targets
Service Level Agreements (SLAs) with remediation measures for underperformance
Security and Incident Management
Appropriate security measures aligned with the entity's ICT risk framework
Incident notification obligations (must support the entity's 4-hour reporting deadline)
Cooperation obligations with competent authorities
Audit, Access, and Inspection
Unrestricted rights of access, inspection, and audit for the entity and its supervisor
Right to take copies of relevant documentation
On-site and remote access to the provider's premises
Exit Strategy
Transition and termination clauses ensuring continuity
Appropriate transition periods
Assistance obligations during exit
Data return and deletion provisions
Data Protection
Data location and processing requirements aligned with GDPR
Data portability and return provisions
Sub-processing limitations and notification requirements
Practical note: Major cloud providers (AWS, Azure, Google Cloud) have updated their standard financial services contracts to address DORA requirements. However, entities must verify that the specific contractual terms meet DORA's detailed requirements — standard terms may not be sufficient for all provisions.
Pillar 5: Information Sharing Arrangements
DORA enables but does not mandate financial entities to exchange cyber threat information and intelligence within trusted communities.
What Can Be Shared
Indicators of compromise (IoCs) — IP addresses, domains, file hashes linked to threats
Tactics, techniques, and procedures (TTPs) — Methods used by threat actors
Cybersecurity alerts — Warnings about active or emerging threats
Configuration tools — Defensive tools and security configurations
Requirements for Sharing
Requirement
Details
Trusted community
Sharing must occur within established, trusted frameworks
Commercial confidentiality
Commercially sensitive information must be protected
Personal data
All sharing must comply with GDPR requirements
Regulatory guidelines
Follow guidance issued by competent authorities
Notification
Inform the competent authority of participation in sharing arrangements
Benefits of Participation
While voluntary, information sharing offers significant advantages:
Early warning of emerging threats targeting the financial sector
Collective intelligence improving detection and response capabilities
Reduced response times through shared incident experiences
Sector-wide resilience through coordinated defensive measures
DORA Compliance Checklist
Use this checklist to assess your organisation's DORA compliance status across all five pillars:
Governance and Accountability
Management body has formally approved the ICT risk management framework
A senior manager is designated as responsible for ICT risk
Management body receives regular ICT risk reports (incidents, testing, third-party)
Management body members undergo regular ICT risk training
ICT risk management budget and resources are adequate and approved
ICT risk appetite and tolerance levels are defined and documented
ICT Risk Management (Pillar 1)
Complete inventory of all ICT assets (hardware, software, data) is maintained
ICT assets are classified by criticality and business function
ICT risk identification and assessment methodology is documented
Protection measures are in place: access control, encryption, network security
Detection capabilities cover all critical systems and applications
Business continuity and disaster recovery plans are documented and tested
RTO and RPO are defined for each critical function
Patch management and vulnerability remediation processes are operational
Information security policy is approved by management body
Framework is reviewed and updated at least annually
Incident Management (Pillar 2)
Incident detection mechanisms cover all critical ICT systems
Classification criteria and procedures align with DORA's six criteria
Incident response playbooks exist for major incident types
4-hour initial notification process is tested and ready
Reporting templates match RTS requirements (initial, intermediate, final)
Communication channels with competent authorities are established
Post-incident reviews and lessons-learned processes are formalised
Incident register is maintained with full documentation
Resilience Testing (Pillar 3)
Annual testing programme is documented and approved
All required test types are included (vulnerability scans, pentests, scenario tests, etc.)
Testing covers all critical ICT systems and applications
Third-party systems are included in the testing scope
Test results are documented, reviewed, and tracked for remediation
TLPT programme is planned (if designated as significant entity)
TLPT testers meet independence and competency requirements
TIBER-EU framework or equivalent is being followed for TLPT
Third-Party Risk Management (Pillar 4)
Strategy on ICT third-party risk is approved by management body
Complete inventory of all ICT service providers exists
Each provider is assessed for criticality and substitutability
Register of information is complete and structured per RTS requirements
All contracts include required DORA provisions (SLAs, audit rights, exit strategy)
Concentration risk is assessed and documented
Ongoing monitoring and performance tracking is operational
Exit strategies exist for all critical and important ICT arrangements
Subcontracting chains are documented and approved
Information Sharing (Pillar 5)
Decision made on participation in information sharing arrangements
If participating, arrangement complies with GDPR and confidentiality requirements
Competent authority is notified of participation
DORA Timeline and Key Dates
Date
Event
14 December 2022
DORA regulation adopted by the European Parliament and Council
16 January 2023
DORA entered into force
17 January 2024
First batch of Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) published
17 July 2024
Second batch of RTS/ITS published
17 January 2025
DORA became fully applicable — all entities must be compliant
30 April 2025
First submission of register of information to competent authorities
17 January 2028
First mandatory TLPT cycle completion (for significant entities designated in 2025)
Note: Unlike NIS2, DORA is a regulation, not a directive. It applies directly in all EU member states without requiring national transposition. Some member states have adopted supplementary implementation laws to designate competent authorities and set enforcement details.
Penalties and Management Liability
Financial Penalties
DORA leaves penalty-setting to member states, but establishes a floor for critical ICT providers and sets expectations for financial entities:
Entity Type
Penalty Framework
Financial entities
Member states set penalties that must be "effective, proportionate, and dissuasive" — specifics vary by country
Critical ICT third-party providers (CTPPs)
Periodic penalty payments of up to 1 % of average daily worldwide turnover in the preceding business year, for up to six months
Administrative Measures
Competent authorities can impose:
Cease and desist orders requiring the entity to stop the infringing conduct
Public statements identifying the entity and the nature of the breach
Temporary bans on management body members holding management positions
Withdrawal of authorisation in the most serious cases
Orders to terminate ICT arrangements with providers that pose systemic risk
Management Body Liability
DORA explicitly establishes that members of the management body can be held personally liable for failures in ICT risk management. Potential consequences include:
Consequence
Description
Financial penalties
Personal fines set by national law
Temporary management bans
Prohibition from holding management positions
Reputational impact
Public disclosure of enforcement actions
Civil liability
Potential claims from shareholders or affected parties
Warning: Unlike general corporate governance rules, DORA's management liability provisions are specific and cannot be delegated away. Board members must demonstrate active engagement with ICT risk — not merely sign-off.
DORA vs NIS2: How They Interact
One of the most common questions in DORA compliance is how it relates to the NIS2 Directive. The answer is defined by the lex specialis principle.
The Lex Specialis Relationship
DORA is lex specialis (the more specific law) to NIS2 for financial entities. In practice:
Aspect
DORA
NIS2
Legal instrument
Regulation (directly applicable)
Directive (requires national transposition)
Scope
Financial sector (21 entity types)
Cross-sector (essential and important entities)
ICT risk management
DORA requirements apply
NIS2 defers to DORA for financial entities
Incident reporting
DORA timelines and templates apply
NIS2 defers to DORA for financial entities
Supervisory authority
Financial regulators (EBA, ESMA, EIOPA)
NIS2 national competent authorities
Where DORA is silent
N/A
NIS2 general provisions apply
Supply chain security
DORA Pillar 4 applies
NIS2 supply chain provisions may supplement
Penalties
DORA penalty framework
NIS2 penalties do not apply where DORA covers
Practical Implications
Financial entities: Comply with DORA as your primary ICT regulation. NIS2 fills gaps only where DORA does not address a topic.
Dual-regulated entities: Some entities may fall under both DORA and NIS2 (e.g., a financial entity that also provides essential services). Coordinate compliance to avoid duplication.
ICT providers: If you serve both financial and non-financial clients, you may need to comply with DORA (contractual requirements from financial clients) and NIS2 (if designated as essential or important).
Personal data processing under DORA must comply with GDPR
Incident notification under DORA does not replace GDPR breach notification — both may be required for the same incident
DORA's data protection contractual requirements supplement GDPR processor requirements
Different notification timelines: DORA (4 hours for initial notification) vs GDPR (72 hours for breach notification)
DORA and Sector-Specific Regulations
Regulation
Relationship with DORA
MiFID II / MiFIR
DORA harmonises ICT requirements previously addressed through MiFID II guidelines; investment firms comply with DORA for ICT matters
Solvency II
DORA replaces ICT-related Solvency II guidelines for insurers
PSD2
Payment institutions comply with DORA for operational resilience; PSD2 strong authentication requirements continue
MiCA
Crypto-asset service providers comply with both MiCA (market conduct) and DORA (operational resilience)
CSRD
CSRD reporting may reference DORA compliance as part of governance disclosures
AI Act
Financial entities using AI must comply with DORA for ICT risk of AI systems and the AI Act for AI-specific requirements
Register of Information: What You Need to Know
The register of information is one of DORA's most operationally demanding requirements. It requires a structured, comprehensive record of all ICT service arrangements.
Structure and Format
The ESAs have published Implementing Technical Standards (ITS) specifying the exact format, templates, and data fields. The register follows a standardised structure:
Template
Contents
B_01
Entity-level information
B_02
Contractual arrangement identification
B_03
ICT third-party service provider information
B_04
Subcontracting chain information
B_05
Functions supported by the arrangement
B_06
ICT services provided
B_99
Changes and updates
Common Challenges
Data completeness — Many entities discover they lack full information about their ICT service providers, especially for indirect and legacy arrangements
Subcontracting visibility — Mapping the full subcontracting chain often requires extensive engagement with providers
Criticality assessment — Determining which arrangements support critical or important functions requires close coordination between ICT, risk, and business teams
Ongoing maintenance — The register is not a one-time exercise; it must be kept current as arrangements change
Standardisation — Ensuring all data matches the ITS templates and formats requires dedicated data management effort
Deadline reminder: The first register submission was due 30 April 2025. Entities must maintain the register on an ongoing basis and submit updates as required by their competent authority.
Implementation Roadmap
For organisations working to achieve or maintain DORA compliance, this seven-step roadmap provides a structured approach:
Step 1: Scoping and Governance (Weeks 1-4)
Confirm whether your entity falls within DORA's scope and identify the applicable competent authority
Assign management body responsibility for DORA compliance
Designate a senior ICT risk officer
Establish a DORA project team with representatives from ICT, risk, compliance, legal, and operations
Allocate budget and resources
Step 2: Gap Analysis (Weeks 4-8)
Map existing ICT risk management practices against all five DORA pillars
Inventory all ICT assets, systems, and dependencies
Review existing incident management processes and reporting capabilities
Audit all ICT third-party arrangements
Assess current testing programme against DORA requirements
Document gaps and prioritise remediation by risk and regulatory significance
Design the annual testing programme covering all required test types
Conduct baseline vulnerability assessments and penetration tests
Schedule and execute scenario-based testing for critical functions
Document all results and track remediation of findings
If designated as significant, begin planning the TLPT programme (scope, threat intelligence, tester selection)
Step 6: Third-Party Risk Management (Weeks 8-20)
Complete the inventory of all ICT third-party service providers
Assess criticality and substitutability for each arrangement
Review and renegotiate contracts to include DORA-required provisions
Build and populate the register of information per ITS templates
Establish ongoing monitoring and performance tracking
Develop exit strategies for critical and important arrangements
Assess and document concentration risk
Step 7: Ongoing Compliance (Continuous)
Review and update the ICT risk management framework annually
Execute the annual testing programme
Maintain the register of information with ongoing updates
Report incidents according to DORA timelines
Provide regular ICT risk reports to the management body
Update management body training on ICT risks
Conduct TLPT every three years (if applicable)
Frequently Asked Questions
Does DORA apply to my organisation?
If your entity is one of the 21 types of financial entities listed in DORA Article 2(1) and operates within the EU, yes — DORA applies directly from 17 January 2025. This includes banks, payment institutions, investment firms, insurers, fund managers, crypto-asset service providers, and more.
What is the deadline for DORA compliance?
DORA has been fully applicable since 17 January 2025. There is no transitional period. The first register of information submission was due 30 April 2025.
How does DORA differ from NIS2?
DORA is lex specialis (the more specific law) to NIS2 for financial entities. Where DORA covers a topic, its requirements take precedence. NIS2 applies where DORA is silent. Key differences: DORA has a 4-hour incident notification (vs NIS2's 24-hour early warning), mandatory structured testing including TLPT, and an EU-level oversight framework for critical ICT providers.
What is the 4-hour incident reporting requirement?
When a financial entity classifies an ICT-related incident as major, it must submit an initial notification to its competent authority within 4 hours of that classification. An intermediate report follows within 72 hours, and a final report within one month of resolution.
Does ISO 27001 help with DORA compliance?
ISO 27001 provides an excellent foundation for Pillar 1 (ICT risk management). However, DORA has specific requirements that go beyond ISO 27001 — particularly around incident reporting timelines (the 4-hour rule), TLPT, third-party risk management with a structured register of information, and explicit management body accountability. Our ISO 27001 guide maps the overlap in detail.
What are the penalties for DORA non-compliance?
Penalties vary by member state for financial entities (required to be "effective, proportionate, and dissuasive"). For critical ICT third-party providers, the ESAs can impose periodic penalty payments of up to 1 % of average daily worldwide turnover for up to six months. Additionally, management body members face personal liability including financial penalties and management bans.
What is TLPT and who must do it?
Threat-Led Penetration Testing (TLPT) is an advanced testing exercise based on realistic threat intelligence that simulates real-world adversary tactics against an entity's live production systems. Entities designated as significant by their competent authorities must conduct TLPT at least every three years, following the TIBER-EU framework or equivalent.
What is the register of information?
The register of information is a comprehensive, structured record of all contractual arrangements for ICT services. It must include provider details, contractual terms, services provided, subcontracting chains, criticality assessments, and data processing information — formatted according to ITS templates published by the ESAs. It must be submitted to competent authorities and kept continuously up to date.
Related Articles
NIS2 Compliance Checklist — Cybersecurity requirements that complement DORA for non-financial entities
What Is NIS2? — Complete guide to the EU Cybersecurity Directive
Need support with the Digital Operational Resilience Act? Vision Compliance helps financial entities across the EU achieve and maintain DORA compliance — from initial gap analysis through implementation, testing, and ongoing monitoring.
Robert Lozo, mag. iur., is a Partner at Vision Compliance specializing in EU regulatory compliance. He advises organizations on GDPR, NIS2, AI Act, and financial regulation, delivering audit-ready documentation and compliance roadmaps across regulated industries.
