DORA Incident Reporting: Classification, Clocks and the Initial Report

Incident reporting is the DORA pillar most likely to be tested in anger, and the one where a process failure is immediately visible to the supervisor. Everything else can be remediated quietly. A late initial notification cannot.

The Three-Report Structure

DORA replaces the patchwork of national and sectoral incident notification regimes with a single harmonised sequence for major ICT-related incidents:

The reports go to the relevant competent authority for the entity type. Significant cyber threats may be notified voluntarily, and clients must be informed where a major incident has or may have an impact on their financial interests, without undue delay.

Two operational realities follow. First, the initial notification is due on a short clock measured from classification — which means the classification decision itself is on a clock. Second, an intermediate report is expected when the incident status changes, so a long-running incident generates more than three documents.

Classification: The Part That Actually Fails

DORA classifies incidents against criteria including the number and relevance of clients or financial counterparts affected and, where applicable, the amount or number of transactions affected; the reputational impact; the duration of the incident and the service downtime; the geographical spread, particularly across other member states; the data losses in relation to availability, authenticity, integrity or confidentiality; the criticality of the services affected; and the economic impact, both direct and indirect.

The regulatory technical standards give thresholds. The problem is not the thresholds — it is that at hour two of an incident, nobody knows the numbers. Client counts are estimates. Duration is open-ended. Data loss is unassessed.

Three practices separate firms that handle this well:

Pre-agreed proxies. Define in advance what stands in for each criterion when the true figure is unavailable. If the payments gateway is down, the affected-client proxy is the average transaction count for that hour on that weekday. Documented in advance, applied consistently, revisited in the final report.

A named classifier with authority. One role, available around the clock, empowered to classify without convening a committee. Committees are for reviewing the classification afterwards, not making it.

Documented non-major decisions. Every incident assessed and found not to be major should have a written classification decision on file. Supervisors ask for these, and their absence looks like the firm only classifies incidents it has already decided to report.

Recurring Incidents

Incidents that individually fall below the threshold but recur can, in aggregate, become major. Firms that classify each occurrence in isolation systematically under-report. Build an aggregation view into the incident register: same root cause, rolling window, cumulative impact against the thresholds.

The Register Behind the Reports

DORA requires a record of all ICT-related incidents and significant cyber threats, not just major ones. The register is the evidence base for aggregation, for trend analysis feeding the ICT risk framework review, and for demonstrating that classification is applied consistently rather than selectively.

Fields that matter and are usually missing: the classification decision and its reasoning, the proxies used, the time of detection separate from the time of occurrence, and the time of classification separate from both. Regulators reconstruct timelines from these three timestamps. If detection and classification are recorded as the same moment for every incident, the record is not credible.

Testing the Process

The incident process should be exercised at least annually against a realistic scenario, with the classification step included. Most tabletop exercises test technical response and skip classification entirely — which is precisely the step that carries regulatory consequence. Run the exercise with incomplete information, force a classification call against the clock, and see whether the proxies hold. This connects directly to the resilience testing programme.

Key Takeaways

• The initial notification clock starts at classification, so classification speed determines reporting compliance.

• Pre-agreed proxies for each classification criterion are the single highest-value preparation.

• Non-major classification decisions must be documented; supervisors ask for them.

• Recurring sub-threshold incidents can aggregate to major and are a systematic under-reporting risk.

• Record detection, occurrence and classification times separately — regulators reconstruct the timeline from all three.

Frequently Asked Questions

Who should hold classification authority? A named, rostered role with round-the-clock coverage — typically the incident manager on duty, with escalation to a senior accountable executive. Vesting it in a committee guarantees delay, and delay in classification is delay in notification.

Does an incident at an outsourced provider need reporting? Yes, if it meets the major threshold for the financial entity. The obligation sits with the regulated firm regardless of where the failure occurred, which is why contractual notification timelines with providers must be shorter than the firm's own reporting deadline. See the third-party risk article.

How does DORA reporting interact with GDPR breach notification? They are separate obligations with separate clocks, separate recipients and different thresholds. An incident can trigger both, one, or neither. Run them as parallel workflows from a single incident record rather than sequentially.

About the author

Jonas Mohamed Osman Abdelghafour is a risk and compliance expert advising banks, insurers, payment institutions and asset managers on operational resilience, ICT and third-party risk, financial crime and enterprise governance across EU and UK regimes. He works at the point where digital operational resilience obligations meet the evidence a board and a supervisor actually ask for. See qualifications and services, or get in touch to discuss an engagement.

*This article discusses regulatory frameworks in general terms and is not legal advice. Jurisdictional interpretation should be confirmed with qualified counsel.*