Short answer. A major ICT-related incident under DORA is an operational or security event that hits a financial entity’s critical or important functions and crosses defined thresholds set in Commission Delegated Regulation (EU) 2024/1772. An incident is major when it affects critical services and either causes data losses or meets 2 or more of the other materiality thresholds, for example more than 100,000 clients affected or 10% of all clients, downtime above 2 hours, or gross costs above EUR 100,000. Once classified as major, the entity has 4 hours to send an initial report to its competent authority. These rules have applied since 17 January 2025.
DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), replaced a patchwork of national incident rules with one EU standard for the whole financial sector. Every bank, insurer, investment firm, payment institution, and crypto-asset service provider now classifies ICT-related incidents against the same criteria and reports the major ones on the same clock.
The practical shift is that “we had an outage” is no longer a judgment call left to an operations team. An incident is graded against 7 concrete criteria. When enough of them cross their thresholds, the incident becomes major, and a reporting duty starts automatically. A payment platform frozen for 3 hours during business hours, a data breach touching 120,000 customer records, or a core banking failure that stops card transactions across a country each trip the threshold on their own facts.
For financial entities in Central Europe, DORA is not optional and not phased. The regulation has applied in full since 17 January 2025, and national supervisors such as the Austrian FMA, the Czech CNB, and the National Bank of Slovakia now receive and review these reports. A missed or late major-incident report is a supervisory finding, and DORA sits alongside existing prudential obligations, so the same event can trigger both operational-resilience and data-protection duties.
The harder problem is speed. The 4-hour initial-report window starts when the entity classifies an incident as major, not when the crisis is resolved. That means the classification decision has to happen while the incident is still live and information is incomplete. Financial entities that treat classification as a post-mortem exercise miss the deadline. The ones that stay compliant build the threshold logic into their monitoring and incident-response process before anything breaks.
A major ICT-related incident under DORA is one that hits critical functions and crosses the thresholds in Commission Delegated Regulation (EU) 2024/1772.
Classification runs on the 7 criteria set in Commission Delegated Regulation (EU) 2024/1772: criticality of the services affected, number and relevance of clients and counterparts and transactions hit, reputational impact, duration and service downtime, geographical spread, data losses, and economic impact. The regulation attaches a measurable threshold to each.
An incident is major when it affects critical or important functions and either the data-losses threshold is met on its own, or 2 or more of the remaining thresholds are met together. The headline numbers are concrete: more than 100,000 clients or 10% of all clients using the affected service, service downtime longer than 2 hours for critical or important functions, incident duration above 24 hours, and gross direct and indirect costs and losses above EUR 100,000. Reputational impact counts when the incident reaches the media or generates repeated client complaints. This combination test is what keeps routine glitches out of the reporting channel while forcing genuine operational failures into it.
DORA sets a three-stage timeline, and the clock is short. The initial report is due within 4 hours of the entity classifying the incident as major, and no later than 24 hours after the entity first becomes aware of the incident. The intermediate report follows within 72 hours of that initial notification, with further updates each time the entity has a relevant status change. The final report is due no later than 1 month after classification, and it must set out the root cause and the remediation.
These three deadlines, 4 hours, 72 hours, and 1 month, are the operational spine of DORA incident management. They are fixed windows, not targets, and they run in parallel with the entity’s own recovery work. A bank cannot pause reporting to fix the system first.
DORA separates two reporting tracks. Major ICT-related incidents are events that have already happened and crossed the thresholds, and reporting them is mandatory. Significant cyber threats are potential events that have not yet materialized into an incident, and reporting those is voluntary. A financial entity may notify its authority of a serious threat it has detected, for example a targeted campaign against its systems, so supervisors can warn the wider sector, but it is not obliged to.
The distinction matters for process design. An entity needs one workflow that classifies live incidents against the 7 criteria and fires the mandatory reports, and a separate, lighter path for voluntary threat intelligence. Collapsing the two leads either to over-reporting noise or to missed mandatory deadlines.
Yes. DORA closes the loophole where a series of small failures each stays under the threshold. Recurring incidents that individually would not qualify as major can become reportable as a single major incident when a cumulative view is taken over time, provided they share the same apparent root cause and recur with a defined frequency. A payment gateway that drops for 20 minutes every few days is not one major incident, but the pattern can add up to one.
For a financial entity, this means incident data cannot be assessed only case by case. The monitoring system has to correlate related events and re-run the threshold test on the aggregate. Institutions without that correlation capability tend to under-report, which is exactly the gap supervisors look for.
Getting DORA incident classification right is a systems problem, not a paperwork problem. The threshold logic has to live inside the monitoring and response tooling, so classification happens in minutes while the incident is live, not in a report written days later. Ableneo builds that kind of production-grade governance and observability for regulated clients in Central Europe, where roughly 80% of the AI and data projects we ship reach production and our client base is concentrated in financial services and insurance. Our work with banks and insurers means we design incident and monitoring pipelines against the same core systems DORA governs. For the wider regulatory picture, see our explainer on what DORA is and how it applies to AI.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.