The EU Digital Operational Resilience Act gives financial entities a hard reporting clock for major ICT incidents. What is easy to miss from reading the text is when that clock actually starts, and what that means for a board that only hears about an incident once it has already been triaged.
What changed
DORA (EU Regulation 2022/2554) has applied directly across the EU financial sector since 17 January 2025. Chapter III requires financial entities to detect, classify, and report major ICT related incidents within regulator set time limits. Article 18 sets out the criteria used to classify an incident as major: clients or counterparts affected, duration, geographic spread, data loss, whether critical functions were affected, and economic impact, both direct and indirect.
Why it matters
Reading the regulation in isolation makes it sound like a reporting form. In practice, the classification criteria force a judgment call under time pressure, using information that is usually incomplete in the first hours of an incident. Duration and economic impact in particular cannot be known precisely on day one, yet the classification decision has to be made early enough for the reporting clock to be met.
| Article 18 criterion | What it actually asks for |
|---|---|
| Clients or counterparts affected | Scale of exposure and transaction volume, often unknown in the first hours |
| Duration | Downtime of the incident, which by definition cannot be final until the incident ends |
| Economic impact | Direct and indirect costs and losses, absolute and relative, again an early estimate at best |
| Service criticality | Whether critical or important functions were affected, which depends on a function inventory being current |
What changes for management
An incident response process built only to contain and remediate is not sufficient under DORA. It has to produce, on a compressed timeline, a defensible early classification against criteria that reference figures the organization may not yet have. That means the classification decision, and the evidence behind it, needs to be a designed step in the response process, not an afterthought handled once the technical work is finished.
What changes for the board
A board that only hears about an incident once management is confident in the details will, under DORA, hear about it after the regulatory clock has already been running for some time. The more useful oversight question is not whether management eventually classified the incident correctly, but whether the organization has a process that can produce a defensible classification, evidence included, inside the window the regulation actually gives it.
Questions boards should now ask
Who in the organization is authorized to make the Article 18 classification call, and on what evidence. How long, in practice, does it take from detection to that first classification decision today. What does the organization do when the true duration or economic impact is still unknown at the point a reporting decision is legally required. And separately from any single incident: does the register of critical and important functions that this classification depends on reflect how the business actually runs today, not how it was mapped at the last annual review.
Practical implications
The Article 18 criteria are also, not coincidentally, close to the inputs a quantitative risk model needs: business process criticality, dependency structure, and a distribution of plausible loss rather than a single guess. An organization that already expresses exposure this way going into an incident is not building the classification case from nothing under time pressure. It is reading a case it has already half built.