DORA Compliance Expert

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

Table of Contents

• 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:

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

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:

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)

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:

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:

1. Scoping phase: Identify critical functions and supporting ICT infrastructure
2. Threat intelligence phase: Gather threat intelligence specific to the entity's sector and geography
3. Red team phase: Execute realistic attack scenarios against production systems
4. Closure phase: Report findings, remediation planning
5. 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:

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

Quick Wins (Month 1–2)

1. Establish ICT risk management governance (management body accountability)
2. Begin building the ICT third-party register
3. Review and update incident response procedures for DORA timelines (4h/72h/1mo)
4. Ensure management body receives regular ICT risk reporting
5. Verify MFA deployment for critical systems
6. 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

Features:

• Incident classification per Article 18 criteria
• Major incident determination
• Reporting deadline calculation (4h initial, 72h intermediate, 1 month final)
• Incident notification template generation
• Severity scoring and impact assessment

Reference Guides

DORA Five Pillars Guide

Complete implementation guidance for all 5 DORA pillars with ISO 27001 control mapping, financial-sector-specific requirements, and RTS/ITS references.

DORA Third-Party Management Guide

ICT third-party register template, contractual requirements checklist, exit strategy framework, concentration risk assessment methodology, and critical provider oversight.

Troubleshooting

Success Criteria

• Overall readiness score of 75+ across all 5 pillars -- indicating the organization can demonstrate compliance with core DORA requirements to competent authorities
• ICT risk management framework formally approved by the management body -- with documented digital operational resilience strategy, risk tolerance levels, and annual review cycle
• Incident classification and reporting procedures operational -- with capability to submit initial notification within 4 hours of major incident classification and intermediate report within 72 hours
• Complete ICT third-party register maintained -- covering all contractual arrangements, distinguishing critical/important functions, with entity identification, service details, and sub-contractor chains
• Resilience testing program covers all 12 required test types -- with annual penetration testing, scenario-based exercises, and TLPT preparation (if applicable) per Articles 24-27
• Exit strategies documented and tested for all critical ICT providers -- with comprehensive transition arrangements, alternative provider identification, and data recovery procedures
• Annual ICT security awareness training delivered to all staff -- with records maintained and specialized training for ICT and security personnel per Article 13

Scope & Limitations

In Scope:

• Readiness assessment against all 5 DORA pillars with per-pillar scoring
• ICT incident classification per Article 18 criteria with major incident determination
• Reporting deadline calculation (4-hour initial, 72-hour intermediate, 1-month final)
• Incident notification template generation for competent authority submissions
• Third-party risk management guidance including register template and contractual requirements
• Resilience testing program design covering basic and advanced (TLPT) testing
• Gap analysis with prioritized remediation recommendations

Out of Scope:

• Actual penetration testing execution or vulnerability scanning -- this skill provides planning and assessment frameworks, not testing tools
• Direct interaction with competent authorities or ESAs (EBA, ESMA, EIOPA)
• Legal determination of entity scope (whether your organization falls under DORA's 20 entity types) -- consult regulatory counsel
• CTPP (Critical Third-Party Provider) oversight framework compliance -- applicable only to ESA-designated providers
• Real-time ICT monitoring or SIEM implementation -- use infrastructure-compliance-auditor for technical security controls

Important Notes:

• DORA became applicable January 17, 2025; regulators are treating 2025 as a transition year but enforcement is expected to intensify in 2026
• Non-compliance penalties can reach up to 2% of total annual worldwide turnover or 1% of average daily global turnover for up to 6 months (for CTPPs)

Integration Points

Tool Reference

dora_readiness_checker.py

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

Output: Overall readiness score (0-100), per-pillar readiness scores, ICT risk management framework validation, incident management readiness, third-party risk assessment, resilience testing evaluation, and prioritized remediation recommendations.

dora_incident_classifier.py

Classifies ICT incidents per DORA Article 18 criteria and determines reporting obligations.

Output: Incident severity scoring per Article 18 criteria, major incident determination, reporting deadline calculation (initial 4h, intermediate 72h, final 1 month), and notification template generation.

Last Updated: March 2026 Regulation Reference: EU 2022/2554 Applicable From: January 17, 2025