DORA Compliance Expert

Tools and guidance for Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (Digital Operational Resilience Act — DORA).

DORA Overview
Scope
Five Pillars Deep-Dive
Penalties and Enforcement
DORA Implementation Roadmap
Infrastructure Checks
Tools
Reference Guides

DORA Overview

The Digital Operational Resilience Act (Regulation EU 2022/2554) establishes a comprehensive framework for ICT risk management in the EU financial sector. It entered into force on January 16, 2023, and has been applicable since January 17, 2025.

Key objectives:

Ensure financial entities can withstand, respond to, and recover from all types of ICT-related disruptions and threats
Harmonize ICT risk management requirements across the financial sector
Establish an oversight framework for critical ICT third-party service providers
Promote information sharing on cyber threats within the financial sector

Legal nature: Unlike NIS2 (a directive requiring national transposition), DORA is a regulation — directly applicable in all EU Member States without transposition.

Relationship to other frameworks:

Framework	Relationship
NIS2 Directive	DORA is lex specialis (specific law) for financial sector; NIS2 applies residually
GDPR	DORA complements GDPR for security of ICT systems processing personal data
EBA Guidelines on ICT	DORA supersedes prior EBA guidelines on ICT and security risk management
PSD2	DORA enhances and extends PSD2 operational resilience requirements
MiCA	Crypto-asset service providers are in scope of both MiCA and DORA
ISO 27001	DORA requirements map to ISO 27001 controls; certification supports compliance

Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS):

DORA is supplemented by detailed RTS/ITS developed by the European Supervisory Authorities (ESAs: EBA, ESMA, EIOPA). Key RTS/ITS cover:

ICT risk management framework details
Incident classification criteria and reporting formats
Threat-led penetration testing (TLPT) methodology
ICT third-party register format
Oversight framework procedures

Scope

DORA applies to 20 types of financial entities and their critical ICT third-party service providers.

Financial Entities in Scope

#	Entity Type	Examples
1	Credit institutions	Banks, building societies
2	Payment institutions	Payment service providers
3	Account information service providers	Open banking providers
4	Electronic money institutions	E-money issuers
5	Investment firms	Broker-dealers, portfolio managers
6	Crypto-asset service providers	Crypto exchanges, custodians
7	Issuers of asset-referenced tokens	Stablecoin issuers
8	Central securities depositories	CSDs
9	Central counterparties	CCPs
10	Trading venues	Stock exchanges, MTFs, OTFs
11	Trade repositories	Transaction reporting repositories
12	Managers of alternative investment funds	Hedge fund managers, PE managers
13	Management companies (UCITS)	Mutual fund managers
14	Data reporting service providers	ARMs, APAs
15	Insurance and reinsurance undertakings	Insurance companies
16	Insurance intermediaries	Insurance brokers (except SMEs)
17	Institutions for occupational retirement provision	Pension funds
18	Credit rating agencies	S&P, Moody's, Fitch, etc.
19	Administrators of critical benchmarks	LIBOR/EURIBOR administrators
20	Crowdfunding service providers	Investment crowdfunding platforms

Proportionality Principle

DORA applies proportionately based on the entity's:

Size and overall risk profile
Nature, scale, and complexity of services, activities, and operations
Systemic importance

Simplified ICT risk management framework is available for:

Small and non-interconnected investment firms
Payment institutions exempted under PSD2
Institutions exempted under Directive 2013/36/EU
Electronic money institutions exempted under EMD2
Small IORPs

Critical ICT Third-Party Service Providers

The ESAs designate critical ICT third-party service providers (CTPPs) based on:

Systemic impact of the services on financial entities
Systemic character or importance of financial entities relying on the provider
Degree of substitutability of the provider
Number of Member States in which the provider operates

CTPPs are subject to the Direct Oversight Framework by the Lead Overseer (one of the ESAs).

Five Pillars Deep-Dive

Pillar 1: ICT Risk Management (Chapter II, Articles 5–16)

The cornerstone of DORA. Financial entities must establish a comprehensive ICT risk management framework.

Governance and Organization (Article 5)

The management body bears ultimate responsibility for ICT risk management:

Define, approve, oversee, and be responsible for the implementation of the ICT risk management framework
Define appropriate risk tolerance level for ICT risk
Approve the digital operational resilience strategy
Allocate adequate budget for ICT risk management
Approve and review the ICT business continuity policy and ICT response and recovery plans
Be informed at least once a year on findings of ICT risk reviews

Organizational requirements:

Designate an ICT risk management function (second line of defense)
Ensure adequate separation of ICT risk management, control, and internal audit functions
Establish clear roles and responsibilities for all ICT-related functions
Implement reporting lines ensuring the management body receives timely information

ICT Risk Management Framework (Article 6)

Entities must establish, maintain, and implement a sound, comprehensive, and well-documented ICT risk management framework that:

Ensures a high level of digital operational resilience
Is documented and reviewed at least annually (or after major ICT incidents)
Includes a digital operational resilience strategy
Defines how the framework supports the entity's business strategy
Sets clear information security objectives
Defines ICT risk tolerance levels
Commits to a continuous improvement process

Digital Operational Resilience Strategy must include:

Methods for addressing ICT risk
Explanation of how the ICT risk management framework supports the business strategy
ICT risk tolerance level
Key information security objectives
Overview of ICT reference architecture and changes needed
Mechanisms for detecting ICT anomalies
ICT third-party risk strategy
Digital operational resilience testing approach
Communication strategy for incident disclosure

ICT Systems, Protocols, and Tools (Article 7)

Requirements for ICT systems and infrastructure:

Use and maintain updated ICT systems, protocols, and tools that are adequate to support critical operations
Monitor effectiveness of ICT systems
Identify all sources of ICT risk (including environmental risks and physical threats)
Ensure appropriate network security management
Implement mechanisms for detecting anomalous activities

Identification (Article 8)

Identify, classify, and adequately document all ICT-supported business functions, information assets, and ICT assets
Identify all sources of ICT risk, particularly cyber threats
Map the interconnections and interdependencies with ICT third-party providers
Perform ICT risk assessments at least annually (and after major changes)
Identify assets and systems critical to business operations

Protection and Prevention (Article 9)

Implement ICT security policies, procedures, protocols, and tools
Continuously monitor and control the security and functioning of ICT systems
Design network connection resilience mechanisms
Deploy strong authentication mechanisms (MFA, Article 9(4))
Implement ICT change management policies
Apply software patching policies
Implement data and system access policies based on least privilege

Detection (Article 10)

Put in place mechanisms to promptly detect anomalous activities
Detect network performance issues and ICT-related incidents
Deploy multiple layers of controls (including automated alerting)
Implement detection mechanisms that enable a fast response
Allocate sufficient resources for monitoring trading activities

Response and Recovery (Article 11)

Implement a comprehensive ICT business continuity policy
Develop ICT response and recovery plans
Activate response plans upon identification of ICT incidents
Estimate preliminary impacts, damages, and losses
Set communication and crisis management actions
Execute ICT response and recovery procedures as appropriate

Specific requirements:

Record all ICT-related incidents and significant cyber threats
Activate containment measures and restoration of operations
Implement backup and restoration policies and procedures
When restoring data from backups, maintain the integrity and confidentiality of data

Backup and Restoration (Article 12)

Establish backup policies specifying scope, frequency, and retention
Restore backup data on separate ICT systems (not directly connected to source)
Regularly test backup procedures and restoration capabilities
When restoring data, ensure integrity checks are performed
Maintain redundant ICT capacities equipped with sufficient resources

Learning and Evolving (Article 13)

Gather information on vulnerabilities, cyber threats, and ICT-related incidents
Review ICT-related incidents after recovery (post-incident reviews)
Implement findings of post-incident reviews and digital operational resilience testing
Monitor effectiveness of the ICT risk management framework
Deliver mandatory annual ICT security awareness training for all staff
Develop ICT security awareness programs for non-ICT staff

Communication (Article 14)

Develop crisis communication plans for internal and external stakeholders
Designate at least one spokesperson to communicate externally during incidents
Define communication policies for responsible disclosure of ICT-related incidents
Inform relevant clients and the public when appropriate

Pillar 2: ICT-Related Incident Management (Chapter III, Articles 17–23)

Incident Management Process (Article 17)

Financial entities must:

Define, establish, and implement an ICT-related incident management process
Put in place early warning indicators to trigger detection
Establish procedures to identify, track, log, categorize, and classify ICT-related incidents
Assign roles and responsibilities for different incident types/scenarios
Define plans for communication to staff, external stakeholders, media, and competent authorities

Classification of ICT-Related Incidents (Article 18)

Entities must classify incidents based on these criteria:

Criterion	Description
Number of clients/counterparts affected	Scale of impact on external parties
Duration	Length of the incident
Geographic spread	Jurisdictions and Member States affected
Data losses	Availability, authenticity, integrity, or confidentiality of data
Criticality of services affected	Impact on critical or important functions
Economic impact	Direct and indirect financial costs

Major incident determination: An incident is classified as major if it meets the thresholds defined in the RTS on incident classification.

Reporting Obligations (Article 19)

Stage	Deadline	Content
Initial notification	Within 4 hours of classifying as major (or 24 hours from detection)	Basic facts, initial classification, estimated impact
Intermediate report	Within 72 hours of initial notification	Updated information, severity, root cause assessment, recovery status
Final report	Within 1 month of intermediate report	Root cause analysis, complete impact assessment, mitigation measures, lessons learned

Additional requirements:

Entities must inform their clients without undue delay about major ICT-related incidents that affect their financial interests
Entities must report to the competent authority using specified templates
Competent authorities may request additional information at any time

Voluntary Reporting (Article 19(2))

Entities may voluntarily report:

Significant cyber threats (even if they have not resulted in an incident)
Near-misses that could have caused a major incident

Centralized Reporting (Article 20)

The ESAs develop common templates and procedures for incident reporting to reduce burden and ensure consistency.

Pillar 3: Digital Operational Resilience Testing (Chapter IV, Articles 24–27)

General Requirements (Article 24)

All financial entities must establish, maintain, and review a digital operational resilience testing program as an integral part of their ICT risk management framework.

Basic Testing (Article 25)

All entities must perform, at a minimum:

Test Type	Frequency	Description
Vulnerability assessments and scans	Regular (at least annually)	Automated and manual vulnerability identification
Open-source analyses	Regular	Assessment of open-source software risks
Network security assessments	Annual minimum	Network architecture, configuration, traffic analysis
Gap analyses	Annual minimum	Comparison of current controls vs requirements
Physical security reviews	Periodic	Data center, office, and facility security
Questionnaires and scanning software	Regular	Compliance checking and configuration verification
Source code reviews	Where applicable	Security-focused code review for in-house applications
Scenario-based tests	Annual	Tabletop exercises, simulations
Compatibility testing	As needed	Testing for system updates and changes
Performance testing	Regular	Load and stress testing for critical systems
End-to-end testing	Regular	Testing of complete business process chains
Penetration testing	Annual minimum	Simulated attack testing

Advanced Testing — Threat-Led Penetration Testing (Article 26)

Applicable to: Entities identified by competent authorities based on systemic importance, ICT risk profile, and criticality of services.

TLPT requirements:

Based on the TIBER-EU framework
Covers critical or important functions mapped to services, business processes, and ICT
Conducted at least every 3 years
Scope is determined by the financial entity, validated by the competent authority
Must include live production systems
The management body must approve the scope

TLPT methodology:

Scoping phase: Identify critical functions and supporting ICT infrastructure
Threat intelligence phase: Gather threat intelligence specific to the entity's sector and geography
Red team phase: Execute realistic attack scenarios against production systems
Closure phase: Report findings, remediation planning
Purple team phase: Collaborative exercises between red team (attackers) and blue team (defenders)

Key rules:

Conducted by external testers with appropriate qualifications and independence
Internal testers may participate under specific conditions
Test results must be validated by competent authority
Remediation plans must be produced and implemented
Summary results must be shared with the competent authority

Purple Teaming

DORA introduces purple teaming as a key element:

Collaborative exercise between red team and blue team
Red team shares tactics, techniques, and procedures (TTPs) used
Blue team reviews detection and response capabilities
Joint identification of gaps and improvement areas
Mandatory as part of the TLPT closure phase

Pillar 4: ICT Third-Party Risk Management (Chapter V, Articles 28–44)

General Principles (Article 28)

Financial entities must:

Manage ICT third-party risk as an integral component of ICT risk management
Be responsible at all times for compliance, regardless of outsourcing
Define strategy on ICT third-party risk (part of the digital resilience strategy)
Maintain and update a register of information relating to all contractual arrangements on ICT services

Preliminary Assessment (Article 28(4))

Before entering into a contractual arrangement, entities must:

Identify and assess all relevant risks (including concentration risk)
Assess whether the arrangement covers critical or important functions
Conduct appropriate due diligence on prospective ICT third-party providers
Identify and assess conflicts of interest
Verify the ICT third-party provider's ability to comply with applicable regulations

Key Contractual Provisions (Article 30)

Contracts with ICT third-party service providers must include:

Provision	Description
Clear service descriptions	Complete description of all services, including SLAs
Location requirements	Where data will be processed and stored, including sub-processing
Data protection provisions	Measures ensuring availability, authenticity, integrity, and confidentiality
Service level commitments	Quantitative and qualitative performance targets
Assistance obligations	ICT provider must assist with ICT incidents affecting the entity
Cooperation with authorities	Provider must cooperate with competent authorities and resolution authorities
Termination rights	Clear termination rights, including for performance failures and regulatory changes
Transition and exit provisions	Adequate transition periods and assistance for orderly transfer of services
Participation in TLPT	ICT provider must participate in entity's threat-led penetration testing
Audit rights	Full access and audit rights, including on-site inspections of the ICT provider
Unrestricted right to monitor	Right to continuously monitor provider's performance
Exit strategies	Mandatory exit strategies for critical or important function outsourcing

For critical or important functions, additional contractual requirements apply:

More detailed service level descriptions
Notice periods and reporting obligations for material developments
Full access to performance and security data
ICT provider must implement and test business continuity plans
Provider must provide staff training on ICT security awareness

Register of ICT Third-Party Arrangements (Article 28(3))

Entities must maintain a register containing:

All contractual arrangements with ICT third-party providers
Distinction between critical/important and non-critical functions
Entity identification details (LEI, type, group structure)
Service details (type, start date, end date, governing law, data processing locations)
Sub-contractor chain information
Exit strategy information

The register must be reported to competent authorities upon request.

Exit Strategies (Article 28(8))

For critical or important functions, entities must:

Develop exit strategies that are comprehensive, documented, and tested
Ensure sufficient transition arrangements that avoid disruption or degradation of services
Consider alternative solutions and transition plans
Enable recovery of data and applications

Oversight Framework for Critical ICT Third-Party Providers (Articles 31–44)

The ESAs designate CTPPs and assign a Lead Overseer. The oversight framework includes:

Direct supervision powers over CTPPs
On-site inspections of CTPPs
Power to request information and issue recommendations
Annual oversight plans
CTPPs must cooperate with the Lead Overseer
Non-compliance may result in periodic penalty payments

Concentration Risk (Article 29)

Entities must:

Identify and assess risks arising from concentrating ICT service arrangements on a single provider
Assess whether planned ICT outsourcing leads to material concentration risk
Consider the substitutability of the ICT third-party provider
Develop multi-vendor strategies where appropriate

Pillar 5: Information Sharing (Chapter VI, Article 45)

Voluntary Cyber Threat Intelligence Sharing

Financial entities may exchange amongst themselves cyber threat intelligence information including:

Indicators of compromise (IoCs)
Tactics, techniques, and procedures (TTPs)
Cybersecurity alerts and configuration tools
Tools and methods for detecting cyberattacks

Requirements for Sharing Arrangements

Sharing must aim to enhance digital operational resilience
Must be within trusted communities of financial entities
Arrangements must respect business confidentiality and data protection
Must protect personal data in accordance with GDPR
Sharing may be enabled through information sharing and analysis centers (ISACs)

Notification Requirements

Entities must notify competent authorities of their participation in information-sharing arrangements.

Penalties and Enforcement

Administrative Penalties

DORA delegates penalty-setting to Member States and competent authorities. The regulation empowers authorities to impose:

Administrative penalties and remedial measures proportionate to the infringement
Periodic penalty payments to compel compliance
Public statements identifying the entity and the nature of the infringement
Orders to cease conduct and to desist from repetition
Temporary or permanent prohibition of certain activities

Enforcement Powers

Competent authorities have powers to:

Require access to any document, data, or information
Conduct on-site inspections
Require remediation within a specified timeframe
Suspend or restrict activities
Impose administrative penalties

CTPP Oversight Penalties

For critical ICT third-party service providers:

The Lead Overseer may issue recommendations
Non-compliance with recommendations may lead to periodic penalty payments
Maximum penalty: 1% of average daily worldwide turnover per day, for up to 6 months

DORA Implementation Roadmap

9-Month Plan

Month	Phase	Key Activities
1	Assessment	Map ICT risk landscape, identify applicable DORA requirements, gap analysis against 5 pillars
2	Framework Design	Design ICT risk management framework, define governance structure, establish policies
3	ICT Risk Management	Implement risk identification, protection, detection, and response procedures
4	Incident Management	Deploy incident classification, establish reporting procedures, prepare templates
5	Third-Party Risk	Build ICT third-party register, assess critical providers, update contracts
6	Third-Party Risk (cont.)	Complete contractual updates, develop exit strategies, assess concentration risk
7	Resilience Testing	Design testing program, execute basic tests (vulnerability scanning, gap analysis)
8	Advanced Testing	Conduct penetration testing, scenario-based exercises, TLPT preparation (if applicable)
9	Validation	Internal audit, remediation, management body reporting, continuous improvement setup

Quick Wins (Month 1–2)

Establish ICT risk management governance (management body accountability)
Begin building the ICT third-party register
Review and update incident response procedures for DORA timelines (4h/72h/1mo)
Ensure management body receives regular ICT risk reporting
Verify MFA deployment for critical systems
Document existing BCP/DRP for ICT systems

Infrastructure Checks

ICT Asset Inventory

Maintain a comprehensive register of all ICT assets (hardware, software, network, cloud)
Classify assets by criticality and map to business functions
Include dependencies on ICT third-party providers
Update inventory upon any changes to ICT infrastructure

Network Resilience Testing

Annual network security assessments
Network architecture review and segmentation validation
DDoS resilience testing for public-facing services
Redundant network path verification
Network monitoring and anomaly detection validation

Data Center Redundancy

Active-active or active-passive redundancy for critical systems
Geographic separation of primary and secondary data centers
Automated failover mechanisms tested regularly
Power and cooling redundancy verification
Physical security assessment of data centers

Business Continuity Testing

Annual BCP exercise for all critical business functions
ICT disaster recovery testing covering failover and restoration
Scenario-based testing (cyber incident, natural disaster, provider failure)
Recovery time and recovery point validation against targets
Post-exercise improvement tracking

Disaster Recovery Capabilities

Documented DRP for all critical ICT systems
Backup restoration tested on separate environments
Immutable backup storage for ransomware resilience
Communication plans for disaster scenarios
Coordination procedures with ICT third-party providers

Third-Party Dependency Mapping

Map all ICT third-party providers to business functions
Identify critical dependencies and single points of failure
Assess concentration risk across providers
Document sub-contractor chains for critical services
Verify provider business continuity capabilities

Tools

DORA Readiness Checker

Assesses organizational readiness against all 5 DORA pillars with per-pillar scoring.

# Generate assessment template
python scripts/dora_readiness_checker.py --template > assessment.json

# Run full readiness assessment
python scripts/dora_readiness_checker.py --config assessment.json

# Assess specific pillars only
python scripts/dora_readiness_checker.py --config assessment.json --pillars 1 3 4 --json

# Generate report with JSON output
python scripts/dora_readiness_checker.py --config assessment.json --output readiness_report.json --json

Features:

Assessment against all 5 DORA pillars
Per-pillar readiness scoring (0–100)
Overall readiness score
ICT risk management framework validation
Incident management readiness check
Third-party risk management assessment
Resilience testing program evaluation
Gap analysis with prioritized remediation recommendations

DORA Incident Classifier

Classifies ICT incidents per DORA criteria and determines reporting obligations.

# Classify an incident interactively
python scripts/dora_incident_classifier.py --clients-affected 5000 --duration-hours 4 --data-loss yes --services-critical yes --economic-impact 500000

# Classify from JSON input
python scripts/dora_incident_classifier.py --config incident.json --json

# Generate incident notification template
python scripts/dora_incident_classifier.py --config incident.json --generate-template --output notification.json