DORA Compliance Guide

Q: 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.

Q: 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.

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
Five pillars	ICT risk management · Incident reporting · Resilience testing · Third-party risk · Information sharing
Penalties	Up to 1 % of average daily worldwide turnover
First register submission	30 April 2025
Key supervisors	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

What Is DORA and Why Does It Exist?
Who Must Comply with DORA?
The Five Pillars of DORA
Pillar 1: ICT Risk Management
Pillar 2: Incident Management and Reporting
Pillar 3: Digital Operational Resilience Testing
Pillar 4: ICT Third-Party Risk Management
Pillar 5: Information Sharing Arrangements
DORA Compliance Checklist
DORA Timeline and Key Dates
Penalties and Management Liability

What Is DORA and Why Does It Exist?

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
Growing cyber risk	Increasingly sophisticated attacks targeting financial infrastructure

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

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

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
2	Incident Management and Reporting	Harmonised classification, 4-hour initial notification
3	Digital Operational Resilience Testing	Annual testing programme, TLPT for significant entities
4	ICT Third-Party Risk Management	Register of information, contractual requirements, exit strategies

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
Intermediate report	72 hours from initial notification	Updated information, response status, root cause analysis (if available), impact reassessment
Final report	1 month from incident resolution	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)

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

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

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)

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	to competent authorities

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

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).

DORA vs NIS2: Key Differences at a Glance

Feature	DORA	NIS2
Incident notification	4 hours (initial)	24 hours (early warning)
Testing requirements	Detailed programme including TLPT	General requirement for security testing
Third-party oversight	EU-level CTPP designation and oversight	General supply chain security provisions
Register of information	Mandatory structured register	No equivalent requirement

DORA and Other EU Regulations

DORA and GDPR

DORA complements GDPR — it does not replace it:

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

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

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

Step 3: ICT Risk Management Framework (Weeks 8-16)

Develop or update the ICT risk management framework and policies
Implement risk identification and assessment methodology
Deploy protection, detection, and response measures
Establish business continuity and disaster recovery plans with defined RTO/RPO
Create or update the information security policy for management body approval
Implement ICT asset management procedures

Step 4: Incident Management (Weeks 12-18)

Define incident detection mechanisms and classification procedures
Develop incident response playbooks for major incident types
Establish the 4-hour notification process and test it through simulations
Create reporting templates aligned with RTS requirements
Set up communication channels with competent authorities
Implement post-incident review and lessons-learned processes

Step 5: Resilience Testing Programme (Weeks 16-24)

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.

NIS2 Compliance Checklist — Cybersecurity requirements that complement DORA for non-financial entities
What Is NIS2? — Complete guide to the EU Cybersecurity Directive
ISO 27001 Implementation Guide — Build the ISMS foundation that supports DORA Pillar 1
GDPR Compliance Guide — Data protection requirements that intersect with DORA

Get Expert Help with DORA Compliance

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.

Financial Compliance Services — DORA, MiFID II, PSD2, and AML compliance support
Cybersecurity Services — ICT risk management, resilience testing, and TLPT coordination
Schedule a Free Consultation — Discuss your DORA compliance needs with our team

RELATED SERVICE

ABOUT THE AUTHOR

Robert Lozo

Partner · CIPP/E · CIPM · CISM

Robert advises organisations on GDPR, NIS2, AI Act, and financial regulation, delivering audit-ready documentation and compliance roadmaps across regulated industries.