What DORA Is and Since When It Applies
DORA is the EU regulation on digital operational resilience for the financial sector. Unlike a directive, which must first be transposed into national law, a regulation applies directly in all member states — without a national implementing act and, in principle, with the same wording everywhere. DORA was adopted at the end of 2022 and, after a two-year preparation phase, has been applicable since 17 January 2025 (Regulation (EU) 2022/2554). Its aim is to consolidate the previously fragmented requirements for IT security and resilience in finance into a single, binding framework.
The three European Supervisory Authorities (ESAs) — the European Banking Authority (EBA), the European Securities and Markets Authority (ESMA) and the European Insurance and Occupational Pensions Authority (EIOPA) — developed the detailed technical rules as regulatory and implementing technical standards (RTS and ITS) (ESAs). Ongoing supervision of individual financial entities sits with the competent national authorities, while critical ICT third-party providers are overseen directly at EU level (Regulation (EU) 2022/2554).
For the entities in scope, the direct start of application means preparation should already be complete. The two-year gap between entry into force and application was the actual implementation phase — since January 2025 it is the current state that counts. DORA consolidates previously scattered requirements, for example on outsourcing, IT security and incident reporting, and raises them to a single, auditable level (Regulation (EU) 2022/2554). Anyone setting up their processes, contracts and evidence only now is therefore no longer working toward a future deadline but closing a gap that is already open.
DORA applies directly and, unlike the NIS2 Directive, did not need to be transposed into national law first. For entities in scope of both DORA and NIS2, DORA acts as the sector-specific special rule (lex specialis) for the financial sector's ICT requirements (Regulation (EU) 2022/2554).
Who Falls Within Scope
DORA's scope is one of the broadest in EU financial law. Article 2 lists 21 categories of financial entity (Regulation (EU) 2022/2554); in total, more than 22,000 financial entities across the EU fall within scope (PwC). It captures not only the large, systemically important institutions but also many smaller and specialised players — from payment institutions to crypto-asset service providers.
Banks and credit institutions of every size, from large banks to regional institutions.
Payment service providers, e-money institutions and account information services.
Investment firms, fund managers and operators of trading venues.
Insurance and reinsurance undertakings as well as insurance intermediaries.
Crypto-asset service providers and issuers of asset-referenced tokens under MiCAR.
ICT providers designated as critical are overseen directly at EU level by the ESAs.
Beyond the financial entities themselves, DORA explicitly addresses their ICT third-party providers. Through the entities' contractual requirements, security and resilience duties are passed down the supply chain. In addition, individual providers can be designated critical ICT third-party providers (CTPPs) and are then subject to direct, EU-wide oversight by the ESAs (Regulation (EU) 2022/2554).
Anyone supplying financial entities with web, API or hosting services will have DORA requirements passed down contractually — for example on availability, reporting paths and evidence. This mirrors the supply-chain logic that also underpins monitoring script integrity and client-side security under PCI DSS 4.0.1.
The Five Pillars of DORA
DORA organises its resilience requirements into five themed pillars. They interlock: without end-to-end risk management there is no robust incident handling, and without incident handling there is no timely reporting (Regulation (EU) 2022/2554).
A comprehensive framework of strategies, policies, procedures and tools to identify, protect and monitor ICT risks — owned by the management body.
A process to detect and classify ICT incidents and report the major ones to the competent authority on time.
Regular testing of digital operational resilience, up to threat-led penetration testing (TLPT) for certain institutions.
Governing and monitoring outsourcing to ICT providers, including a complete register of information.
Voluntary exchange of intelligence on cyber threats and vulnerabilities between financial entities.
In practice, the web and API layer relates most closely to the first, second and fourth pillars: continuous monitoring of availability and integrity feeds ICT risk management, timestamped detection feeds incident handling, and monitoring of outsourced services feeds third-party risk. For a structured view of the underlying security fundamentals, the OWASP Top 10 2025 web risks offer useful orientation.
The ICT Incident Deadlines: 4 h, 72 h, 1 Month
The operational core of DORA is the staggered reporting of major ICT-related incidents. Whether an incident counts as major follows criteria the ESAs set out in the technical standards — including the number of clients affected, the duration and geographical spread of the disruption, data losses, economic impact and the criticality of the services affected (ESAs). Only when an incident meets that threshold and is classified as major do the actual reporting deadlines begin to run.
- Initial notification — as early as possible, in any case within 4 hours of classification as major and no later than 24 hours after becoming aware of the incident (ESAs, RTS on ICT incident reporting).
- Intermediate report — at the latest 72 hours after the initial notification, with an updated status; a further update follows once regular activities recover (ESAs).
- Final report — no later than one month after the (latest updated) intermediate report, with a root-cause analysis, impact and the measures taken (ESAs).
A limited deadline extension over weekends and public holidays does not apply to all institutions equally; it is not available to credit institutions, central counterparties, trading-venue operators and entities classified as essential or important under NIS2 (ESAs). In practice this means the tight 4-hour deadline is the rule rather than the exception for many addressees.
The 4-hour deadline runs from classification — which can only happen once the incident has actually been noticed. If an outage or manipulation is discovered by chance only hours later, classification shifts accordingly and the remaining response time shrinks. The earlier and more precisely the moment of detection is timestamped, the more realistic an orderly, on-time report becomes.
In addition to the mandatory reporting of major incidents, financial entities may voluntarily notify significant cyber threats. Where clients are affected by an incident, they must also be informed without undue delay (Regulation (EU) 2022/2554). The reporting chain therefore does not end with the supervisor but includes outward communication.
The Register of Information for ICT Third Parties
A standalone duty is the Register of Information (RoI). Every financial entity must keep a complete record of all contractual arrangements with ICT third-party providers — at entity, sub-consolidated and consolidated level. Competent authorities were required to submit this register to the ESAs for the first time by 30 April 2025 (EBA). The register is therefore not mere documentation but an active supervisory tool to reveal concentration risks in the supply chain.
The voluntary dry run at the end of 2024 showed how demanding the data quality is: around 1,000 financial entities took part, of which 1,039 submitted their registers under realistic conditions (EBA/ESAs). Many participants found that capturing contracts, provider identifiers and function chains completely and accurately takes more effort than first assumed.
On 18 November 2025, the ESAs published the first list of designated critical ICT third-party providers — 19 providers, including several large cloud and platform providers, have since been under direct EU oversight (EBA/ESMA/EIOPA). For financial entities, this underlines how strongly their own resilience depends on the availability of outsourced services.
Why the Web and API Layer Becomes Resilience Evidence
DORA is a broad governance framework — but at its operational core it is about the availability and integrity of services. That is exactly where disruptions first surface, at the public web and API layer: an unreachable customer portal, a slow or failing payment API, an expired certificate, a manipulated page. Continuous, automated monitoring turns the abstract resilience duty into measurable, timestamped evidence.
Multi-region checks detect outages in minutes and document start and end with a timestamp — the basis of uptime monitoring.
Payment and customer-data interfaces are checked against assertions and thresholds, as described in API monitoring.
Expiring or revoked certificates and changes to DNS records are reported early, before they turn into a disruption.
Visual and content deviations are checked against a baseline — the basis of screenshot and defacement monitoring.
Security-relevant HTTP headers and common weakness patterns are checked regularly via the security scan.
Every relevant state change is logged with a timestamp — the low-gap, low-tamper chronicle for the reporting chain.
An honest caveat matters here: web monitoring is an operational building block, not a replacement for the entire ICT risk framework. It provides the time-precise detection and the evidence for the availability and integrity layer — the legal assessment of whether an incident is major under DORA is made case by case by those responsible, ideally with expert and legal support.
From Monitoring to a Provable Reporting Chain
The real compliance value lies in the chain: event, detection, classification, initial notification, intermediate report, final report. Continuous monitoring detects the status change itself, stamps it with a time and alerts the contact point. This log — when a disruption began, when it was detected, when it was resolved — feeds all three reporting stages and remains available as evidence.
| Dimension | Without continuous monitoring | With continuous monitoring |
|---|---|---|
| Detecting an outage | often only via a customer tip, hours later | automated, typically within minutes |
| When the deadline starts | unclear, hard to evidence | timestamped and traceable |
| Evidence for the report | reconstructed after the fact | low-gap, low-tamper history |
| Status communication | ad hoc and inconsistent | status page with a documented incident timeline |
| Final report | laborious manual work | derivable from the log |
The 4-hour deadline runs from classification. Detecting early and with a timestamp buys exactly the hours that decide whether the initial notification is orderly and on time.
— XICTRAQ compliance monitoring
For raw data to become dependable evidence, two things are needed: reliable alerting with escalation, and clean reporting. The alert chain to the right person is covered in the article on incident management with escalation levels; the business case for fast detection is shown in the piece on the cost of website outages. For documented outward communication during an incident, a public status page for customers helps, and for robust threshold control, error budgets and burn-rate alerts are useful. Reporting and a status page together form the low-gap resilience and incident evidence that makes DORA workable in practice.
Fines and Oversight: What Is at Stake
DORA comes with meaningful enforcement tools. For critical ICT third-party providers, the Lead Overseer can impose a periodic penalty payment of up to 1% of average daily worldwide turnover — on a daily basis, for up to six months, until the required measures are implemented (Regulation (EU) 2022/2554, Art. 35). For the financial entities themselves, member states set the specific administrative penalties and measures; the management body is expressly responsible too (Regulation (EU) 2022/2554).
That supervisors probe real resilience was already clear from the European Central Bank's cyber resilience stress test: in 2024, 109 directly supervised banks took part, and a sub-sample of 28 went through deeper testing including actual recovery checks (ECB 2024). At the same time, the threat level remains high — in the ENISA threat landscape for finance, the sector was the third-most-targeted, and among the observed DDoS incidents 58% hit banks (ENISA 2024). Incidents are costly in economic terms too: the financial sector, at an average of around USD 5.56 million per data breach, is among the most expensive industries (IBM Cost of a Data Breach 2025).
A common misconception is that supervisory measures only kick in after a security incident. In fact, an absent or inadequate ICT risk framework, an incomplete register of information, or late reports can already draw supervisory consequences (Regulation (EU) 2022/2554). Prevention therefore begins with demonstrable, ongoing diligence — not only in an emergency. Anyone also tracking the vulnerability reporting obligation under the Cyber Resilience Act can serve related evidence duties on the same monitoring basis.
This article draws on: Regulation (EU) 2022/2554 (Digital Operational Resilience Act, DORA), including the technical standards of the European Supervisory Authorities (ESAs — EBA, ESMA, EIOPA) on reporting major ICT-related incidents and on the register of information; European Banking Authority (EBA), Preparation for DORA application and the FAQ on the Register of Information, plus the 2024/2025 dry-run findings; ESAs, press release on the designation of critical ICT third-party providers of 18 November 2025 (EBA/ESMA/EIOPA); European Central Bank (ECB), Cyber Resilience Stress Test 2024; ENISA, Threat Landscape Finance Sector 2024; IBM, Cost of a Data Breach Report 2025; PwC, analyses of DORA's scope. This article is general information and does not constitute legal advice.