What this page is
A reading aid, not legal advice. Whether DORA applies to you, how an incident is classified as major, and what your competent authority expects are questions for your own compliance owner. Every quotation below is from Regulation (EU) 2022/2554 or Commission Delegated Regulation (EU) 2025/301 as published, linked at the end.
What DORA says
Clients (Article 19(3)): “Where a major ICT-related incident occurs and 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.”
The plan (Article 14(1)): financial entities have “crisis communication plans enabling a responsible disclosure of, at least, major ICT-related incidents or vulnerabilities to clients and counterparts as well as to the public, as appropriate.”
Authorities (Article 19(1) and 19(4)): “Financial entities shall report major ICT-related incidents to the relevant competent authority”, as an initial notification, an intermediate report and a final report. Delegated Regulation 2025/301, Article 5, sets the time limits: the initial notification “within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours from the moment the financial entity has become aware of the ICT-related incident”; the intermediate report “at the latest within 72 hours from the submission of the initial notification”; the final report “no later than one month” after the intermediate report, or after the latest updated one.
Third parties (Article 28(3)): financial entities maintain “a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers.”
Requirement by requirement
- Inform clients without undue delay (19(3)): a public RealUptime Status page, or a password-protected one for clients only. An incident posted there is emailed to the page's confirmed subscribers, and each update, including the mitigation measures, is timestamped. When a check fails the incident can open on its own, so the record starts when the outage does.
- Responsible disclosure to clients and the public (14(1)): the status page is the channel the plan names; incident templates keep the first message consistent under pressure.
- The initial, intermediate and final reports (19(4)): RealUptime does not file them. It keeps the timeline you write them from: when checks first failed and in which regions, when the incident opened, every update and when it resolved.
GET /api/v1/incidents/export?format=jsonreturns every incident with its full update timeline. - Watching ICT third-party providers (28): the register is your own document. Vendor dependency alerts tell you when a provider in it reports an incident, and RealUptime Outages keeps a public record of each one, which is useful evidence when you review a provider.
- Availability over time: monthly SLA reports per monitor, downloadable as CSV on Pro and Business, from RealUptime Monitor's own checks.
What RealUptime does not do
It does not classify incidents, does not submit anything to a competent authority, and does not make you compliant. RealUptime itself does not hold a security certification today; the trust page says where it stands, and a financial entity using it as an ICT provider should record it in its own register like any other. Application errors are in RealUptime Errors. The NIS2 guide covers the cross-sector rules.