Incident Reporting Under DORA: The Deadlines That Catch Firms Off Guard

Table of Contents

The following sections cover what counts as a reportable incident under DORA, the actual reporting clock, the organizational gaps that most commonly cause deadline failures, and why so many firms discover these gaps only during a real incident.

• A Clock That Starts Before Most Teams Realize It
• What Actually Counts as a Major ICT Incident
• The Classification Criteria, in Detail
• Why Severity Assessment Isn’t a One-Time Snapshot
• The Three-Report Structure: Initial, Intermediate, Final
• The Actual Deadlines, Hour by Hour
• Why the Precise Deadlines Require Checking Current Standards
• Who Within the Organization Actually Files the Report
• Where Tooling and Automation Genuinely Help
• When the Incident Originates at a Third-Party Provider
• Cross-Border Reporting for Multi-Country Groups
• Language and Format Requirements Across Jurisdictions
• What the Board Actually Needs to Know, and When
• The Common Gaps That Blow the Deadline
• Building Genuine Reporting Readiness
• Case Study: A Payment Institution’s First Major Incident
• The Mistakes That Compound Under Pressure
• Incident Reporting Readiness Checklist
• FAQ
• Regard d’Expert
• Références

A Clock That Starts Before Most Teams Realize It

Among all of DORA’s operational requirements, incident reporting deadlines are the ones most likely to catch a financial institution genuinely off guard, not because the rule is unclear, but because the reporting clock starts ticking the moment an incident is classified as major, often well before the organization’s crisis response has even fully mobilized around the specific facts of that incident. Teams accustomed to a measured, days-long incident response process discover, usually during their first real major incident, that DORA’s initial notification window is measured in hours.

This isn’t a theoretical risk. Incident classification and reporting is one of DORA’s five pillars precisely because regulators learned, from prior sector incidents, that slow or inconsistent incident disclosure across the financial sector delays the kind of coordinated response that limits contagion when a major ICT disruption affects multiple institutions simultaneously, often through a shared critical provider whose failure ripples across an entire client base at once.

What Actually Counts as a Major ICT Incident

Not every technical disruption triggers DORA’s reporting obligations. The regulation defines a major ICT-related incident based on a combination of factors: the number of clients or financial counterparts affected, the duration of the disruption, the geographical spread of the impact, the data losses involved, the criticality of the services affected, and the economic impact of the incident on the entity itself.

This multi-factor definition means classification isn’t a simple binary check, it requires judgment applied consistently against defined thresholds, exercised under time pressure during an actual incident, precisely when careful judgment is hardest to apply. Organizations that haven’t pre-defined and rehearsed this classification exercise before a real incident occurs routinely lose valuable hours simply debating whether a given incident even meets the reporting threshold.

The Classification Criteria, in Detail

Each of the classification factors deserves specific attention because they interact rather than apply independently. The number of affected clients matters relative to the entity’s total client base, not as an absolute figure, meaning the same incident might be immaterial for a large institution but clearly reportable for a smaller one serving a concentrated client segment. Duration is assessed against the criticality of the affected service, a brief outage of a systemically important payment function can meet the threshold faster than a longer disruption to a peripheral internal tool.

Geographical spread becomes particularly relevant for multi-country groups, an incident contained to a single national subsidiary is assessed differently than one propagating across the group’s cross-border operations. Economic impact, meanwhile, isn’t limited to direct remediation costs, it also captures reputational and regulatory exposure the entity reasonably anticipates as a consequence of the incident, a forward-looking element that requires genuine judgment rather than a simple retrospective tally.

Data loss, the remaining major criterion, deserves separate attention because it interacts with other EU data protection obligations an entity may already be familiar with, notably breach notification requirements under data protection law. Entities sometimes assume that a data protection breach assessment automatically satisfies DORA’s incident classification, when in practice the two assessments serve different purposes and use different criteria, meaning an incident can meet one threshold without automatically meeting the other, or vice versa, and both assessments may need to run in parallel rather than one substituting for the other.

Why Severity Assessment Isn’t a One-Time Snapshot

A frequently underappreciated aspect of DORA’s incident framework is that severity assessment isn’t a single judgment made once at the moment of detection. An incident initially assessed as below the major threshold can evolve, as duration extends, as affected client numbers grow, or as root cause investigation reveals a broader scope than first understood, into one that crosses the threshold hours or even a day after initial detection.

This means incident response teams need an explicit, ongoing reassessment discipline, not a single classification checkpoint at the start of the incident. Organizations that treat classification as a one-time gate, decided and then forgotten, risk missing the point at which a genuinely evolving incident crosses into major territory, precisely because nobody was tasked with continuously re-evaluating the classification as new facts emerged throughout the incident’s lifecycle.

Classification under time pressure is where most incident reporting processes actually break down.

The Three-Report Structure: Initial, Intermediate, Final

DORA structures incident reporting around three successive submissions rather than a single notification. The initial notification, filed within the tightest deadline, confirms that a major incident has occurred and provides the essential facts known at that early stage, even if the full picture remains incomplete. An intermediate report follows, updating the initial notification as the situation develops and the entity’s understanding of root cause and impact matures. A final report closes the cycle, providing a complete root cause analysis and the remediation measures taken.

This three-stage structure reflects a deliberate regulatory design choice: rather than waiting for complete information before reporting anything, which would delay disclosure by days or weeks in complex incidents, DORA requires early, necessarily incomplete disclosure, followed by iterative refinement. Organizations that misunderstand this structure, waiting to file only once they have a complete picture, breach the initial notification deadline by definition, since that deadline is explicitly designed to be met before full information is available.

The Actual Deadlines, Hour by Hour

The precise deadlines are defined through regulatory technical standards developed by the European Supervisory Authorities, and while exact figures should always be verified against the current technical standards in force, the initial notification window for major incidents is measured in hours from classification, not days, a genuinely tight window compared to many organizations’ existing crisis communication practices built around board and client notification timelines that assume more preparation time.

This compressed timeline is precisely why the classification step discussed above matters so much: an organization that spends several hours debating whether an incident meets the major incident threshold has already consumed a meaningful share of the total time available to prepare and file the initial notification, leaving little room for the substantive work of gathering the facts that notification actually requires.

Who Within the Organization Actually Files the Report

A surprisingly common gap in incident reporting readiness isn’t technical but organizational: many entities haven’t clearly designated, in advance, who holds the authority and responsibility to file the initial DORA notification once an incident is classified as major. Without this clarity, precious time is lost during a real incident simply determining who is supposed to act, coordinating between IT, compliance, legal, and communications functions that may not have a pre-established protocol for this specific, time-critical decision.

Organizations with mature incident reporting readiness designate this responsibility explicitly, typically to a compliance or risk function with a clear escalation path to IT and security teams for the technical facts needed, and with pre-authorized templates and approval chains that don’t require assembling an ad hoc committee once the clock has already started running.

A related but distinct challenge involves the approval chain itself: even with a designated filer, many organizations still route the actual notification through a sign-off process involving senior legal or executive approval before submission, a reasonable control in principle, but one that can silently consume a disproportionate share of the available reporting window if the approval chain itself hasn’t been streamlined for the specific urgency DORA demands. Organizations that pre-authorize the designated filer to submit within defined parameters, reserving fuller executive review for the subsequent intermediate and final reports rather than gating the initial notification behind the same approval layers used for routine business communications, consistently perform better against the tight initial deadline.

Where Tooling and Automation Genuinely Help

While incident reporting readiness is fundamentally an organizational and procedural challenge rather than a purely technical one, certain tooling investments meaningfully reduce the time pressure during a real incident. Automated alerting that flags potential major incidents against pre-defined thresholds the moment monitoring systems detect anomalies gives classification teams a head start rather than starting entirely from manual assessment. Pre-built notification templates integrated directly into incident management platforms, auto-populating known fields from the incident ticket itself, reduce drafting time further still.

The organizations that benefit most from this tooling are those that have already done the harder organizational work, clear classification criteria, designated filing authority, streamlined approval chains, since tooling amplifies a functioning process but cannot substitute for one that doesn’t exist. A sophisticated automated alerting system feeding into an undefined, ad hoc decision-making process still produces the same delays as no tooling at all, the bottleneck simply shifts from detection to the human decision layer that tooling alone cannot resolve.

When the Incident Originates at a Third-Party Provider

Incident reporting becomes meaningfully more complex when the underlying incident originates not within the financial entity’s own systems, but at a third-party ICT provider supporting a critical function. The financial entity remains responsible for its own DORA reporting obligations regardless of where the incident technically originated, which means the entity’s reporting clock starts based on when it becomes aware of, or should reasonably have become aware of, the incident, not necessarily when the provider itself detects or discloses it.

This creates a genuine dependency on the provider’s own incident communication speed and quality, precisely the kind of dependency DORA’s contractual requirements for critical providers, covered elsewhere in this series, are designed to address through mandatory incident cooperation clauses. An entity relying on a provider with slow or unclear incident communication practices inherits that provider’s weakness as its own compliance risk, since DORA doesn’t extend the entity’s own reporting deadline simply because the provider was slow to inform it.

A provider’s slow incident communication becomes the financial entity’s own compliance risk under DORA.

Cross-Border Reporting for Multi-Country Groups

For financial groups operating across multiple EU member states, incident reporting adds a layer of coordination complexity beyond the single-entity case. An incident affecting operations across several countries may trigger reporting obligations to multiple national competent authorities simultaneously, each potentially expecting the notification through its own designated channel, even though the underlying regulatory requirements are harmonized at EU level.

Groups that haven’t pre-mapped which national authorities need to be notified for incidents affecting which subsidiaries or cross-border services routinely lose time during an actual cross-border incident simply determining the correct notification recipients, a problem entirely avoidable through advance preparation but frequently discovered only in the middle of a live, time-pressured incident.

This mapping exercise gains additional complexity when a group’s internal structure doesn’t neatly align with its regulatory footprint, a shared service center supporting multiple national subsidiaries from a single location, for instance, may need to trigger notifications to several national authorities simultaneously for what is, from an internal operational perspective, a single incident affecting a single system. Groups that have already documented this alignment between internal service delivery structure and external regulatory notification obligations avoid the scramble of reconstructing this mapping in real time, under pressure, while an incident is still actively unfolding.

Language and Format Requirements Across Jurisdictions

A practical detail that frequently surprises multi-country groups involves the language and format in which incident notifications must be submitted to different national competent authorities. While the substantive content requirements are harmonized through DORA’s technical standards, some national authorities expect submissions in the local language rather than English, and some maintain their own specific submission portals or formats distinct from a generalized EU template.

Groups operating across several countries benefit from pre-translating standard notification template language into each relevant jurisdiction’s expected language ahead of time, rather than requiring translation under time pressure during an actual incident, when the compliance team’s attention is already stretched across classification, internal coordination, and the substantive drafting of the incident’s technical facts. This is a small, almost administrative preparation step, but one that recurringly consumes disproportionate time during real incidents precisely because it’s so easy to overlook until it’s urgently needed.

What the Board Actually Needs to Know, and When

Beyond the regulatory notification itself, DORA’s governance pillar implies that board-level oversight of incident management is a genuine expectation, not merely the technical reporting obligation to supervisory authorities. This raises a related but distinct question many organizations handle inconsistently: what does the board need to know about a major incident, and on what timeline, separate from the regulatory notification clock itself.

Organizations with mature governance practices maintain a board or risk committee notification protocol running in parallel with, but distinct from, the regulatory reporting timeline, ensuring executive oversight isn’t purely a downstream consequence of regulatory process but an active, informed governance function throughout the incident’s lifecycle. This dual-track approach, regulatory notification on one clock, board awareness on a parallel but coordinated clock, prevents the common failure mode where board members learn the full scope of a significant incident only well after the fact, from a post-incident report rather than through active awareness during the event itself.

The Common Gaps That Blow the Deadline

Several recurring gaps explain why organizations miss DORA’s tight reporting deadlines even when they’re aware of the requirement in principle. Classification ambiguity, discussed above, consumes time that should be spent on substantive reporting work. Unclear internal ownership of the filing decision creates coordination delays at exactly the wrong moment. Dependency on slow third-party incident communication imports a provider’s weakness into the entity’s own compliance timeline. And a lack of pre-built reporting templates means teams draft the initial notification from scratch during the incident itself, rather than filling in a pre-approved structure requiring only incident-specific facts.

Building Genuine Reporting Readiness

Genuine readiness starts with a documented, rehearsed classification methodology applied through tabletop exercises before a real incident forces the question, so that when classification judgment is actually needed, the criteria and thresholds are already familiar rather than being interpreted for the first time under pressure. It continues with explicit designation of filing authority and a pre-approved notification template requiring only incident-specific details to be completed, cutting drafting time dramatically compared to starting from a blank page.

It also requires building the third-party dependency explicitly into incident response planning, ensuring contractual incident cooperation clauses with critical providers translate into an actual, tested communication channel that functions quickly during a real incident, not just a clause sitting unused in a contract nobody has stress-tested. Finally, for multi-country groups, a pre-built map of which national authorities require notification for which subsidiaries and services removes a decision point that otherwise consumes time during the incident itself.

Case Study: A Payment Institution’s First Major Incident

A mid-sized European payment institution experiences a significant service disruption affecting its card processing capability for several hours, following a failure at a critical infrastructure provider supporting its transaction routing. The institution’s technical teams identify and begin remediating the root cause within the first hour, a genuinely fast technical response by most standards.

The compliance team, however, spends nearly three hours debating whether the incident meets DORA’s major incident threshold, since the institution had never previously rehearsed this classification exercise against a real scenario, and the criteria, while documented, had never been tested against an incident of this specific shape. By the time classification is confirmed and the initial notification is drafted from scratch, using no pre-existing template, the institution files its initial notification close to the edge of the permitted window, with internal reviewers uncomfortably aware of how little margin remained.

The post-incident review identifies both gaps clearly: the absence of a rehearsed classification exercise, and the absence of a pre-approved notification template. Over the following two months, the institution runs two tabletop exercises simulating different incident shapes against its classification criteria, and builds a pre-approved notification template requiring only incident-specific facts to complete. Its next significant incident, eight months later, sees the initial notification filed with more than half the available window still remaining, a direct result of removing avoidable friction from a process that, in the first incident, consumed nearly all the available time on decisions that should have been settled in advance.

The institution’s compliance lead later reflects that the most valuable single change wasn’t the notification template itself, useful as it was, but the explicit, pre-authorized delegation of filing authority that removed the need to convene senior approval during the incident itself. That single organizational change, decided and documented well before any incident, did more to compress the actual filing time than any technical tooling improvement made during the same period, a finding consistent with the broader pattern that incident reporting readiness is predominantly an organizational discipline rather than a technology problem to be solved with better software alone.

Why the Precise Deadlines Require Checking Current Technical Standards

It’s worth being explicit about a point that matters for any organization building its own internal playbook: the precise hour-by-hour deadlines for initial, intermediate, and final incident reports are defined through regulatory technical standards developed and periodically refined by the European Supervisory Authorities, not fixed permanently in the primary DORA regulation text itself. This means an internal playbook built once, citing specific deadline figures, risks becoming outdated if those technical standards are subsequently revised.

Organizations maintaining incident reporting playbooks should build in a periodic review checkpoint, confirming current deadline figures against the latest published technical standards rather than assuming a playbook built in an earlier compliance cycle remains accurate indefinitely. This is a small governance discipline, but one that prevents the uncomfortable discovery, during a live incident, that the internal playbook cites deadline figures that regulatory guidance has since updated.

The Mistakes That Compound Under Pressure

Never rehearsing incident classification before a real incident forces the question. Classification judgment exercised for the first time under pressure consumes time that should go toward substantive reporting work.

Leaving filing authority undesignated or ambiguous. Coordination delays at the exact moment speed matters most are almost always an organizational gap, not a technical one.

Assuming a third-party provider’s incident communication will be fast enough. DORA doesn’t extend an entity’s reporting deadline because a provider was slow, making this dependency a genuine compliance risk if untested.

Drafting the initial notification from scratch during the incident. A pre-approved template requiring only incident-specific details dramatically cuts the time needed compared to composing a notification from a blank page under pressure.

Failing to map cross-border notification requirements in advance for multi-country groups. Determining which national authorities need notification during a live cross-border incident wastes time entirely avoidable through advance preparation.

Assuming an internal playbook’s cited deadlines remain accurate indefinitely. Regulatory technical standards defining exact deadlines can be revised, and a playbook never rechecked against current standards risks citing outdated figures precisely when accuracy matters most.

Gating the initial notification behind the same approval layers used for routine communications. A pre-authorized filer operating within defined parameters clears the initial deadline far more reliably than a process requiring full executive sign-off before every submission.

Incident Reporting Readiness Checklist

This checklist gathers the points of vigilance discussed throughout this article, intended as the basis for an honest internal readiness assessment before the next real incident tests the gaps directly.

• Has the classification methodology been tested through tabletop exercises against realistic incident scenarios, not just documented on paper?
• Is filing authority for the initial notification explicitly designated, with a clear escalation path to technical teams for the facts needed?
• Are incident cooperation clauses with critical providers backed by an actual, tested communication channel, not just a contractual clause?
• Does a pre-approved notification template exist, requiring only incident-specific details to complete?
• For multi-country groups, is there a pre-built map of which national authorities require notification for which subsidiaries and services?
• Are notification template translations pre-prepared for each relevant jurisdiction’s expected submission language?
• Is board or risk committee awareness of significant incidents running on a defined protocol, rather than depending entirely on the regulatory reporting timeline?
• Has the internal playbook’s cited deadline figures been checked against the current version of the relevant regulatory technical standards?

FAQ

Does every ICT incident need to be reported under DORA?
No, only incidents meeting the major incident classification criteria, based on client impact, duration, geographical spread, data loss, service criticality, and economic impact, trigger the formal reporting obligation.

What happens if an entity misses the initial notification deadline?
Consequences vary by national competent authority and the specific circumstances, but a missed deadline is itself a compliance failure independent of how well the underlying incident was actually handled technically, which is precisely why reporting readiness deserves attention separate from technical incident response capability.

Can an incident be reclassified as major after the initial assessment concluded it wasn’t?
Yes, if new information emerges indicating the incident meets the threshold after all, the entity should file the required notification promptly upon that reassessment rather than treating the initial classification as final and irreversible, since severity assessment is an ongoing discipline throughout the incident lifecycle, not a single checkpoint decided once and never revisited.

Do smaller financial entities face the same reporting deadlines as large institutions?
The classification criteria and reporting structure apply broadly across the regulated scope, though the practical thresholds for what counts as major, particularly client impact assessed relative to total client base, naturally differ by entity size and context, meaning a smaller entity may cross the threshold at absolute numbers that would look minor for a systemically important institution.

Should incident reporting readiness be tested as often as broader resilience testing like TLPT?
Tabletop exercises specifically for incident classification and reporting can and should happen more frequently than a full TLPT cycle, since they’re lower cost to run and directly address the organizational, not just technical, readiness gaps that most commonly cause deadline failures.

Does DORA’s incident reporting obligation overlap with existing sector-specific incident notification rules?
In many cases yes, and entities already subject to other sector reporting obligations, such as payment services incident rules, need to map how those existing obligations interact with DORA’s requirements rather than assuming one automatically satisfies the other, since the triggering criteria, timelines, and recipient authorities aren’t always identical across frameworks.

Who bears responsibility if a critical provider delays incident disclosure to the financial entity?
The financial entity remains responsible for its own DORA reporting timeline regardless of provider delay, which is precisely why contractual incident cooperation clauses and a tested communication channel with critical providers matter as much as the entity’s own internal readiness.

Regard d’Expert

Having coordinated cybersecurity and compliance programs across multi-country contexts, I consistently see incident reporting readiness treated as a documentation exercise, a policy written and filed away, rather than a rehearsed organizational capability tested regularly and deliberately against realistic, varied scenarios over time. The gap between those two states is exactly what determines whether a real incident is reported within the deadline or not, and it’s a gap that costs little to close through tabletop exercises, yet remains surprisingly common even among otherwise well-prepared organizations.

Written by Steeve Vignissy, Senior Digital Transformation Consultant at Notoriti, with experience coordinating cybersecurity and compliance programs across multi-country financial and retail contexts, including incident governance and audit committee reporting.

👉 Contact Notoriti to stress-test your incident classification and reporting readiness before your next real incident does it for you, through a tabletop exercise built around scenarios genuinely relevant to your organization.

Related Reading

• DORA Third-Party Risk: What « Critical ICT Provider » Really Means for You
• Test d’Intrusion Ciblé par la Menace (TLPT) : Ce Que DORA Exige (FR)
• Le Registre d’Information DORA (FR)

Références

• Orbiq, DORA Compliance Guide 2026: Requirements & Deadlines, March 2026
• Mitratech, What Is DORA? What Financial Institutions Need to Know in 2026, June 2026
• IBM, What Is the Digital Operational Resilience Act (DORA)?, June 2026