CyphrQ
Menu

DORA Requirements for Financial Entities: Five Pillars Explained

What DORA requires of EU financial entities since 17 January 2025: five pillars, the 4-hour and 24-hour incident clock and ICT provider oversight.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

10 min read

What does DORA require of financial entities? DORA, the EU's Digital Operational Resilience Act, requires banks, insurers, investment firms and other regulated financial entities to manage ICT risk, report major ICT incidents to their supervisor, test their resilience, control their technology suppliers and share threat information. It has applied since 17 January 2025.

This is not legal advice. It is a plain-language reading by CyphrQ.ai, not by a lawyer, with links so you and your legal adviser can check it. Your supervisor's own guidance and the national rules that apply to you come first.

What is DORA?

DORA is Regulation (EU) 2022/2554 (EUR-Lex). A regulation, unlike a directive, applies directly in every Member State without national transposition. That is a real difference from the NIS2 Directive, where your duties come from a national law.

The ESAs, the three European Supervisory Authorities for banking, securities and insurance (EBA, ESMA and EIOPA), said in a statement of 4 December 2024 that DORA provides no transitional period, so firms had to be ready on 17 January 2025 (ESAs statement JC 2024 99). The EBA describes DORA as setting up an EU-wide oversight framework for critical ICT third-party providers, with the ESAs as Lead Overseers (EBA).

"ICT" here means information and communication technology: the systems, networks, software, data and cloud services a firm runs its business on.

Who does DORA apply to?

To financial entities in the EU, and to the ICT providers they depend on. Article 2 of the Regulation lists 20 types of financial entity, points (a) to (t), among them credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, insurers and pension funds. Point (u) adds ICT third-party service providers. Some small firms get a lighter regime, and the Regulation scales its rules to size and risk (the proportionality principle).

What this means in practice:

  • If you are a regulated financial entity: you carry the duties directly.
  • If you sell technology to one: you are not usually covered yourself, but your customer must manage you as a third-party risk. Expect contract changes, questionnaires and evidence requests.
  • If the ESAs designate you as a critical provider: you face direct EU oversight. More on that below.

How DORA sits next to NIS2: where DORA applies to a financial firm, it is the more specific rule for ICT risk management and incident reporting. The detail is in NIS2 requirements: who is in scope.

What are the five pillars of DORA?

The ESAs' public pages describe DORA through five areas. Each one is a block of requirements, not a single control:

Pillar What it asks of a financial entity
1. ICT risk management A documented framework that identifies, protects, detects, responds and recovers, owned by the management body
2. ICT incident management and reporting Classify incidents, report major ones to the supervisor in stages, and tell affected clients
3. Digital operational resilience testing A testing programme, with advanced threat-led testing for some firms
4. ICT third-party risk A register of every ICT contract, contract terms, exit plans, and oversight of critical providers
5. Information sharing Voluntary exchange of cyber threat information between firms

Two points are easy to miss. First, accountability sits with the management body, meaning the board, not the IT department. Second, pillar 4 reaches furthest, because it covers every ICT supplier, not just the big cloud names.

How does DORA incident reporting work?

A financial entity classifies each ICT-related incident and, if it is "major", reports it to its competent authority in stages. The EBA's page on the major-incident reporting standards gives the limits as an initial notification "4 hours after classification and 24 hours after detection of the incident", an intermediate report at 72 hours, and a final report at one month (EBA).

Step Time limit as summarised by the EBA
Initial notification 4 hours after classification as major, and 24 hours after detection
Intermediate report 72 hours
Final report 1 month

Read the first row carefully. Two clocks run. The 4 hours start when you classify the incident as major. The 24 hours start when you detect it. So a slow classification decision does not buy you time past the 24-hour mark.

The same EBA page lists the package as adopted, published in the Official Journal under CELEX 32025R0301, and in force. The EBA's page uses the word "proposed" for the limits and says they are aligned with NIS2, so confirm the final wording of the Delegated Regulation before you build a procedure around it. The start points for the intermediate and final reports are where summaries disagree, so take them from the legal text.

Article 19 of DORA sets the staged structure itself. In the Regulation's text on EUR-Lex, entities submit an initial notification, an intermediate report when the status changes significantly, and a final report once the root cause analysis is complete and actual impact figures replace estimates.

What does DORA require for third-party ICT providers?

Financial entities stay fully responsible for their own compliance when they outsource. The Regulation answers that with two layers:

  1. Every firm manages its own suppliers. It keeps a register of information on all contractual arrangements with ICT providers, writes minimum terms into contracts, and plans how it would exit from a provider.
  2. The EU oversees the critical providers. The ESAs can designate an ICT provider as critical and then oversee it directly.

In practice, that second layer is already live. On 18 November 2025 the three ESAs published their first list of designated critical ICT third-party providers (ESMA news). The page says the ESAs will use direct oversight to check whether designated providers have adequate risk management and governance. The list is a separate PDF (List of designated CTPPs); I could not extract its text, so I do not name providers here.

Designation does not take your own duties away. If your supplier is on the list, you still hold the register entry, the contract terms and the exit plan.

What is the DORA register of information?

It is the structured inventory of a firm's ICT contracts, in a template the ESAs standardised. The legal basis is Article 28(3) of DORA, and the templates come from an Implementing Technical Standard, identified in the EBA's reporting FAQ as Commission Implementing Regulation (EU) 2024/2956 (EBA ITS page). The register also feeds the ESAs' choice of which providers to designate as critical, which is why a sloppy register matters beyond your own audit.

A DORA readiness checklist for financial entities

  1. Confirm you are a financial entity under Article 2 and write down which type, and which supervisor.
  2. Name a management-body owner for ICT risk, and put it on the board agenda.
  3. Build the register of information: every ICT contract, which function it supports, and the subcontractors you know of.
  4. Mark which functions are critical or important, and check those suppliers first.
  5. Write the incident classification test and the reporting path, with a named decision-maker and a deputy.
  6. Run a drill that starts the clock at detection and measure when you could file an initial notification.
  7. Put an exit plan on file for every critical provider, and say who tests it.
  8. Align this with your business continuity management system. ISO 22301 explained covers the standard many firms use for that.

Going deeper: for security and IT teams

This section assumes you know the basics and have the Regulation and technical standards open. The legal texts rank above any summary here, including this one.

Know your instruments. DORA (Regulation (EU) 2022/2554) sets the duties. The detail lives in technical standards the ESAs wrote and the Commission adopted. The EBA's DORA page links the ones that matter here: the RTS on incident classification, the joint technical standards on major-incident reporting, the ITS on register-of-information templates, the joint RTS on threat-led penetration tests, the RTS on the ICT risk management framework, and the joint RTS on oversight conditions (EBA DORA page). Treat those as your control baseline.

Register of information. Build it as a data model, not a spreadsheet. The ESAs' FAQ says the registers are reported in plain CSV according to the ESAs' specification, and that the same format was used in a 2024 dry run (EBA FAQ on register reporting). The ESAs' timeline set 30 April 2025 as the date by which competent authorities report the registers to the ESAs (ESAs timeline). Decide per supplier which company identifier you hold, such as a Legal Entity Identifier (LEI), and record it consistently. Typical failures are missing subcontractor chains, no link between a contract and the business function it supports, and stale entries after renewals.

Major-incident classification. Classification drives the clock, so automate the inputs. The Regulation's classification criteria cover things like the number and share of clients affected, duration, geographical spread, data losses, the criticality of the services hit and the economic impact, and the RTS sets thresholds (EBA classification RTS page). Feed these from evidence you already have: identity provider sign-in logs, EDR alerts, service monitoring, and customer-impact counts from your support system. Record the timestamp of detection and the timestamp of classification as separate fields in the ticket. They start different clocks.

Threat-led penetration testing (TLPT). DORA adds advanced testing, based on real threat intelligence, for entities the authorities identify. Article 26 requires those entities, other than microenterprises and firms under the simplified framework, to run TLPT at least every 3 years, and the supervisor can raise or lower that frequency. Frequency, scope and who may test are set in the Regulation and the joint RTS on TLPT (EBA TLPT RTS page). Check with your supervisor whether you are in the TLPT population. If you are, plan for scoping that covers live production systems that support critical functions, including those your providers run for you. Pooled testing with a provider is something to raise early, because your provider's willingness is a dependency.

Exit plans and contracts. Article 28 expects an exit strategy for ICT services that support critical or important functions, and Article 30 lists minimum contract terms. Write exit plans as testable runbooks: trigger conditions (provider failure, supervisory order, termination), a data-return format, a target alternative provider or an in-house fallback, and a realistic recovery time. Then run a tabletop and keep the output as audit evidence. A plan nobody has exercised is a document, not a capability.

Detection and evidence. What an examiner will ask for is dated proof: board minutes approving the ICT risk framework, the register and its change history, incident tickets with detection and classification timestamps, filed notifications, test reports and remediation tracking.

Questions for your vendors and your supervisor.

  • Is our function classed as critical or important, and does that change the contract terms we need?
  • Which of our providers use subcontractors that support that function, and can we see them?
  • How quickly will you tell us about an incident that touches our data, and is that faster than our own 24-hour limit?
  • Which national authority receives our reports, in which channel and format?
  • Are we expected to run TLPT, and who decides the scope?

Learn more

Key takeaways

  • DORA, Regulation (EU) 2022/2554, has applied directly to EU financial entities since 17 January 2025, with no transitional period according to the ESAs.
  • It has five pillars: ICT risk management, incident management and reporting, resilience testing, third-party risk, and information sharing.
  • The EBA summarises the incident clock as an initial notification 4 hours after classification and 24 hours after detection, an intermediate report at 72 hours and a final report at one month. Check the start points in the legal text.
  • Firms keep a register of information on all ICT contracts. The ESAs published their first list of critical ICT providers on 18 November 2025, and your own duties remain even when a supplier is on it.
  • Start with scope, a board owner, the register, a timed incident drill and tested exit plans.

Sources