1. ICT risk management (Art. 5–16)
Board-approved framework, ICT asset inventory, identification/protection/detection/response controls, business impact analysis, cyber-resilience strategy reviewed at least annually and after major incidents.
DORA · Regulation (EU) 2022/2554
DORA compliance checklist for financial entities.
A practical, source-cited checklist of 42 controls across the five DORA pillars — ICT risk management, incident management, resilience testing, third-party ICT risk and information sharing. Use it to scope your programme, run a gap assessment and brief your board before the next supervisory dialogue. Applies from 17 January 2025.
- 5 pillars · 42 control points
- Aligned to the RTS/ITS package
- Board-pack templates included
- Ties into AML/CFT and MiCA controls
Definition
What is DORA?
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) is the EU's binding framework for the digital operational resilience of financial entities. It harmonises ICT risk management, incident reporting, resilience testing and third-party ICT oversight across banks, investment firms, insurers, CASPs authorised under MiCA, payment institutions, trading venues and fund managers.
DORA is supplemented by a package of Regulatory and Implementing Technical Standards published by the ESAs (EBA, EIOPA, ESMA) — notably Impl. Reg. (EU) 2024/2956 (register of information), Del. Reg. (EU) 2024/1772 (incident classification) and RTS on TLPT. The framework applies from 17 January 2025.
See our related work on perpetual KYC, enhanced due diligence and the AML glossary.
The five pillars
What DORA actually requires.
2. Incident management (Art. 17–23)
Classification (RTS 2024/1772), 4h/24h/72h/1-month reporting timeline, root-cause analysis, communications playbook, and voluntary reporting of significant cyber threats.
3. Resilience testing (Art. 24–27)
Annual testing programme covering vulnerability assessments, network security, penetration testing, source-code review and — for significant entities — TLPT every 3 years.
4. Third-party ICT risk (Art. 28–44)
Register of information, pre-contractual due diligence, contractual clauses (Art. 30), concentration risk assessment, exit strategy, oversight of CTPPs by the ESAs.
5. Information sharing (Art. 45)
Voluntary participation in cyber-threat intelligence sharing arrangements with other financial entities, subject to GDPR and confidentiality safeguards.
Governance overlay (Art. 5)
Management body owns the ICT risk framework, receives quarterly MI, approves the ICT strategy and third-party policy, and cannot delegate ultimate accountability.
How to prepare
Four steps to a defensible DORA programme.
1. Baseline scoping
Confirm scope (which legal entities, which ICT functions), map critical or important functions per Art. 3(22), and identify DORA-in-scope third parties. Output: scoping memo and function inventory.
2. Gap analysis vs 42 controls
Score current state against the five pillars using the ComplianceSuite DORA control library. Output: heatmap by pillar and severity-ranked gap list.
3. Remediation plan
Owner, cost, target date and evidence type per gap. Board pack template included. Output: remediation roadmap and board-approved plan.
4. Operate and evidence
Register of information kept current, incidents classified against RTS 2024/1772, evidence retained for audit and supervisory review. Output: audit-ready DORA file per year.
The checklist
12 board-level controls to evidence first.
The 12 controls below are the ones supervisors ask about first. The full 42-point checklist is bundled with the ComplianceSuite DORA workspace and mapped to owner, evidence type and refresh cadence.
| Area | Control | Reference |
|---|---|---|
| ICT risk framework | Board-approved ICT risk framework in place and reviewed annually | Art. 6 |
| ICT risk framework | Complete inventory of ICT assets, dependencies and data flows | Art. 8 |
| ICT risk framework | Documented business impact analysis for critical or important functions | Art. 8(6) |
| Incident management | Incident classification procedure aligned to RTS (EU) 2024/1772 | Art. 18 |
| Incident management | 4h / 24h / 72h / 1-month reporting playbook and templates | Art. 19 |
| Incident management | Root-cause analysis retained and shared with the competent authority | Art. 20 |
| Resilience testing | Annual programme covering VA, network security, penetration testing and source-code review | Art. 24–25 |
| Resilience testing | TLPT scoping, provider selection and remediation plan (if significant) | Art. 26–27 |
| Third-party risk | Register of information submitted annually per Impl. Reg. (EU) 2024/2956 | Art. 28(3) |
| Third-party risk | Pre-contractual due diligence and Art. 30 contractual clauses in every ICT contract | Art. 28–30 |
| Third-party risk | Concentration-risk assessment and documented exit strategy per critical function | Art. 29 |
| Governance | Quarterly MI to the management body; RACI documented for ICT risk owners | Art. 5 |
Incident reporting timeline
Major ICT incident: what has to happen when.
| Deadline | Report | Content |
|---|---|---|
| 4h from classification (≤24h from detection) | Initial notification | Entity ID, incident type, criticality classification, functions affected, whether report is mandatory or voluntary. |
| 72h from classification | Intermediate report | Impact update, temporary actions, indicators of compromise, cross-border reach, root-cause hypothesis. |
| 1 month from classification | Final report | Root-cause analysis, permanent remediation, lessons learned, changes to the ICT risk framework. |
Timelines from DORA Art. 19 and Delegated Reg. (EU) 2024/1772. National competent authorities may add local notification channels.
Frequently asked questions.
What is DORA?
The Digital Operational Resilience Act (Regulation EU 2022/2554) is the EU's binding framework for ICT risk management, incident reporting, resilience testing, third-party ICT oversight and information sharing across financial entities. It applies from 17 January 2025 to banks, investment firms, insurers, CASPs, payment institutions, trading venues, fund managers and their critical ICT service providers.
Who does DORA apply to?
20 categories of financial entities including credit institutions, payment and e-money institutions, investment firms, CASPs authorised under MiCA, insurance and reinsurance undertakings, UCITS/AIF managers, CCPs, CSDs, trading venues, credit-rating agencies, and their critical third-party ICT service providers (CTPPs) — including cloud, data-centre and SaaS providers designated by the ESAs.
What are the five DORA pillars?
1) ICT risk management framework (Art. 5–16); 2) ICT-related incident management, classification and reporting (Art. 17–23); 3) Digital operational resilience testing including TLPT (Art. 24–27); 4) Managing ICT third-party risk including the register of information and CTPP oversight (Art. 28–44); 5) Information and intelligence sharing on cyber threats (Art. 45).
When is the DORA incident reporting deadline?
Major ICT-related incidents must be reported to the competent authority: initial notification within 4 hours of classification and no later than 24 hours from detection, intermediate report within 72 hours, and final report within 1 month. Significant cyber threats may be reported voluntarily. Classification thresholds are set in RTS Reg. (EU) 2024/1772.
What is TLPT and when is it required?
Threat-Led Penetration Testing is the DORA-mandated red-team exercise on live production systems, based on TIBER-EU. Required at least every 3 years for entities designated as significant by their national competent authority — typically the largest banks, systemically important CASPs, CCPs and major insurers. Scope, providers and remediation follow RTS Reg. (EU) 2025/1190.
What is the DORA register of information?
A structured inventory of every contractual arrangement with an ICT third-party service provider, using the templates in Implementing Reg. (EU) 2024/2956. It must be submitted annually to the competent authority (first submission was April 2025) and cover function criticality, sub-outsourcing chains, data location, exit strategies and substitutability assessments.
How does DORA relate to MiCA, NIS2 and the EU AI Act?
For CASPs, DORA sits alongside MiCA (Art. 68 explicitly cross-refers) as the operational-resilience layer. NIS2 continues to apply for non-financial critical entities; DORA is lex specialis for financial entities. The EU AI Act adds obligations on high-risk AI systems but does not replace DORA's ICT risk framework.
How does ComplianceSuite help with DORA?
We cover the compliance-adjacent DORA obligations — ICT third-party register maintenance, incident classification workflows, evidence retention for audits, board reporting and MI, and integration with the AML/CFT control framework so DORA controls are testable alongside financial-crime controls in the same audit-ready system.
Turn the checklist into a defensible programme.
We'll walk your team through the 42 controls, benchmark against peer institutions and hand back a prioritised remediation plan — usually in one workshop.
Related solutions