DORA Incident Reporting: The 4h/24h/72h Clock and the Duty to Inform Clients
Jul 26, 2026 | by openstatus | [compliance]
DORA — Regulation (EU) 2022/2554 — has applied since 17 January 2025. Unlike NIS2 it is a regulation, not a directive: it is directly applicable across the EU without national transposition, so the text itself binds you, supplemented by the technical standards.
Like NIS2, its incident obligations split into two that are frequently conflated:
- Reporting to your competent authority, on prescribed templates, on a tight clock.
- Informing your clients, under Article 19(3), where their financial interests are affected.
The second is where a status page belongs. The first is a regulatory filing, and no status page discharges it.
Who is in scope
Chapter I lists twenty categories of financial entity — credit institutions, payment institutions, account information service providers, electronic money institutions, investment firms, crypto-asset service providers and issuers of asset-referenced tokens, central securities depositories, central counterparties, trading venues, trade repositories, alternative investment fund managers, management companies, data reporting service providers, insurance and reinsurance undertakings and intermediaries, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, and securitisation repositories.
Plus ICT third-party service providers designated as critical, who fall under a direct EU oversight framework.
If you are a vendor, not a financial entity
You are most likely reached through Chapter V. Financial entities must have contractual arrangements with ICT providers covering service levels, incident notification to the entity, audit and access rights, exit strategies, and data location. In practice this arrives as contract terms and due-diligence questionnaires, not as a direct DORA obligation on you — unless you are designated critical, which is a small set of large providers.
Classification comes first
You cannot report until you have classified, and classification is what starts the tightest clock. The criteria in Commission Delegated Regulation (EU) 2024/1772 cover:
- Clients, financial counterparts, and transactions affected
- Reputational impact
- Duration and service downtime
- Geographical spread
- Data losses — availability, authenticity, integrity, confidentiality
- Criticality of services affected
- Economic impact
Two of those — duration and service downtime, and criticality of services affected — are the ones monitoring data speaks to directly. Being able to state precisely when a service became unavailable, from where, and for how long is an input to classification, not merely a nicety after the fact.
The reporting clock
| Stage | Deadline | Notes |
|---|---|---|
| Initial notification | No later than 4 hours after classification as major, and no later than 24 hours from becoming aware | Whichever binds first applies |
| Intermediate report | Within 72 hours of the initial notification | Required even if status is unchanged |
| Final report | No later than one month after the most recent intermediate report | Root cause, remediation, impact |
Slow classification does not buy time
The 24-hour outer limit runs from awareness regardless of when you classify. Deferring the classification decision compresses the window rather than extending it. Where an incident is resolved quickly, the intermediate and final reports may be combined into a single submission.
The stage deadlines and report contents are set by Commission Delegated Regulation (EU) 2025/301; the templates and submission formats by Commission Implementing Regulation (EU) 2025/302. Voluntary notification of significant cyber threats is also provided for under Article 19(2).
The client-facing duty — Article 19(3)
Where a major ICT-related incident has an impact on the financial interests of clients, financial entities shall, without undue delay as soon as they become aware of it, inform their clients about the major ICT-related incident and about the measures that have been taken to mitigate the adverse effects of such incident.
Two conditions worth reading precisely: the incident must be major, and it must have an impact on financial interests. Not every major incident triggers client notification, and not every client-visible degradation is a major incident.
Article 14 sits alongside it, requiring communication plans that enable responsible disclosure of major incidents to clients, counterparts, and the public, with a designated person or role responsible for implementing the strategy.
Article 11(2) also requires response and recovery procedures that include communication actions toward staff, external stakeholders, and the media.
Have the channel before you need it
Article 14 asks for a plan, not improvisation. A status page that already exists, is already branded, and already has clients subscribed is what turns "we have a communication plan" from a document into a capability. Standing one up during a major incident is the failure mode the article exists to prevent.
What a status page serves, and what it does not
Serves:
- Article 19(3) client information, with a timestamped record of what was said and when.
- Article 14 crisis communication, as the channel the plan names.
- Article 11(2) communication toward external stakeholders during response and recovery.
- Duration and downtime evidence feeding the classification criteria.
- Article 10 detection, as one input — DORA requires mechanisms to promptly detect anomalous activities, explicitly including ICT network performance issues.
Does not serve:
- The initial, intermediate, or final regulator reports. Prescribed templates, designated channel, different audience.
- Classification itself. That is your process and your judgement.
- Chapter IV — digital operational resilience testing. Vulnerability assessments, scenario-based testing, and threat-led penetration testing for entities that meet the criteria.
- Chapter V — ICT third-party risk. The register of information, concentration risk analysis, contractual requirements, exit strategies.
- Most of Chapter II — ICT risk management. Governance, the risk framework, protection, backup and recovery policies, learning and evolving.
- Board accountability. Article 5 places ultimate responsibility on the management body, which cannot be delegated to a tool.
The honest summary: DORA has five pillars, and a status page is one implementation detail inside part of one of them.
Retention
DORA expects records sufficient to support reporting and supervisory review, and Article 13 requires post-incident reviews that feed back into your risk framework. Your ability to reconstruct an incident months later — including the availability record behind classification — depends on what you retained.
Openstatus retention runs 14 days on Hobby, 3 months on Starter, 12 months on Pro, and 24 months on Scale. For a financial entity, the two short tiers are unlikely to be adequate; supervisory questions rarely arrive within a fortnight.
A practical setup
- Confirm your category and your competent authority. Know the submission channel before you need it — the ESMA DORA hub collects the joint ESA material if you are unsure where to start.
- Write the classification procedure against the 2024/1772 criteria, with a named decision-maker and a recorded timestamp for the decision.
- Pre-fill what you can of the 2025/302 templates. Four hours is not long to compose a filing from scratch.
- Define what "impact on the financial interests of clients" means for your business, so the Article 19(3) trigger is decided in advance rather than under pressure.
- Name the status page in your Article 14 communication plan and keep clients subscribed to it.
- Retain monitoring and incident data long enough to answer supervisory questions.
- Drill the whole path. The 4-hour clock does not accommodate a first attempt.
Openstatus covers steps 5 and 6, and contributes evidence to step 2 through its availability record — 28 monitoring regions, timestamped incident history, email and RSS/Atom/JSON subscriber notification, and a full in-transaction audit log on Pro and Scale. Steps 1, 3, 4, and 7 are yours, and that is where supervisory exposure concentrates.
Primary sources
DORA is a regulation, so the EUR-Lex text is the operative law — there is no national act to chase. The technical standards carry most of the detail.
- Regulation (EU) 2022/2554 (DORA) — Article 11 for response and recovery, Article 14 for communication, Articles 17–20 for incident management and reporting, Chapter V for third-party risk.
- Commission Delegated Regulation (EU) 2024/1772 — classification criteria and materiality thresholds for major incidents and significant cyber threats.
- Commission Delegated Regulation (EU) 2025/301 — content of the initial, intermediate, and final reports, and the time limits.
- Commission Implementing Regulation (EU) 2025/302 — the standard forms, templates, and reporting procedures.
- ESMA's DORA hub — joint ESA guidance, Q&As, and implementation material.
Background, not advice
Financial services regulation carries supervisory consequences that a guide cannot scope for your entity. Use this to orient yourself in the texts, then work it through with your compliance function.
Related reading
- NIS2 incident reporting — the general regime; where both apply, reporting under DORA can satisfy the NIS2 duty
- SOC 2 and your status page — what customers ask for alongside the regulator
- Incident severity matrix — a starting point for the classification procedure
- What is MTTR — duration and downtime feed the classification criteria
- Status pages for crypto exchanges and DeFi protocols — if you are a CASP or token issuer
Start your status page