DORA Compliance Checklist 2026

The Digital Operational Resilience Act (EU Regulation 2022/2554), known as DORA, has applied directly to EU financial entities since January 17, 2025. Unlike a directive, DORA is a regulation — it does not require national transposition and applies uniformly across all EU member states with immediate legal effect. This places DORA in a different category from NIS2: there is no implementation lag, no national variation in requirements, and no ambiguity about whether your organization is covered. The European Supervisory Authorities (EBA, ESMA, and EIOPA) published their final regulatory technical standards in early 2024, and national competent authorities began formal DORA supervisory activities in Q1 2025.

DORA fundamentally changes how financial entities must approach ICT risk. Where previous EU financial sector rules treated technology risk as a subset of operational risk, DORA elevates digital operational resilience to a standalone regulatory pillar with its own governance requirements, testing obligations, and supervisory regime. For many financial institutions, particularly those outside the largest tier, achieving DORA compliance requires a substantial uplift in ICT governance, third-party oversight, and operational resilience testing capabilities.

This guide covers the five DORA pillars, who must comply, the most commonly identified compliance gaps, and a practical 10-item compliance checklist you can use to assess your organization’s current posture.

1. The Five DORA Pillars

DORA organizes its requirements across five distinct pillars. Each pillar has its own chapter in the Regulation and associated regulatory technical standards (RTS) specifying detailed implementation requirements.

ICT Risk Management in Detail

Pillar 1 is the foundation of the entire DORA framework. It requires entities to maintain a sound, comprehensive, and well-documented ICT risk management framework that is integral to the overall risk management system. The framework must identify all ICT assets and their dependencies, assess risks against the entity’s risk tolerance, implement protection and prevention measures, maintain detection capabilities, and define response and recovery procedures. Critically, the management body is personally responsible for approving the ICT risk management framework and bears ultimate accountability for ICT risk oversight. This mirrors NIS2’s Article 20 provisions and represents a significant shift for boards that have historically delegated technology risk entirely to the CTO or CISO function.

ICT Incident Reporting Timeline

DORA establishes a three-stage incident reporting process for major ICT-related incidents. The classification criteria for “major” incidents are defined in the RTS on incident classification and include thresholds based on number of clients affected, duration of service disruption, geographic spread, and data integrity impact.

2. Who Must Comply with DORA

DORA applies to a broad range of financial entities operating in the EU. The full scope is defined in Article 2(1) of the Regulation and covers both traditional and emerging financial services sectors.

The Simplified Regime

DORA recognizes a proportionality principle, allowing smaller and less complex financial entities to apply a simplified ICT risk management framework under Articles 16 and 17. The simplified regime is specifically available for microenterprises and small non-interconnected investment firms. However, even entities on the simplified regime must maintain basic ICT risk management policies, perform incident detection and response, and apply the third-party risk provisions when using ICT providers that support critical or important functions. The simplified regime is narrower than many organizations assume — it does not eliminate the core DORA obligations.

Third-Country Branches: EU branches of non-EU financial entities are also subject to DORA requirements for their EU operations. The parent entity’s ICT risk management framework may be used if it is equivalent to DORA requirements, but equivalence must be documented and demonstrable to the competent authority.

3. Common DORA Compliance Gaps

Threat-Led Penetration Testing (TLPT)

TLPT is the most technically demanding DORA requirement and the one with the longest lead time to implement. DORA requires significant financial entities to conduct TLPT at least once every three years. Unlike standard penetration testing, TLPT must follow the TIBER-EU framework methodology, be threat intelligence-driven based on entity-specific threat actor profiles, target production systems (not test environments), involve certified testers, and produce remediation plans reviewed by the competent authority. Many organizations underestimate the organizational preparation required: establishing a TLPT governance structure, commissioning threat intelligence, scoping critical functions and systems, and securing board-level authorization for production system testing typically takes 6 to 12 months before testing can begin.

ICT Third-Party Register and Contractual Requirements

DORA requires entities to maintain a register of all ICT third-party providers supporting critical or important functions. Many organizations have informal vendor inventories that are incomplete, outdated, or not formally assessed against DORA’s criteria for criticality classification. Beyond the register, DORA specifies mandatory contractual provisions that must be included in all agreements with ICT providers supporting critical functions: service level descriptions, incident reporting obligations, audit rights, exit provisions, and subcontractor disclosure requirements. A significant proportion of existing vendor contracts predate DORA and lack these provisions, requiring renegotiation or amendment.

Incident Classification Criteria

A major operational gap is the absence of documented, pre-approved incident classification criteria that align with the DORA RTS thresholds. Organizations must be able to classify an incident as “major” and trigger the 4-hour initial notification within the notification window — which means the classification decision process must be automated or pre-delegated, not dependent on an emergency escalation to senior management. Many organizations have generic incident severity classifications (P1/P2/P3) that do not map to DORA’s specific criteria, creating uncertainty during an actual incident about whether and when to notify.

ICT Concentration Risk

Article 29 of DORA requires entities to identify and manage concentration risk arising from dependence on a limited number of ICT third-party providers or providers from a single geographic region. This includes assessing concentration at the individual entity level and, for groups, at the consolidated level. Few financial entities have conducted a formal concentration risk analysis that covers cloud service providers, software vendors, and other critical technology dependencies in the way DORA requires. The European Supervisory Authorities have indicated that concentration risk will be a supervisory priority.

4. DORA Compliance Checklist

Use this 10-item checklist to evaluate your current DORA compliance posture. Each item reflects a mandatory requirement of the Regulation. For each item, your organization should be able to provide documented evidence — not just verbal confirmation — that the requirement is met.

• ICT risk management framework established and board-approved — A comprehensive ICT risk management framework exists, has been formally approved by the management body, is reviewed at least annually, and is integrated into the entity’s overall risk management system.
• Incident classification criteria documented and tested — Written criteria aligned with the DORA RTS incident classification thresholds exist, roles and responsibilities for classification decisions are defined, and the process has been tested through a tabletop exercise or drill.
• Complete ICT third-party register maintained — All ICT providers supporting critical or important functions are inventoried, assessed for criticality, and the register is reviewed and updated at least annually.
• TLPT program established (if significant entity) — A TLPT governance structure is in place, TIBER-EU methodology has been reviewed, and the first TLPT cycle is planned or in progress. Alternatively, completed TLPT results and remediation evidence are documented.
• Business continuity and ICT recovery plans documented and tested — Documented BCP and ICT disaster recovery plans address DORA’s specific requirements for recovery time objectives (RTO) and recovery point objectives (RPO) for critical functions, with evidence of at least annual testing.
• ICT concentration risk analysis completed — A formal concentration risk assessment has been conducted covering cloud providers, critical software vendors, and geographic dependencies, with findings reported to the management body.
• Key contractual provisions in place with ICT providers — All contracts with ICT providers supporting critical functions have been reviewed and updated to include the mandatory DORA contractual provisions: SLAs, incident reporting, audit rights, exit provisions, and subcontractor disclosure.
• Information sharing participation evaluated — The entity has assessed available cyber threat intelligence sharing arrangements and made a documented decision about participation, with rationale communicated to the management body.
• Regulatory reporting procedures tested — The 4-hour initial notification process has been rehearsed, escalation paths are documented, the competent authority’s reporting portal is accessible, and responsible persons are trained on the reporting requirements.
• Management body ICT training completed — Board members and senior executives have received ICT risk and DORA compliance training, attendance is documented, and cybersecurity is a standing agenda item at management body meetings.

Next Steps & Related Resources

Achieving DORA compliance is not a one-time project — it requires ongoing operational resilience capabilities including regular testing, continuous third-party monitoring, and a mature incident notification process. The most effective way to validate that your compliance posture actually works under pressure is through realistic tabletop exercises that simulate ICT incidents requiring regulatory notification decisions. Exercises that rehearse the 4-hour notification window, the incident classification decision process, and management body crisis communication surface procedural gaps that are impossible to identify through documentation review alone. The Skyhigh Cybersecurity platform includes DORA-mapped exercise scenarios for financial entities, covering ransomware, third-party ICT provider outages, and data integrity incidents that require DORA notification decision-making.