DORA — Digital Operational Resilience Act Skill

How to Respond

DORA Structure at a Glance

Regulation (EU) 2022/2554 — Published: OJ L 333, 27 December 2022 Application date: 17 January 2025 (Art. 64)

In-Scope Financial Entities (Art. 2)

DORA applies to a broad range of financial entities including:

• Credit institutions (banks)
• Payment institutions, e-money institutions
• Investment firms
• Crypto-asset service providers (CASPs) under MiCA
• Central securities depositories (CSDs), CCPs, trading venues
• Insurance and reinsurance undertakings
• UCITS management companies, AIFMs
• Data reporting service providers
• Crowdfunding service providers

Proportionality (Art. 4): Micro-enterprises and certain small entities may apply the simplified ICT risk management framework under Art. 16. The criteria are set in CDR (EU) 2024/1774, Chapter II. Entities eligible for the simplified framework include (indicative — confirm against CDR 2024/1774):

• Micro-enterprises as defined in EU law (fewer than 10 staff; ≤ €2M turnover/assets)
• Small and non-interconnected investment firms
• Payment institutions and e-money institutions below certain thresholds
• Certain occupational pension funds and small insurance intermediaries

If unsure whether the simplified framework applies: Default to the full Chapter II framework (Art. 6–14). Applying the simplified framework without confirming eligibility is itself a compliance risk.

Chapter II — ICT Risk Management Framework (Art. 5–16)

The ICT RMF is the core ongoing governance obligation. Key articles:

Art. 5 — Governance and Organisation

• Management body (board) bears ultimate responsibility for ICT risk (Art. 5(1))
• Must define ICT risk appetite and strategy (Art. 5(2)(a))
• Must approve the ICT security policies (Art. 5(2)(b))
• Must ensure adequate ICT budget and training (Art. 5(2)(d)–(e))
• Must ensure a crisis communication plan (Art. 5(2)(g))

Common gap: Board is not formally approving ICT risk appetite or ICT security policy — these remain purely IT/CISO-owned documents.

Art. 6 — ICT Risk Management Framework

• Maintain a comprehensive, documented ICT RMF (Art. 6(1))
• Implement strategies, policies, procedures, protocols, and tools (Art. 6(2))
• Review after major incidents and at least annually (Art. 6(5))
• Document and review the ICT risk management function (Art. 6(4))

Key RTS: CDR (EU) 2024/1774 specifies detailed RMF elements

Art. 7 — ICT Systems, Protocols and Tools

• Maintain ICT systems that meet current standards (Art. 7(a))
• Ensure resilience and availability (Art. 7(b))
• Maintain adequate capacity (Art. 7(c))
• Apply security patches promptly (Art. 7(d))

Art. 8 — Identification

• Identify and classify all ICT assets supporting critical/important functions (Art. 8(1))
• Maintain an ICT asset register (Art. 8(4))
• Map interdependencies and single points of failure (Art. 8(4))

Common gap: No maintained, current ICT asset register; no mapping of assets to business functions.

Art. 9 — Protection and Prevention

• Implement physical and logical access controls (Art. 9(2))
• Apply network segmentation and encryption (Art. 9(2)(b)–(c))
• Implement policies to manage ICT third-party access (Art. 9(2)(d))
• Establish change management procedures (Art. 9(4)(b))
• Patch and vulnerability management (Art. 9(4)(c))

Art. 10 — Detection

• Deploy monitoring tools to detect anomalous activities (Art. 10(1))
• Enable alerts for ICT incidents (Art. 10(1))
• Implement multiple layers of control (Art. 10(2))

Art. 11 — Response and Recovery

• Implement a documented ICT business continuity policy (Art. 11(1))
• Business impact analysis (BIA) for critical functions (Art. 11(2))
• ICT recovery time objectives (RTO) and recovery point objectives (RPO) (Art. 11(2))
• Test continuity plans at least annually (Art. 11(6))
• Maintain crisis communication procedures (Art. 11(1)(c))

Art. 12 — Backup Policies and Procedures

• Implement backup policies specifying scope, frequency, and storage (Art. 12(1))
• Ensure backups are stored separately from primary systems (Art. 12(2))
• Test restorability of backups (Art. 12(3))

Common gap: Backup restore tests are not documented; backup storage is co-located with primary systems.

Art. 13 — Learning and Evolving

• Perform post-incident reviews after major ICT incidents (Art. 13(1))
• Conduct threat intelligence monitoring (Art. 13(3))
• Provide ICT security training and digital operational resilience training (Art. 13(6))
• Track cyber threats and vulnerabilities (Art. 13(2))

Art. 14 — Communication

• Establish crisis communication plans for major ICT incidents (Art. 14(1))
• Define internal escalation and external communication procedures (Art. 14(2))

Art. 15 — Further Harmonisation of ICT Risk Management Tools

ESAs may develop guidelines to further specify Art. 6–14 elements.

Art. 16 — Simplified ICT Risk Management Framework

Smaller, less complex entities may apply a simplified framework. Eligible entities and requirements are specified in CDR (EU) 2024/1774, Chapter II.

Chapter III — Incident Management, Classification and Reporting (Art. 17–23)

Art. 17 — ICT-Related Incident Management Process

• Establish and implement a documented incident management process (Art. 17(1))
• Define roles, responsibilities, escalation paths (Art. 17(1)(a))
• Set thresholds for classifying incidents as major (Art. 17(1)(b))
• Ensure senior management awareness for major incidents (Art. 17(3))
• Report major incidents to the board (Art. 17(3))

Art. 18 — Classification of ICT-Related Incidents

Financial entities classify ICT incidents and cyber threats using these criteria:

Classification criteria (Art. 18(1)):

• (a) Number of clients/counterparts affected and value of transactions
• (b) Reputational impact
• (c) Duration and geographic spread
• (d) Data losses — availability, authenticity, integrity, confidentiality
• (e) Criticality of the services affected
• (f) Economic impact

Materiality thresholds are set in CDR (EU) 2024/1772 (RTS on classification). An incident is major if it meets or exceeds any threshold.

For voluntary reporting of significant cyber threats: Art. 19(2).

Art. 19 — Reporting of Major ICT-Related Incidents

Three-stage reporting to the competent authority:

Key RTS: CDR (EU) 2025/301 (content and time limits) Key ITS: CIR (EU) 2025/302 (standard forms and templates)

For payment-related incidents: see Art. 23.

Art. 20 — Harmonisation of Reporting Content, Timelines and Templates

Obligation for ESAs to develop harmonised RTS/ITS — fulfilled by CDR (EU) 2025/301 and CIR (EU) 2025/302.

Art. 21 — Centralisation of Reporting of Major ICT-Related Incidents

ESAs to assess feasibility of a single EU reporting hub. Supervisors forward reports to other relevant authorities where appropriate.

Art. 22 — Supervisory Feedback

Competent authorities may provide feedback to financial entities after incident report receipt, including indicative impact assessments, relevant cyber threat intelligence, and preventive measures.

Art. 23 — Specific Rules on Reporting of Payment-Related Major Incidents

Applies to payment-specific entities (credit institutions, payment institutions, e-money institutions). Integrates with EBA payment security reporting and PSD2 Article 96 legacy obligations where applicable.

Chapter IV — Digital Operational Resilience Testing (Art. 24–27)

Art. 24 — General Requirements for Digital Operational Resilience Testing

• All financial entities must conduct a basic digital operational resilience testing programme including vulnerability assessments, gap analyses, and network security assessments (Art. 24(1))
• Tests must be conducted by independent internal or external parties (Art. 24(4))
• Tests must be performed at least once a year for critical ICT systems (Art. 24(1))

Art. 25 — Testing of ICT Tools and Systems

Covers baseline testing types:

• Vulnerability assessments and scans
• Source code reviews (where applicable)
• Scenario-based testing and compatibility tests
• Performance tests and end-to-end tests

Art. 26 — Advanced Testing Based on TLPT

Threat-Led Penetration Testing (TLPT) is required for significant financial entities meeting the criteria in Art. 26(8):

• TLPT must be conducted every 3 years (Art. 26(1))
• Must cover live production systems (Art. 26(2))
• Scope includes critical/important functions and underlying ICT systems (Art. 26(3))
• ICT TPSPs supporting critical functions may be in scope with consent (Art. 26(3))
• Must use threat intelligence to develop TLPT scenarios (Art. 26(4))
• Must be performed by qualified external testers with no conflict of interest (Art. 26(6))
• Competent authority may require TLPT on specific systems (Art. 26(7))

Key RTS: CDR (EU) 2025/1190 (TLPT requirements and testers)

TIBER-EU: The TLPT framework is aligned with TIBER-EU. Many EU Member State central banks already operate TIBER-EU programmes. TLPT under DORA Art. 26 builds on but formally supersedes informal TIBER frameworks for in-scope entities.

Art. 27 — Requirements for Testers

• External testers must demonstrate capability, integrity, and risk methodology (Art. 27(1))
• Must hold relevant professional certifications (Art. 27(2))
• Cannot have conflicts of interest with the tested entity (Art. 27(3))
• Competent authority maintains list of qualified testers (Art. 27(4))

Chapter V — ICT Third-Party Risk Management (Art. 28–44)

This chapter imposes the most complex obligations and is divided into two sections.

Section I — Key Principles and General Requirements (Art. 28–30)

Art. 28 — General Principles for Managing ICT Third-Party Risk

• Adopt and regularly review an ICT third-party risk policy (Art. 28(1))
• Maintain and update the Register of Information on all ICT service arrangements (Art. 28(3))
• Assess ICT concentration risk — single TPSPs supporting multiple critical functions (Art. 28(6))
• Conduct exit strategy planning for critical arrangements (Art. 28(7))
• Pre-contractual due diligence for all ICT service arrangements (Art. 28(4))

Key ITS: CIR (EU) 2024/2956 — templates and mandatory fields for the Register of Information (RoI)

Key RTS: CDR (EU) 2024/1773 — detailed ICT third-party risk policy requirements

Art. 29 — Preliminary Assessment of ICT Concentration Risk at Entity Level

• Assess risk of concentrating ICT services in one TPSP (Art. 29(1))
• Assess risk that entire ICT services are or could become unavailable (Art. 29(2))
• Perform assessment before entering new arrangements for critical functions (Art. 29(3))

Art. 30 — Key Contractual Provisions

Contracts with ICT TPSPs supporting critical or important functions must include:

• Art. 30(2)(a): Clear description of ICT services
• Art. 30(2)(b): Locations where services are provided and data processed
• Art. 30(2)(c): Data protection provisions
• Art. 30(2)(d): Accessibility, availability, integrity, security provisions
• Art. 30(2)(e): Audit and access rights for the entity, competent authority, and resolution authority
• Art. 30(2)(f): Termination rights and minimum exit notice periods
• Art. 30(2)(g): Reporting and monitoring obligations
• Art. 30(2)(h): Data portability and migration assistance on termination
• Art. 30(2)(i): Sub-contracting arrangements — prior consent and notification

For non-critical arrangements: a lighter set of provisions applies (Art. 30(3)).

Key RTS: CDR (EU) 2024/1773 (detailed contractual provisions) Key RTS: CDR (EU) 2025/532 (subcontracting of ICT services)

For detailed contractual provisions guidance, see references/third-party-risk.md.

Section II — Oversight Framework for Critical ICT Third-Party Service Providers (Art. 31–44)

Art. 31 — Designation of Critical ICT Third-Party Service Providers

ESAs designate ICT TPSPs as critical (CTPPs) based on criteria in CDR (EU) 2024/1502:

• Systemic impact if the TPSP were to fail or discontinue services
• Number and type of financial entities served
• Degree of substitutability
• Interdependence and interconnectedness

Art. 32 — Structure of the Oversight Framework

• Lead Overseer (EBA, ESMA, or EIOPA depending on CTPSP's predominant services) is designated for each CTPSP
• Joint Oversight Network (JON) coordinates across ESAs
• Joint Examination Teams (JETs) conduct on-site and off-site examinations per CDR (EU) 2025/420

Art. 33–38 — Lead Overseer Powers

• Require information and documentation (Art. 33)
• Conduct general investigations (Art. 34)
• Conduct on-site inspections (Art. 35)
• Issue recommendations (Art. 36)
• Issue follow-up recommendations for non-compliance (Art. 37)
• Fees: CDR (EU) 2024/1505

Art. 39–44 — Additional Oversight Provisions

• Oversight activities harmonisation: CDR (EU) 2025/295 (RTS on Art. 41)
• Information exchange between authorities (Art. 40)
• Protection of confidential information (Art. 41)

Chapter VI — Information-Sharing Arrangements (Art. 45)

Financial entities may participate in voluntary cyber threat intelligence sharing arrangements with other financial entities. Requirements:

• Must protect confidential and personal data (Art. 45(1))
• Must not violate competition rules (Art. 45(1))
• ESAs may develop guidelines on cyber threat information sharing (Art. 45(3))

Gap Analysis — DORA Compliance Assessment

Phase 1: Governance and Risk Framework (Chapter II)

Phase 2: Incident Management (Chapter III)

Phase 3: Resilience Testing (Chapter IV)

Phase 4: Third-Party Risk (Chapter V)

Register of Information — Key Fields (CIR (EU) 2024/2956)

The Register of Information is the central inventory of all ICT service arrangements. It is submitted annually (or on demand) to the competent authority.

Mandatory fields include:

For the complete field set and template, see references/third-party-risk.md.

TLPT — Threat-Led Penetration Testing

Applies to: Financial entities meeting criteria in Art. 26(8), as further specified in CDR (EU) 2025/1190.

Indicative criteria triggering TLPT (Art. 26(8)):

• Size and overall risk profile of the entity
• Scale and complexity of ICT systems
• Relevance to financial stability

TLPT process (Art. 26 + CDR (EU) 2025/1190):

1. Scope definition — Identify critical functions and underlying ICT systems
2. Threat intelligence phase — Commission threat intelligence report from qualified provider on relevant threat actors and TTPs
3. Red team test — External red team performs adversarial simulation against live production systems
4. Remediation — Entity remediates findings
5. Competent authority notification — Before and after TLPT
6. Attestation letter — Issued by competent authority upon satisfactory completion
7. Mutual recognition — Results recognized across EU jurisdictions for entities operating cross-border

Frequency: At least once every 3 years (Art. 26(1)).

Common DORA Compliance Errors

Reference Files

• references/rts-its-guide.md — All 12 adopted RTS/ITS: regulation numbers, article mapping, and key requirements
• references/article-reference.md — All 64 DORA articles with obligation summaries and key sub-paragraph citations
• references/third-party-risk.md — Deep-dive on Art. 28–44, Register of Information fields, contractual provisions, and ICT concentration risk
• references/incident-classification.md — Art. 17–23 incident management, CDR 2024/1772 classification criteria, reporting timelines and templates