The Digital Operational Resilience Act (EU Regulation 2022/2554 — DORA) has been directly applicable across all EU member states since January 17, 2025. Unlike a directive, DORA requires no national transposition — it is immediately binding on financial entities and their critical ICT third-party service providers. If your organization is a bank, payment institution, investment firm, crypto-asset service provider, insurance undertaking, or a technology firm providing ICT services to any of the above, this DORA compliance checklist covers the obligations you must meet in 2026.
Who Does DORA Apply To?
DORA's scope is exceptionally broad. The regulation applies to over 20 categories of financial entities including credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers, central counterparties, trading venues, insurance and reinsurance undertakings, institutions for occupational retirement provision, and ICT third-party service providers (including cloud providers) designated as critical by the European Supervisory Authorities (ESAs).
A proportionality principle applies: microenterprises (fewer than 10 employees and less than €2M annual turnover) have a simplified compliance regime. However, most financial entities — even mid-sized firms — fall under full DORA obligations.
The Five DORA Pillars: What You Must Do
Pillar 1 — ICT Risk Management
Financial entities must have a comprehensive ICT risk management framework approved by the management body. This framework must include an ICT risk strategy aligned with the overall business strategy, policies covering data classification, patch management, access control, cryptography, network security, and physical security. A business impact analysis (BIA) must identify critical business functions and the ICT assets supporting them. The management body is responsible for the oversight and must receive regular ICT risk reporting.
One critical requirement that many firms overlook: DORA mandates an ICT multi-vendor strategy for critical ICT systems, meaning organizations should not have single-vendor dependencies for systems supporting critical or important functions without documented mitigation plans.
Pillar 2 — ICT-Related Incident Management, Classification, and Reporting
DORA introduces a specific incident taxonomy for financial entities. Not all cybersecurity incidents are reportable — only "major ICT-related incidents" as defined by the Joint Committee of ESAs. Classification criteria include the number of clients affected, the geographical scope, data losses, service unavailability duration, and economic impact.
For major incidents, DORA requires a three-stage notification: an initial notification within 4 hours of classification (no more than 24 hours from the first detection), an intermediate report within 72 hours, and a final report within one month. Significant cyber threats — even those that have not yet materialized into incidents — must be reported on a voluntary basis.
The absence of a DORA-specific incident classification taxonomy is one of the most common gaps identified in compliance assessments. Most organizations have general incident response procedures but lack the specific criteria to distinguish between a regular ICT incident and a "major ICT-related incident" under DORA definitions.
Pillar 3 — Digital Operational Resilience Testing
DORA mandates a testing program covering basic resilience testing (at least annually), including vulnerability assessments and network security testing, and — for significant financial institutions — Threat-Led Penetration Testing (TLPT) at least every three years. TLPT under DORA follows the TIBER-EU framework and requires the use of accredited testing providers, intelligence-led red-team exercises, and formal validation by the competent authority.
BCP testing is also mandatory. Organizations must demonstrate that their business continuity arrangements are tested and that they can recover critical ICT systems within their defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). Untested BCPs are a critical gap — regulators expect evidence of exercises, not just policy documents.
Pillar 4 — ICT Third-Party Risk Management
Third-party ICT risk is a cornerstone of DORA. Financial entities must maintain a comprehensive register of all ICT third-party service providers used to support critical or important functions. For each provider, the entity must conduct due diligence, assess concentration risk (over-reliance on a single provider), and include mandatory contractual provisions covering service level commitments, audit rights, business continuity support, and exit strategies.
Critical ICT third-party service providers (CTPPs) — designated by the ESAs — are subject to direct supervisory oversight by Lead Overseers. Financial entities using CTPPs must ensure these providers comply with DORA oversight requirements and may need to update contracts accordingly.
Pillar 5 — Information Sharing
DORA encourages financial entities to participate in cyber threat intelligence sharing arrangements. While not strictly mandatory, participation in sector-specific Information Sharing and Analysis Centers (ISACs) and EU-level sharing initiatives supports an organization's overall threat landscape awareness and demonstrates proactive compliance engagement.
Check Your DORA Readiness in 5 Minutes
Our free DORA Readiness Assessment scores your organization across all five DORA pillars and identifies your highest-priority gaps.
Take the Free DORA Assessment →Most Common DORA Compliance Gaps
- No DORA-specific incident classification taxonomy: Generic incident severity levels do not map cleanly to DORA's "major ICT-related incident" criteria. Without a formal taxonomy, firms cannot reliably determine when to report to the competent authority.
- ICT third-party register incomplete: Shadow IT and unmanaged cloud services mean many organizations have ICT third-party relationships they have not identified, let alone assessed for DORA compliance.
- BCPs not tested against RTO/RPO targets: Business continuity plans often specify recovery objectives without evidence that they have been validated through functional testing or exercises.
- Management body not formally engaged: DORA places explicit accountability on the management body. Many firms have delegated ICT risk to a CISO without establishing the governance structures that DORA requires at board level.
- TLPT program not established: Significant financial institutions have not begun scoping their TLPT program or identifying accredited test providers.
- Concentration risk not assessed: Financial entities rely heavily on a small number of hyperscale cloud providers for critical functions without formal concentration risk assessments or exit plans.
DORA Compliance Checklist: 10 Key Items
DORA Readiness Checklist 2026
- ICT risk management framework documented and approved by the management body
- ICT asset inventory completed with criticality classification for all assets supporting critical functions
- DORA incident classification taxonomy defined (criteria for "major ICT-related incident" established)
- Incident notification procedures: 4-hour initial, 72-hour intermediate, 1-month final report workflows documented and tested
- BCP tested with documented RTO/RPO validation for all critical ICT systems
- Annual resilience testing program in place (vulnerability assessments, network security testing)
- TLPT scope defined and testing cycle planned (for significant financial institutions)
- ICT third-party register complete with risk tier classification and concentration risk assessment
- DORA-compliant contractual clauses in ICT third-party agreements (audit rights, exit strategy, RTO/RPO commitments)
- Management body trained on DORA responsibilities and ICT risk reporting cadence established
Preparing for DORA Through Tabletop Exercises
DORA's emphasis on operational resilience testing means that organizations cannot rely on policy documentation alone. Tabletop exercises specifically designed for DORA scenarios help validate incident classification procedures, test the 4-hour notification workflow, exercise third-party escalation protocols, and engage the management body in realistic crisis management scenarios.
Exercises that simulate a major ICT disruption at a critical cloud service provider — triggering both DORA incident notification requirements and BCP activation — are particularly valuable. These scenarios expose gaps in escalation procedures, notification timing, and recovery coordination that are invisible until stress-tested.
For financial entities with OT/ICS footprints — such as payment infrastructure operators or energy sector financial participants — exercises should also integrate operational technology failure scenarios, as DORA's operational resilience requirements extend to the full service delivery chain.
Next Steps: Building Your DORA Compliance Program
DORA enforcement is active in 2026. The ESAs have finalized all regulatory technical standards (RTS) and implementing technical standards (ITS), providing clear technical benchmarks for each compliance area. Organizations that have not yet conducted a formal DORA gap assessment should do so immediately, with particular focus on incident classification, the third-party register, and BCP testing evidence.
Engage your management body with a DORA-specific briefing that explains their personal accountability, the regulatory landscape, and the organization's current readiness posture. Boards that understand DORA's requirements are significantly more likely to approve the investments needed for full compliance.