DORA Incident Reporting: Architecture and Operating Model

DORA’s incident reporting timeline gets quoted everywhere — 4 hours, 72 hours, one month. What’s less discussed is the operating model needed to actually hit those deadlines, and why the classification decision, not the report itself, is where most firms will struggle first.

Article 19 of DORA requires financial entities to report major ICT-related incidents to their competent authority. The classification criteria sit in a separate delegated regulation; the timelines and templates in two more. Put together, they describe a three-stage reporting process with a clock that starts the moment an incident is classified as major — not the moment it’s detected, and not the moment it’s resolved. This is what the process actually requires to run, operationally, inside a technology function.

The classification gate comes first

An incident is classified as major when it meets at least two of the classification criteria — client impact, duration, data loss, geographical spread, economic impact, and disruption to critical or important functions — or a single criterion combined with an economic-impact threshold of €100,000. Critical services being affected is a mandatory gateway condition, not one of the two criteria itself; a common early mistake is counting it as one of the two and looking for just one more.

The classification decision has to happen fast enough that the reporting clock, once it starts, is achievable. If your classification process requires convening a committee, and that committee can’t meet within an hour or two of detection, the four-hour initial notification deadline is already at risk before anyone has started drafting a report.

The three-stage timeline

• Initial notification: as early as possible, and in any case within four hours of classifying the incident as major — but no later than 24 hours from when the entity first became aware of it, even if classification takes longer.
• Intermediate report: within 72 hours of the initial notification, even where nothing material has changed. If the situation shifts significantly before then, or regular operations are restored, an updated intermediate report is required regardless of the 72-hour mark.
• Final report: within one month of the latest intermediate report — not one month from the incident itself. Submitting several updated intermediate reports pushes the final-report deadline out accordingly.

The final report is where root cause analysis, the full timeline from detection to resolution, quantified impact, and remediation measures are expected — estimates are acceptable in earlier stages where actual figures aren’t yet available, but the final report should replace them with confirmed numbers.

Who this is for

• The CISO or head of technology risk who owns incident response and now has to prove the process meets a regulatory clock, not just an internal SLA.
• The compliance lead building the reporting workflow who needs to know where the actual failure points are, not just the headline deadlines.
• The board member who wants to know what “we can report a major incident within four hours” actually requires of the organisation to be true.

The operating model, not just the template

A harmonised reporting template solves the “what to fill in” problem. It doesn’t solve the “who decides, and how fast” problem, which is where the architecture actually needs to exist:

1. A named classification authority — and a deputy — who can make the major/non-major call without waiting for a scheduled meeting, including out of hours.
2. A pre-calculated decision matrix mapping your entity’s specific thresholds against the six classification criteria, so the call is a lookup, not a fresh analysis under pressure.
3. Contractual provisions with ICT third-party providers requiring prompt notification of incidents at their end — the reporting obligation sits with you, not the provider, and you can’t report what you don’t know about.
4. A single owner for aggregating recurring, related incidents — DORA requires smaller incidents to be assessed cumulatively when they collectively meet materiality thresholds, which a purely per-incident process will miss.
5. A client notification workflow that runs in parallel with regulatory reporting — Article 19(3) requires informing affected clients without undue delay when their financial interests are impacted, and that’s a separate communication track from the report to your competent authority.

Where this connects to Article 6

Incident reporting isn’t a standalone process — it’s one of the four pillars of the ICT risk management framework required under DORA Article 6, and it’s meant to feed back into it. Article 6 explicitly requires the framework to be reviewed upon the occurrence of major incidents, not just annually. If your incident reports and your framework review sit in different teams that don’t talk, that link tends to get missed — and it’s one of the more visible gaps a supervisory review will notice.

The failure modes worth knowing in advance

Treating “nothing new to report” as a reason to skip the intermediate report. The RTS is explicit that the 72-hour intermediate report is due even where the incident’s status hasn’t changed.

Not knowing where a third-party incident lands. A major incident at a critical ICT third-party provider affecting your critical functions must be reported by you, even if you only learn about it indirectly — which is precisely why the contractual notification clause above matters.

Conflating DORA reporting with GDPR breach notification. An incident involving personal data can trigger both obligations simultaneously, to different authorities, on different (though overlapping) clocks. They need coordinated handling, not a single workflow that assumes one covers the other.

Significant cyber threats: the voluntary layer worth using

Alongside mandatory major-incident reporting, DORA establishes a voluntary framework for notifying significant cyber threats — events that haven’t yet caused a major incident but carry real potential to. There’s no obligation to report these, but firms are encouraged to do so as a demonstration of proactive risk management, and it feeds the same relationship with the competent authority that matters when a genuine major incident does occur. A technology function that has never used this channel, and then shows up for the first time with a four-hour major-incident notification, is starting that regulatory conversation from a colder position than one with an established pattern of proactive engagement.

There’s also a practical aggregation point worth building into the workflow deliberately: recurring, related incidents that individually fall below the major-incident threshold can still meet it when assessed cumulatively. A monitoring process that evaluates each alert in isolation, without a mechanism for recognising a pattern of smaller related events, will systematically under-classify exactly the kind of persistent, low-grade compromise that regulators most want visibility into.

How we engage with this

We read incident reporting processes against what DORA actually requires — as part of a Technology Control Review, typically alongside the broader ICT risk management framework. The output is a written assessment of where the classification authority, the escalation path, and the third-party notification clauses stand relative to the four-hour clock, with specific gaps identified for the board to act on.

We don’t build incident-management software. We don’t run tabletop exercises. We don’t submit reports on your behalf. We read what’s there, identify what’s missing, and write it down for the people who have to decide what to do about it.

Pricing is published at /pricing/. If your board wants to know whether your incident reporting process can actually meet DORA’s timelines under pressure, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.