DORA
DORA — Regulation (EU) 2022/2554
The digital operational resilience obligations that have applied to European financial entities since January 2025: an ICT risk framework reviewed yearly, major incidents reported within four hours, and a register of ICT providers.
- Who it applies to
- The financial entities listed in Article 2: credit, payment and electronic money institutions, investment firms, fund managers, insurance and reinsurance undertakings, crypto-asset service providers, central securities depositories, central counterparties, trading venues and credit rating agencies, among others. It also reaches the ICT third-party service providers that serve them, with a dedicated oversight regime for those designated critical.
- Deadline
- Applicable since 17 January 2025, with no transitional period. The recurring internal deadlines are annual: review of the ICT risk management framework, review of asset classification, testing of continuity plans, and reporting on the register of information. Threat-led penetration testing, at least every three years for identified entities.
- Official reference
- Regulation (EU) 2022/2554 of 14 December 2022
DORA is not a security regulation, it is a continuity regulation
Regulation (EU) 2022/2554 has applied since 17 January 2025 and came with no transitional period. It helps to understand its logic before mapping controls: DORA is not primarily worried about you being attacked, it is worried about you stopping service. That is why the unit of analysis is the critical or important function rather than the asset, and why most obligations end up pointing at the same question: if this function goes down, how long until it is back, and who has verified that?
The difference explains two things that surprise people arriving from ISO 27001. First, testing is neither optional nor annual-if-we-get-round-to-it: continuity plans are tested at least once a year and the result matters more than the existence of the plan. Second, the provider sits squarely inside the regulated perimeter.
Five blocks and one common thread
The regulation is organised into ICT risk management (Articles 5 to 16), incident management and reporting (17 to 23), resilience testing (24 to 27), ICT third-party risk (28 to 44) and information sharing (45). The common thread is documentary: nearly every obligation resolves into a dated document, a named owner and a periodic review.
Article 16 sets out a simplified framework for certain small and non-interconnected entities, and microenterprises are carved out of several specific requirements. Before sizing the effort, check which bucket your entity falls into, because the difference in workload is substantial.
Where it usually goes wrong
Two points account for most of the trouble. The first is the four-hour clock. It does not run from the moment you know something is wrong, but from the moment you classify the incident as major under the criteria in Commission Delegated Regulation (EU) 2024/1772 — and that instant has to be recorded with a time and an author. When classification is decided in a meeting with no minutes, the deadline becomes indefensible. If the deadline falls on a weekend or a national bank holiday, submission may be deferred to noon of the next working day, except for the entity types the delegated regulation excludes from that flexibility.
The second is the register of information. It is not a contract inventory: it is a fixed-structure template with legal entity identifiers and a subcontracting chain you must be able to reconstruct. Entities that assembled it by hand in a spreadsheet in year one found the annual update costs more than the initial load.
What the supervisor looks at first
Based on the first supervisory cycles, the usual order is: board minutes approving the framework, the date of the last annual review, the third-party register of information, and the file for the most recent major incident reported. If those four are dated and consistent with each other, the rest of the review proceeds on solid ground.
Obligations
-
The management body bears ultimate responsibility for ICT risk
Article 5(2) does not allow delegation: the management body defines, approves, oversees and is accountable for every element of the ICT risk management framework. Specifically it approves the digital operational resilience strategy and the ICT risk tolerance level, the business continuity policy and the response and recovery plans, the ICT internal audit plans, the resilience budget, and the policy on the use of ICT services from third parties. Article 5(4) adds that its members must keep their knowledge current through regular training.
Evidence required
Dated board minutes for each of those approvals, identifying the version approved, together with the specific resilience budget line and a named training record for the directors.
-
An ICT risk management framework, documented and reviewed at least yearly
Article 6(5) requires the framework to be documented and reviewed at least once a year, and additionally on the occurrence of major ICT-related incidents, following supervisory instructions, and following conclusions from resilience testing or audit processes. The review report goes to the competent authority on request. Article 6(4) requires separation between ICT risk management, control functions and internal audit under the three lines of defence model.
Evidence required
The framework document under version control with a change history, the dated annual review report, and the approval minutes. If there was a major incident during the year, the post-incident review, dated visibly after the incident was closed.
-
Inventory and classify ICT functions and assets, reviewed every year
Article 8(1) requires identifying, classifying and documenting all ICT-supported business functions, roles and responsibilities, the information and ICT assets supporting them and their dependencies, and reviewing the adequacy of that classification at least yearly. Article 8(2) adds an annual review of risk scenarios, and Article 8(7) a specific assessment, at least yearly, of all legacy ICT systems.
Evidence required
A dated export of the inventory showing the last review date per asset, the dependency map between assets and functions, and the minutes or signature approving the annual review. An inventory with no review date is, to a supervisor, an inventory that was never reviewed.
-
Report a major incident within four hours of classifying it
Article 19 creates the obligation; Commission Delegated Regulation (EU) 2025/301 sets the clock. The initial notification goes out as early as possible and in any case within four hours of classifying the incident as major, and no later than 24 hours from the moment the entity became aware of it. If classification happens after those 24 hours, four hours from classification still applies. The intermediate report is due at the latest 72 hours after the initial notification, even if nothing has changed, and is updated when regular activities are recovered. The final report is due no later than one month after the latest intermediate report.
Evidence required
A time-stamped supervisory acknowledgement for each milestone and, above all, the record of the exact moment of classification as major, who decided it and on what criterion. That single entry is what holds up or collapses the four-hour count.
-
A resilience testing programme and an annual test of continuity plans
Article 24 requires entities other than microenterprises to maintain a digital operational resilience testing programme, executed by independent parties — internal or external — with documented management of conflicts of interest. Article 25 lists the expected repertoire: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, source code reviews where feasible, scenario-based tests and penetration testing. Article 11(6) adds testing of business continuity and response and recovery plans at least yearly.
Evidence required
Test reports signed by the executing team, with scope, start and end dates and a statement of independence; and the minutes of the annual continuity exercise with scenario, participants, measured timings and assigned improvement actions.
-
Threat-led penetration testing at least every three years
Article 26(1) requires entities identified by the competent authority to carry out TLPT at least every three years, on live production systems and covering several or all of their critical or important functions. The entity proposes the scope and the supervisor validates it. Where ICT providers fall within scope, the entity must secure their participation and retains full responsibility for compliance.
Evidence required
Supervisory validation of the scope, the exercise report, the attestation issued on completion, and the remediation plan for the findings with committed dates and closure evidence.
-
Maintain the register of information on ICT third-party arrangements and report it yearly
Article 28(3) requires maintaining and updating, at entity level and where relevant at sub-consolidated and consolidated level, a register of information on all contractual arrangements for the use of ICT services, distinguishing those supporting critical or important functions from those that do not. At least yearly, the entity must report to the competent authority on the number of new arrangements, the categories of providers, the types of contract and the services and functions provided. It must also give timely notice of any planned arrangement covering a critical or important function, and when a function becomes critical or important.
Evidence required
The register in the official template with a stated cut-off date, proof of the annual submission to the authority, and the trail of pre-signature notifications for contracts supporting critical functions.
-
Pre-contractual assessment, minimum clauses and an exit strategy before signing
Article 28(4) requires, before entering into a contract, assessing whether it covers a critical or important function, checking that supervisory conditions for contracting are met, identifying all relevant risks — including the concentration risk in Article 29 — and performing due diligence. Article 28(8) requires exit strategies for ICT services supporting critical or important functions, and Article 30 lists the minimum contractual provisions, including the access, inspection and audit rights in Article 28(6).
Evidence required
The due diligence file dated before the contract, the signed contract with a map locating each Article 30 provision, and the exit plan with milestones, owners and the result of the last reversibility test.