DORA Compliance Checklist 2026: Everything EU Financial Entities Must Have in Place

Regulation (EU) 2022/2554 — the Digital Operational Resilience Act — has applied to EU financial entities since 17 January 2025. There are no more transitional periods. Regulators are now actively supervising, registers of information have been collected, and the first wave of Threat-Led Penetration Testing (TLPT) notifications is expected in 2026.

If your compliance programme was built in a hurry before the January 2025 deadline, now is the time to pressure-test it against the actual regulation. This checklist maps every major obligation to its source article so you can identify gaps without guesswork.

---

Who DORA Applies To

DORA applies directly without national transposition to 20 categories of financial entity operating in the EU, including:

• Credit institutions and investment firms
• Insurance and reinsurance undertakings
• Payment institutions and electronic money institutions
• Crypto-asset service providers
• Central counterparties, trading venues, and central securities depositories
• Crowdfunding service providers
• ICT third-party service providers designated as critical (directly regulated under Chapter V)

Microenterprises (fewer than 10 employees, turnover or balance sheet below €2 million) are subject to a simplified framework under Article 16 and are exempt from several of the more prescriptive requirements that apply to larger entities.

---

Pillar 1: Governance and ICT Risk Management Framework

This is the foundation of DORA. Articles 5 through 15 set out what your management body must own, what your ICT risk management framework must contain, and how it must be maintained.

Management Body Responsibilities (Article 5)

• The management body has formally defined, approved, and taken ownership of the ICT risk management framework
• Board members receive regular, specific training on ICT risk commensurate with the risks being managed
• The management body reviews and approves the ICT business continuity policy and response/recovery plans at least annually
• An appropriate budget has been allocated for ICT security, training, and resilience needs
• The management body approves and periodically reviews the ICT internal audit plan
• A digital operational resilience strategy has been approved at board level, including the entity's ICT risk tolerance (Article 6(8))

ICT Risk Management Framework (Article 6)

• A documented ICT risk management framework is in place, reviewed at least annually (or upon major incidents or supervisory instruction)
• A control function is assigned responsibility for ICT risk, with appropriate independence from business functions (three lines of defence model)
• The framework covers all information assets, ICT systems, hardware, software, servers, data centres, and physical infrastructure
• A digital operational resilience strategy is embedded in the framework, including multi-vendor ICT strategy considerations where relevant
• Internal audit of the framework is conducted regularly by auditors with ICT risk expertise
• A formal follow-up process exists for critical ICT audit findings, including remediation timelines

ICT Systems, Protocols and Tools (Article 7)

• ICT systems, protocols, and tools are fit for purpose, reliable, and have sufficient capacity
• Technology refresh cycles are documented and managed to avoid running unsupported or legacy systems
• ICT change management processes include testing before deployment to production

Asset Identification (Article 8)

• A complete inventory of all ICT assets (hardware and software) is maintained and kept up to date
• All business functions supported by ICT assets are mapped and documented
• Critical or important functions (CIFs) are formally identified and classified
• ICT dependencies — between internal systems and with third-party providers — are mapped
• Cyber threats and vulnerabilities are regularly assessed against the asset inventory

Protection and Prevention (Article 9)

• Access controls and authentication policies are implemented and enforced (including privileged access management)
• A documented information security policy is in place
• Patch management and software update procedures are defined and operational
• Network segmentation, encryption, and data integrity controls are implemented
• Automated isolation mechanisms exist to contain compromised components without disrupting operations

Detection (Article 10)

• Anomaly detection and monitoring tools are deployed across critical ICT systems
• User behaviour monitoring is in place with adequate resource and capability
• Alert mechanisms enable prompt detection of ICT incidents and anomalies
• Detection capability is tested regularly

Response and Recovery (Article 11)

• A comprehensive ICT business continuity policy is documented and approved
• ICT response and recovery plans exist and are subject to independent internal audit (for non-microenterprises)
• Business Impact Analysis (BIA) and risk analysis underpin continuity planning
• Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) are defined per critical function, accounting for market efficiency impact
• A crisis management function is in place with clear internal and external communication procedures
• Aggregated annual costs and losses from major ICT incidents can be reported to competent authorities upon request

Backup and Recovery (Article 12)

• Backup solutions are implemented and can be activated without impacting data integrity or security
• Backup systems are logically or physically segregated from primary systems
• Restoration procedures are regularly tested
• RTO and RPO objectives are validated through testing

Learning and Evolving (Article 13)

• Post-incident reviews are conducted after significant ICT incidents
• Threat intelligence capability exists to identify and assess evolving cyber threats
• Lessons learned from incidents feed back into the ICT risk management framework

Communication (Article 14)

• A crisis communication strategy exists for major ICT incidents, including responsible disclosure of vulnerabilities
• Internal communication policies cover staff notification during ICT incidents
• External communication policies cover clients, counterparties, and the public
• At least one individual is designated for public and media communications related to ICT incidents

---

Pillar 2: ICT-Related Incident Management and Reporting

Chapter III (Articles 17–23) governs how incidents are detected, classified, managed, and reported to regulators.

Incident Management Process (Article 17)

• An incident management process is formally defined and operational
• Early warning indicators (EWIs) and thresholds are established for incident detection
• ICT incidents are logged, tracked, and classified according to a documented classification methodology
• Roles and responsibilities for incident response are clearly assigned

Incident Classification (Article 18)

• A classification methodology distinguishes between standard ICT incidents and major ICT incidents using the criteria set out in the RTS on incident classification
• Significant cyber threats are tracked and assessed even where they have not yet materialised into incidents
• Classification decisions are documented and reviewable

Major Incident Reporting (Article 19)

• Initial, intermediate, and final reports on major ICT incidents are submitted to the competent authority within the regulatory timeframes
• The reporting workflow is tested and staff responsible for filing reports are trained
• Voluntary reporting of significant cyber threats is available as a capability (Article 19(2))

Client Notification (Article 19(3))

• Procedures exist to notify affected clients without undue delay when a major ICT incident impacts the financial services provided to them
• Client communication templates are prepared and approved in advance

---

Pillar 3: Digital Operational Resilience Testing

Chapter IV (Articles 24–27) requires all in-scope entities to conduct regular testing, with the most systemically important institutions also required to carry out TLPT.

Basic Digital Operational Resilience Testing (Article 24–25)

• A digital operational resilience testing programme is in place, covering at least annual testing of all critical ICT systems
• Tests include vulnerability assessments, open-source analyses, network security assessments, gap analyses, and — where appropriate — physical security reviews
• Testing is conducted by independent parties (internal or external)
• Test results feed into remediation plans with tracked completion

Threat-Led Penetration Testing — TLPT (Article 26)

TLPT is mandatory only for entities specifically identified by their competent authority. These are typically G-SIIs, O-SIIs, and large payment/e-money institutions above €150 billion in annual transaction volume. Most firms will not be in TLPT scope, but should monitor for notification.

• You have confirmed whether your entity has been or is likely to be identified for TLPT by your national competent authority
• If identified, TLPT is conducted at least every three years on live production systems supporting critical or important functions
• TLPT scope covers all relevant ICT systems, including outsourced and cloud-hosted functions
• An external Threat Intelligence provider develops test scenarios based on current threat intelligence
• A Red Team conducts the simulated attacks (internal testers permitted under Article 26(8), but external testers required every third test significant credit institutions must always use external testers)
• A mandatory purple teaming exercise is conducted in the closure phase (required under DORA, not just encouraged as in TIBER-EU)
• A remediation plan is submitted to the TLPT Authority within eight weeks of the Test Summary Report
• A formal attestation is obtained from the competent authority upon completion

Note: The TLPT RTS (Commission Delegated Regulation (EU) 2025/1190) became applicable on 8 July 2025. The first TLPT notifications for most institutions are expected in 2026, with actual tests likely running from late 2026 into 2027.

---

Pillar 4: ICT Third-Party Risk Management

Chapter V (Articles 28–44) is often the most operationally demanding part of DORA. It governs how financial entities manage their ICT supply chain.

ICT Third-Party Risk Strategy (Article 28)

• A documented ICT third-party risk strategy exists, including guidelines for providers supporting critical or important functions
• Management regularly reviews risks arising from ICT third-party services supporting CIFs
• A risk-based approach is applied when selecting, onboarding, and managing providers

Register of Information / ICT Third-Party Contracts (Article 28)

• A Register of Information on all contractual arrangements with ICT third-party service providers has been compiled and is kept current
• The Register was submitted to the competent authority by the applicable deadline (first submission was due April 2025; deadlines vary by national authority)
• The Register distinguishes between arrangements supporting CIFs and those that do not
• ICT concentration risk is assessed at entity level (Article 29) — including dependency on a single provider for multiple critical functions

Key Contractual Provisions (Article 30)

All contracts with ICT third-party providers supporting critical or important functions must include:

• A clear description of all functions and services to be provided, with their sub-locations and data processing locations
• Provisions on availability, authenticity, integrity, and confidentiality of data
• Full access, inspection, and audit rights for the financial entity, its competent authorities, and resolution authorities
• Data portability and exit assistance obligations on the provider
• Notice periods and reporting requirements where the provider experiences developments that could materially impact service levels
• Cooperation obligations with competent and resolution authorities
• Business continuity provisions, including the provider's assistance with incident resolution (at no or pre-agreed cost under Article 30(2)(f))
• Subcontracting chains are assessed particularly where ICT services supporting CIFs are subcontracted (Article 30(5) RTS on subcontracting)

Pre-Contractual Due Diligence

• A documented due diligence process is applied before entering contracts with providers supporting CIFs
• The financial entity retains full responsibility for DORA compliance even when functions are outsourced

---

Pillar 5: Information Sharing

Article 45 allows but does not mandate, financial entities to participate in information sharing arrangements on cyber threats.

• The entity has considered whether to participate in voluntary cyber threat intelligence sharing arrangements with other financial entities
• If participating, arrangements comply with data protection requirements and do not compromise confidentiality obligations

---

Common Gaps to Address in 2026

Based on how regulators have engaged with financial entities since January 2025, these are the areas most commonly found to be incomplete:

Register of Information quality. Many entities submitted registers in April 2025 that were incomplete or inconsistently structured. The ESAs have indicated they will use the data to identify concentration risks, so the accuracy of provider classification matters. CIF identification. The distinction between functions that are "critical or important" and those that are not has significant downstream consequences for testing scope, contract requirements, and third-party risk management. Many entities have applied this classification too narrowly. Contract renegotiation. Existing contracts with ICT providers often do not include all of the provisions required by Article 30. Renegotiating large enterprise agreements takes time; entities that have not started this process should prioritise it. TLPT readiness. Even entities not yet formally identified for TLPT should be mapping their critical functions, understanding their ICT architecture, and identifying qualified Threat Intelligence and Red Team providers. Receiving a TLPT notification without this groundwork puts the six-month window to scope submission under significant pressure. Board engagement. Article 5 places direct personal responsibility on management body members for ICT risk governance. Regulators have the explicit power to impose administrative penalties on individual board members. Compliance cannot remain a purely operational matter.

---

Using This Checklist

This checklist is structured around the five pillars of DORA and references the relevant articles directly so you can cross-check against the regulation text. For the definitive text of Regulation (EU) 2022/2554, use the EUR-Lex official publication.

If you are building or managing a DORA compliance programme, a structured tool that maps your maturity against each article and tracks who owns what. This will save significant time compared to managing this in a spreadsheet. That is exactly what DORA GRC is built for.

---

This article is for informational purposes. It does not constitute legal advice. Requirements may vary depending on your entity type, size, and national competent authority guidance. Always verify against the current text of Regulation (EU) 2022/2554 and applicable RTS/ITS.