Dora Compliance Expert

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 is a directly applicable EU regulation (applicable since January 17, 2025) covering 20 types of financial entities and their critical ICT third-party providers. This skill assesses readiness against the five pillars, classifies ICT incidents and computes reporting deadlines, and structures third-party risk and resilience-testing programs.

Core Capabilities

• 5-pillar readiness assessment — score ICT risk management, incident management, resilience testing, third-party risk, and information sharing (0–100 per pillar) with gap analysis and prioritized remediation
• Incident classification & reporting — classify ICT incidents per Article 18 criteria, determine major-incident status, and compute the 4h / 72h / 1-month reporting deadlines
• Third-party ICT risk — register structure, Article 30 contractual provisions, exit strategies, and concentration-risk assessment
• Resilience testing program design — basic testing (12 test types) plus advanced Threat-Led Penetration Testing (TLPT) per the TIBER-EU framework

When to Use

• Running a DORA gap assessment or readiness scorecard for a financial entity
• Classifying an ICT incident and confirming reporting obligations to a competent authority
• Building or auditing an ICT third-party register and contracts
• Designing a digital operational resilience testing program (basic + TLPT)
• Determining whether and how DORA applies to your entity

Quick Start

# Generate and run a 5-pillar readiness assessment
python scripts/dora_readiness_checker.py --template > assessment.json
python scripts/dora_readiness_checker.py --config assessment.json --json

# Classify an ICT incident and get reporting deadlines
python scripts/dora_incident_classifier.py --clients-affected 5000 --duration-hours 4 \
  --data-loss yes --services-critical yes --economic-impact 500000

References

Load the reference that matches the task — keep this file lean and pull detail on demand:

• [references/framework-overview.md](references/framework-overview.md) — DORA background, legal nature, relationship to NIS2/GDPR/PSD2/MiCA/ISO 27001, the 20 in-scope entity types, proportionality, CTPP designation, and the penalty/enforcement regime. Read when scoping applicability or assessing enforcement exposure.
• [references/five-pillars-detail.md](references/five-pillars-detail.md) — article-by-article requirements for all 5 pillars (Articles 5–45), incident classification & reporting deadlines, testing/TLPT, and third-party contractual provisions. Read when assessing a specific pillar or mapping a requirement to its article.
• [references/dora-five-pillars-guide.md](references/dora-five-pillars-guide.md) — complete implementation guidance for all 5 pillars with ISO 27001 control mapping, financial-sector-specific requirements, and RTS/ITS references. Read when implementing controls aligned to ISO 27001.
• [references/dora-third-party-management.md](references/dora-third-party-management.md) — ICT third-party register template, contractual requirements checklist, exit strategy framework, concentration-risk methodology, and critical-provider oversight. Read when building the register or reviewing contracts.
• [references/implementation-and-infrastructure.md](references/implementation-and-infrastructure.md) — 9-month implementation roadmap, quick wins, infrastructure verification checklists, troubleshooting table, and success criteria. Read when planning the program or diagnosing assessment results.
• [references/tools-and-cli.md](references/tools-and-cli.md) — full command examples, feature lists, and flag-by-flag reference for both Python scripts. Read when running or scripting the tools.

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

---

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

DORA Five Pillars — Implementation Guide

Complete implementation guidance for all 5 pillars of the Digital Operational Resilience Act (EU 2022/2554), with ISO 27001 control mapping, financial-sector-specific requirements, and RTS/ITS references.

---

Table of Contents

• Pillar 1: ICT Risk Management
• Pillar 2: ICT-Related Incident Management
• Pillar 3: Digital Operational Resilience Testing
• Pillar 4: ICT Third-Party Risk Management
• Pillar 5: Information Sharing
• ISO 27001 Control Mapping
• RTS/ITS References

---

Pillar 1: ICT Risk Management

Articles 5–16 Implementation

Governance Framework (Article 5)

Implementation steps:

1. Management body accountability

• Document management body responsibilities for ICT risk in the entity's governance framework
• Include ICT risk management as a standing agenda item in board/management meetings
• Ensure the management body defines and approves the ICT risk tolerance level
• Allocate dedicated budget for ICT risk management (separate line item)

2. Organizational structure

• Appoint a Chief Information Security Officer (CISO) or equivalent with direct reporting line to management body
• Establish an ICT risk management function (second line of defense)
• Ensure separation between ICT risk management, ICT operations/control, and internal audit
• Define RACI matrix for all ICT-related functions

3. Digital operational resilience strategy (Article 6(8))

The strategy must include:

• Explanation of how ICT risk management supports the business strategy
• ICT risk tolerance level and key information security objectives
• Description of the ICT reference architecture and changes needed
• Mechanisms for detecting and responding to ICT anomalies
• ICT third-party risk strategy
• Digital operational resilience testing approach
• Communication strategy for ICT incident disclosure

Financial sector specificity: The strategy must consider the entity's interconnectedness with the broader financial system, systemic importance, and potential cascading effects.

ICT Systems and Tools (Article 7)

• Deploy systems, protocols, and tools that are adequate in design and updated
• Invest in ICT capacity proportionate to business needs and risk profile
• Implement reliability, capacity, and business continuity as design principles
• Document all ICT systems supporting critical or important functions

Identification (Article 8)

• Identify and classify all ICT-supported business functions, roles, and assets
• Map interdependencies among ICT assets and between entity and third-party providers
• Maintain updated network topology and data flow documentation
• Identify assets and services supporting critical/important functions
• Perform ICT risk assessments annually and after significant changes

Financial sector specificity: Financial entities must specifically map dependencies relevant to financial stability, payment systems, and settlement processes.

Protection and Prevention (Article 9)

Key requirements:

• Continuous monitoring and control of ICT system security
• Network connection resilience (redundant paths, failover)
• MFA for access to critical systems (Article 9(4))
• Strong authentication mechanisms
• ICT change management with security review
• Software patching policies with defined timelines
• Least privilege access control

Financial sector specificity: Payment systems, trading platforms, and settlement systems require enhanced protection measures due to real-time availability requirements and financial impact of disruption.

Detection (Article 10)

• Multiple layers of detection controls
• Automated alerting mechanisms
• Sufficient resources and capabilities for monitoring trading activities
• Detection mechanisms that enable multi-stage attack identification
• Log collection from all critical systems with adequate retention

Response and Recovery (Articles 11–12)

• ICT business continuity policy covering all critical functions
• Response and recovery plans tested annually
• Backup policies with:
• Defined scope, frequency, and retention
• Restoration on separate, independent systems
• Integrity verification after restoration
• Redundant ICT capacities with adequate resources

Financial sector specificity: Recovery objectives must consider market hours, settlement cycles, and regulatory reporting deadlines. Payment systems may require near-zero RPO.

Learning and Evolving (Article 13)

• Mandatory post-incident reviews for all significant incidents
• Vulnerability and threat intelligence gathering
• Annual ICT security awareness training for all staff (mandatory)
• ICT security awareness programs for non-ICT personnel
• Implementation of findings from testing and post-incident analysis

Communication (Article 14)

• Crisis communication plans for both internal and external stakeholders
• At least one designated spokesperson for external crisis communication
• Responsible disclosure policies for ICT-related incidents
• Coordination with competent authorities during incidents

---

Pillar 2: ICT-Related Incident Management

Articles 17–23 Implementation

Building the Incident Management Process (Article 17)

Step 1: Detection and identification

• Deploy early warning indicators across all critical systems
• SIEM integration with financial-sector-specific use cases
• Automated correlation of events from multiple sources
• Integration with threat intelligence feeds relevant to financial sector

Step 2: Classification (Article 18)

Classify every incident using all six criteria:

Step 3: Major incident determination

An incident is major when it meets thresholds defined in the RTS on incident classification criteria (delegated to ESAs). Key indicators:

• Significant number of clients unable to access financial services
• Extended duration affecting critical functions
• Cross-border impact affecting financial stability
• Loss or compromise of financially sensitive data
• Substantial economic impact (direct and indirect)

Step 4: Reporting timeline

Detection → Classification → Initial (4h) → Intermediate (72h) → Final (1 month)
     |            |                |                |                    |
   ASAP      ASAP after       4h from          72h from            1 month from
            detection      classification    initial report     intermediate report
                          (max 24h from
                           detection)

Step 5: Client notification

• Determine if clients' financial interests are affected
• Notify without undue delay using appropriate channels
• Include description of incident, impact, and remedial measures

Reporting Templates

Initial notification content:

• Entity identification (name, LEI, entity type)
• Incident reference and classification date/time
• Brief description
• Affected services and functions
• Initial impact assessment
• Suspected cause (malicious/non-malicious)

Intermediate report content:

• Updated severity and impact assessment
• Root cause assessment (if determined)
• Recovery status and timeline
• Indicators of compromise
• Additional measures implemented

Final report content:

• Complete timeline
• Detailed root cause analysis
• Full impact assessment (financial, operational, data, reputational)
• Mitigation measures applied and ongoing
• Lessons learned and improvement actions

---

Pillar 3: Digital Operational Resilience Testing

Articles 24–27 Implementation

Testing Program Design

Program structure:

Basic Testing Requirements (Article 25)

All financial entities must perform:

1. Vulnerability assessments and scans

• External vulnerability scanning at least weekly
• Internal scanning at least monthly
• Web application scanning for all public-facing applications
• Remediation tracking with defined SLAs

2. Network security assessments

• Architecture review and segmentation validation
• Firewall rule review and optimization
• Network traffic analysis for anomalies
• Wireless network security assessment

3. Gap analyses

• Compare current controls against DORA requirements
• Map to RTS/ITS technical standards
• Identify and prioritize remediation actions

4. Scenario-based tests

• Cyber attack scenarios (ransomware, APT, DDoS)
• Third-party provider failure scenarios
• Multi-event scenarios (cascading failures)
• Crisis communication exercises
• Include management body participation in major scenarios

5. Penetration testing

• External network penetration testing
• Web application penetration testing
• Internal network penetration testing
• Social engineering testing (phishing, vishing)
• Mobile application testing (if applicable)

6. Source code reviews

• SAST integrated into CI/CD pipelines
• Manual security code review for critical changes
• Open-source dependency analysis (SCA)
• License compliance checking for OSS

TLPT — Threat-Led Penetration Testing (Article 26)

Applicability: Only entities designated by competent authorities based on systemic importance and risk profile.

TLPT process based on TIBER-EU:

Phase 1: Scoping (4-6 weeks)
├── Identify critical/important functions
├── Map supporting ICT infrastructure
├── Define scope boundaries with competent authority
└── Management body approval

Phase 2: Threat Intelligence (4-6 weeks)
├── Sector-specific threat landscape analysis
├── Entity-specific threat assessment
├── Attack scenario development
└── TTP (Tactics, Techniques, Procedures) selection

Phase 3: Red Team Testing (8-12 weeks)
├── Execute realistic attack scenarios
├── Target production systems (live environment)
├── Multiple attack vectors
├── Document all activities and findings
└── Maintain strict operational security

Phase 4: Closure (4-6 weeks)
├── Red team debrief and reporting
├── Blue team review (detection and response assessment)
├── Purple team exercises (collaborative analysis)
├── Remediation plan development
├── Management body presentation
└── Summary report to competent authority

Purple teaming requirements:

• Red team shares TTPs, tools, and attack paths
• Blue team assesses detection coverage for each TTP
• Joint gap identification for detection and response
• Collaborative improvement recommendations
• Documentation of purple team findings and remediation

Key TLPT rules:

• Must be conducted by qualified external testers
• Internal testers may participate under specific conditions
• Tests must cover live production systems
• Results must be validated by the competent authority
• Remediation of findings is mandatory
• Summary must be shared with the competent authority

---

Pillar 4: ICT Third-Party Risk Management

Articles 28–44 Implementation

Lifecycle Management

Assessment → Contracting → Onboarding → Monitoring → Review → Exit/Renewal
     |            |            |            |           |          |
  Due diligence  DORA-compliant  Security    Ongoing    Annual    Exit
  Risk assessment  provisions   integration  SLA/security review  strategy
  Concentration   Article 30    verification monitoring          execution
  risk check

Pre-Engagement Assessment

Due diligence checklist:

• [ ] Provider financial stability assessment
• [ ] Provider security certifications (ISO 27001, SOC 2, etc.)
• [ ] Provider business continuity capabilities
• [ ] Geographic location of data processing and storage
• [ ] Sub-contractor chain transparency
• [ ] Regulatory compliance status
• [ ] Conflict of interest evaluation
• [ ] Concentration risk assessment
• [ ] Substitutability analysis
• [ ] Reference checks from other financial entity clients

Contract Management

Mandatory contractual provisions (Article 30):

For all ICT service arrangements: 1. Clear and complete service descriptions with SLAs 2. Data processing locations (including sub-processing) 3. Data availability, authenticity, integrity, and confidentiality measures 4. Quantitative and qualitative performance targets 5. Provider assistance obligations during ICT incidents 6. Cooperation requirements with competent and resolution authorities 7. Termination rights (including for performance failure and regulatory change) 8. Transition and exit provisions 9. TLPT participation requirements 10. Full audit and access rights (including on-site inspections) 11. Unrestricted right to monitor performance

For critical or important functions (Article 30(3), additional): 12. Detailed service level descriptions 13. Notice periods and reporting for material developments 14. Full access to performance and security data 15. Mandatory BCP testing by provider 16. ICT security awareness training for provider staff 17. Provider participation in entity's security testing

Ongoing Monitoring

• Track SLA compliance continuously
• Monitor provider security posture (certifications, incidents, vulnerabilities)
• Review sub-contractor changes
• Assess provider financial health annually
• Verify data processing location compliance
• Monitor regulatory changes affecting the arrangement

Exit Strategy Framework

For critical/important function arrangements:

1. Trigger conditions

• Provider material breach of contract
• Provider insolvency or financial instability
• Regulatory requirement to exit
• Concentration risk exceeding tolerance
• Provider designated as CTPP with restrictions

2. Transition planning

• Identify alternative providers or insourcing options
• Define data migration procedures
• Document system integration requirements
• Establish transition timeline (typically 6-18 months)
• Test transition procedures before they are needed

3. Data management

• Data extraction and portability requirements
• Data format and structure specifications
• Secure deletion verification from outgoing provider
• Continuity of data integrity during migration

---

Pillar 5: Information Sharing

Article 45 Implementation

Setting Up Sharing Arrangements

1. Identify relevant sharing communities

• Financial sector ISACs (e.g., FS-ISAC, European FI-ISAC)
• National CERT/CSIRT communities
• Sector-specific threat intelligence sharing groups
• Vendor-operated threat intelligence platforms

2. Establish governance

• Define what can be shared (IoCs, TTPs, strategic intelligence)
• Establish data handling procedures (TLP protocol)
• Ensure GDPR compliance for any personal data in threat data
• Protect business confidentiality and competition-sensitive information

3. Operationalize

• Integrate threat intelligence feeds into SIEM/SOC
• Establish processes to analyze and act on received intelligence
• Contribute back to the community with sanitized threat data
• Report participation to competent authority

---

ISO 27001 Control Mapping

Complete DORA to ISO 27001:2022 Mapping

Gap Analysis for ISO 27001 Certified Organizations

Organizations with ISO 27001 certification typically have 50-65% of DORA requirements covered. Key gaps:

1. DORA-specific governance requirements — Management body must directly approve and oversee ICT risk management (not just delegate) 2. Incident reporting timelines — 4-hour initial notification is significantly more aggressive than ISO 27001 requirements 3. TLPT — No equivalent in ISO 27001; requires threat intelligence-based red teaming against production systems 4. ICT third-party register — DORA requires a structured register of all ICT arrangements with specific fields 5. Concentration risk — Explicit requirement to assess and manage ICT provider concentration 6. Exit strategies — Mandatory documented and tested exit strategies for critical function outsourcing 7. Financial sector specificity — Recovery objectives tied to market hours, settlement cycles, and financial stability considerations

---

RTS/ITS References

Key Regulatory Technical Standards

Note: Consult the EBA, ESMA, and EIOPA websites for the latest versions of all RTS/ITS, as technical standards continue to be refined through the regulatory process.

---

Last Updated: March 2026 Regulation Reference: EU 2022/2554

DORA Third-Party Management Guide

Comprehensive guidance for managing ICT third-party risk under DORA (EU 2022/2554), including the ICT third-party register, contractual requirements, exit strategies, concentration risk assessment, and critical provider oversight.

---

Table of Contents

• ICT Third-Party Register
• Contractual Requirements Checklist
• Exit Strategy Framework
• Concentration Risk Assessment
• Critical Provider Oversight

---

ICT Third-Party Register

Overview

Article 28(3) of DORA requires financial entities to maintain a register of information relating to all contractual arrangements on the use of ICT services provided by ICT third-party service providers. This register must be available to competent authorities upon request.

Register Structure

The register must distinguish between arrangements that cover critical or important functions and those that do not.

Register Template

Section A: Entity Information

Section B: Arrangement Details (Per Third-Party Provider)

Register Maintenance

• Update frequency: Upon any change to arrangements, and at minimum quarterly
• Review cycle: Annual comprehensive review
• Reporting: Available to competent authority upon request
• Format: Structured data format as specified by ESA ITS

---

Contractual Requirements Checklist

All ICT Service Arrangements (Article 30(2))

Critical or Important Function Arrangements (Article 30(3), Additional)

Audit and Access Rights

Sub-Contracting Requirements

---

Exit Strategy Framework

When Exit Strategies Are Required

Exit strategies are mandatory for all arrangements covering critical or important functions (Article 28(8)).

Exit Strategy Components

1. Trigger Conditions

Define clear conditions that trigger exit strategy activation:

2. Transition Planning

3. Data Management During Exit

• Data extraction: Define formats, methods, and timelines for data extraction from provider
• Data migration: Procedures for secure data transfer to alternative provider or in-house
• Data validation: Integrity verification of all migrated data
• Data deletion: Verifiable deletion of all entity data from outgoing provider
• Continuity: Ensure no data loss or service disruption during transition

4. Service Continuity During Transition

• Define minimum service levels during transition period
• Establish parallel-run requirements before cutover
• Plan for fallback if migration encounters issues
• Maintain provider cooperation requirements during transition

5. Testing Exit Strategies

Exit strategies must be tested to ensure they work:

---

Concentration Risk Assessment

Overview

Article 29 requires financial entities to assess and manage risks arising from concentrating ICT services with a limited number of providers.

Assessment Methodology

Step 1: Map ICT Service Dependencies

For each ICT third-party provider, document:

• All services provided
• Business functions supported
• Data volumes and sensitivity
• Number of entity staff dependent on the service
• Availability requirements

Step 2: Identify Concentration Indicators

Step 3: Concentration Risk Scoring

Step 4: Mitigation Strategies

Step 5: Reporting

• Include concentration risk assessment in the ICT risk management framework
• Report concentration risk to management body at least annually
• Update assessment when entering new ICT arrangements or upon material changes
• Report to competent authority upon request

Concentration Risk Register

---

Critical Provider Oversight

Overview

Articles 31–44 establish an Oversight Framework for critical ICT third-party service providers (CTPPs). This framework is unique to DORA and has no equivalent in other cybersecurity regulations.

Designation Process

The ESAs designate CTPPs based on:

Lead Overseer

One of the three ESAs (EBA, ESMA, EIOPA) is assigned as Lead Overseer for each designated CTPP based on the types of financial entities primarily using the provider.

Oversight Powers

The Lead Overseer may:

Financial Entity Obligations Regarding CTPPs

If your ICT provider is designated as a CTPP:

1. Verify compliance — Confirm that your provider is cooperating with the Lead Overseer 2. Review contracts — Ensure contracts contain all DORA-mandated provisions, including cooperation with authorities 3. Monitor oversight outcomes — Track any recommendations issued to your CTPP by the Lead Overseer 4. Assess impact — Evaluate whether oversight actions affect the services you receive 5. Exit readiness — Maintain tested exit strategies in case oversight actions require transition 6. Report — Report material developments in the CTPP relationship to your competent authority

Non-EU ICT Third-Party Providers

CTPPs established in third countries (non-EU) must:

• Establish a subsidiary within the Union within 12 months of designation
• The subsidiary is subject to the full oversight framework
• Failure to establish may result in the Lead Overseer recommending that financial entities suspend or terminate arrangements

---

Last Updated: March 2026 Regulation Reference: EU 2022/2554, Articles 28-44

DORA Five Pillars — Article-by-Article Detail

Per-pillar requirements with the governing DORA articles, incident classification and reporting deadlines, testing obligations (including TLPT), third-party contractual provisions, and information-sharing rules. Read this when assessing a specific pillar or mapping a requirement to its article.

---

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.

DORA Framework Overview, Scope & Enforcement

Background on the regulation, its scope across financial entities and CTPPs, and the penalty regime. Read this when establishing whether DORA applies, how it relates to other frameworks, or what enforcement exposure looks like.

---

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

---

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, Infrastructure Checks & Troubleshooting

The 9-month implementation plan, quick wins, infrastructure verification checklists, the troubleshooting table for the assessment tools, and the success criteria. Read this when planning a DORA program, validating technical resilience controls, or diagnosing unexpected assessment results.

---

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

---

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

DORA Tools — Usage & CLI Reference

Full command examples, feature lists, and flag-by-flag reference for the two Python scripts (dora_readiness_checker.py, dora_incident_classifier.py). Read this when running an assessment, classifying an incident, or scripting the tools into automation.

---

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

---

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.