DORA Incident Reporting Timeline and Workflow

For a major ICT-related incident under DORA, the initial notification is due as early as possible and, in any case, within four hours after the incident is classified as major and no later than 24 hours after the financial entity becomes aware of the incident. The intermediate report is due within 72 hours after the initial notification. The final report is due no later than one month after the intermediate report, or after the latest updated intermediate report if one was submitted.

Those deadlines are the external reporting clock. The operational workflow starts earlier, with detection and internal incident management, because the organization still has to determine whether the incident affects critical services and meets DORA's major-incident thresholds.

That distinction matters. A security event does not become reportable simply because it looks serious. Teams need a fast path from awareness to impact assessment, classification, escalation, and regulatory reporting without waiting for a complete forensic picture.

What is the DORA incident reporting timeline?

The current timeline comes from Commission Delegated Regulation (EU) 2025/301. It supplements DORA Article 19 with the exact time limits for the initial notification, intermediate report, and final report.

The final adopted rule is worth checking carefully because older articles and consultation documents can show different reference points. The 72-hour deadline now runs from submission of the initial notification, not from classification of the incident as major.

Which DORA incidents have to be reported?

DORA does not require external reporting of every ICT incident. Article 17 requires financial entities to record and manage ICT-related incidents, while Article 19 requires external reporting of incidents classified as major. Article 18 and Delegated Regulation (EU) 2024/1772 provide the classification criteria and thresholds.

At a high level, an incident is major when it affects a critical service and meets the major-incident test in the delegated regulation. Successful malicious and unauthorized access to network and information systems can itself satisfy the key data loss threshold. Otherwise, the incident generally needs to meet at least two of the other materiality thresholds.

The criteria examine several types of impact. These are the categories an incident team needs to assess quickly before deciding whether the external reporting workflow applies:

• clients, financial counterparts, and affected transactions;
• reputational impact;
• incident duration and service downtime;
• geographical spread across Member States;
• loss of data availability, authenticity, integrity, or confidentiality;
• criticality of the services affected;
• economic impact.

The exact thresholds matter, but the working decision should sit in the incident-classification process rather than be reconstructed from memory during an outage. The DORA Incident Classification Matrix should own that detailed decision logic.

When does the DORA reporting clock actually start?

Three moments are easy to confuse: the incident occurring, the organization becoming aware of it, and the incident being classified as major. DORA uses awareness and classification differently.

The 24-hour limit is tied to awareness. The four-hour limit is tied to classification as major. That means the team should not treat classification as a way to postpone the reporting process while investigation continues.

There is also a specific rule for late classification. If the entity has not classified the incident as major within 24 hours after awareness but later concludes that it is major, it must submit the initial notification within four hours after that later classification.

What should happen before the initial notification?

DORA Article 17 requires an ICT-related incident management process. The regulatory report is therefore one output of a wider response process, not the first action an incident team takes.

A practical sequence from awareness to the first regulatory notification looks like this:

1. Detect and record the ICT-related incident with a reliable awareness timestamp.
2. Escalate the incident to the people responsible for technical response, business impact, compliance, and regulatory communication.
3. Identify affected services, systems, data, clients, transactions, locations, and ICT third parties.
4. Assess whether a critical service is affected and apply the DORA classification criteria and materiality thresholds.
5. Record the classification decision, including the information used and any estimates made because the impact is still developing.
6. If the incident is major, prepare and submit the initial notification within the applicable time limit while technical containment and recovery continue.

This is where operational resilience and reporting meet. The response team needs enough telemetry and service context to contain the incident, while the compliance path needs enough structured information to classify it and notify the competent authority on time. Our guide to operational resilience under DORA explains how those capabilities fit into the wider resilience model.

What goes into the DORA initial notification?

Commission Delegated Regulation (EU) 2025/301 sets the minimum information for the initial notification, while Implementing Regulation (EU) 2025/302 provides the standard reporting template. The first report is intentionally narrower than the final report because the investigation may still be in progress.

The initial stage is designed to tell the competent authority what happened, when the incident was detected and classified, why it is considered major, which Member States are affected, how it was discovered, and whether business continuity arrangements have been activated. Where the origin is already known, that information can also be included.

Teams should not delay the first notification simply because later-stage fields are incomplete. The official template allows information required for later reports to be added early when it is already available.

What changes in the intermediate report?

The intermediate report is due within 72 hours after the initial notification, even when the incident status or handling has not materially changed. It expands the authority's view of the incident as investigation and recovery progress.

The intermediate stage captures a more developed picture of impact, response, indicators of compromise where relevant, and the current handling status. DORA also requires an updated intermediate report without undue delay when the situation changes materially and, in any case, when regular activities have recovered.

That makes incident documentation a live process. The evidence used for the initial classification, technical investigation, containment decisions, service recovery, and communications should be maintained in a way that can support the next regulatory update without rebuilding the incident history from scratch.

What is required in the final DORA incident report?

The final report is due no later than one month after the intermediate report, or after the latest updated intermediate report where one was submitted. This is a calendar-month rule, not a generic 30-day deadline.

By this stage, the report must address the root cause, when the incident was resolved and the root cause was addressed, how the incident was resolved, relevant information for resolution authorities where applicable, direct and indirect costs and losses, financial recoveries, and recurring-incident information where relevant.

The final report should therefore be supported by the post-incident review, not written as a separate compliance exercise. Root-cause analysis, recovery evidence, cost assessment, corrective actions, and recurrence checks should feed both operational learning and the regulatory submission.

What if a reporting deadline falls on a weekend or bank holiday?

Delegated Regulation (EU) 2025/301 allows some financial entities to submit a notification or report by noon of the next working day when the deadline falls on a weekend or bank holiday in the entity's Member State. The exception is not universal.

For initial notifications and intermediate reports, the extension does not apply to credit institutions, central counterparties, operators of trading venues, or other financial entities identified as essential or important entities under NIS2. Competent authorities may also remove the extension for other significant or systemic financial entities. Teams should therefore know their supervisory position before relying on the next-working-day rule.

Can incident reporting be outsourced under DORA?

Yes, DORA Article 19(5) allows reporting obligations to be outsourced to a third-party service provider, but the financial entity remains fully responsible for meeting the requirements. Implementing Regulation (EU) 2025/302 also requires the entity to inform its competent authority about the outsourcing arrangement.

Outsourcing the submission step does not remove the need for internal classification, escalation, evidence, and decision ownership. A provider cannot report accurately if the financial entity cannot determine what service was affected, when awareness occurred, whether the incident is major, or how business impact is changing.

How does the official DORA incident reporting template work?

Implementing Regulation (EU) 2025/302 establishes the standard forms, templates, and procedures used for major ICT-related incident reporting. The same Annex I template supports the initial notification, intermediate report, and final report, with different fields becoming mandatory at each stage.

For the full regulatory map behind classification, reporting deadlines, and the official forms, see our DORA RTS and ITS technical standards list.

DORA incident reporting workflow: a worked timeline

A simple example shows why the awareness and classification timestamps need to be captured separately. The times below are illustrative, while the deadlines follow the current EU rules.

In a real incident, the classification may change as new evidence arrives. The process should preserve the timestamps, evidence, and decisions behind each stage so the reporting record remains understandable after the incident is over.

How should DORA reporting connect to the rest of the compliance program?

Incident reporting depends on information owned by several other DORA processes. Treating the reporting form as a standalone compliance task usually creates delays because the necessary data sits elsewhere.

The operational resilience model should provide the service and recovery context. The Register of Information can help identify relevant ICT third-party arrangements when a supplier is involved. The DORA vs. NIS2 comparison becomes relevant for entities that also fall within the NIS2 scope, especially where the same incident may trigger different legal reporting paths.

If an ICT provider is involved in the incident, our DORA ICT third-party risk management guide explains how provider obligations, dependencies, and contractual arrangements fit into the wider risk process.

If the same incident may trigger obligations under more than one framework, the Cross-Regulation Incident Reporting Cheat Sheet provides a practical DORA, NIS2, and GDPR reference.

Common DORA incident reporting mistakes

Most reporting problems start before someone opens the regulatory template. The process fails when detection, business impact, classification, and compliance ownership are disconnected.

• Treating the 24-hour limit as the only DORA deadline and missing the four-hour-from-classification rule.
• Using an older draft timeline that measures the 72-hour report from classification rather than from the initial notification.
• Calling the final deadline "30 days" instead of one month.
• Waiting for complete forensic certainty before making the major-incident decision.
• Failing to preserve the awareness timestamp and the classification timestamp separately.
• Assuming every ICT incident must be externally reported rather than applying the major-incident test.
• Treating the reporting template as the incident record instead of feeding it from a maintained response and evidence trail.
• Relying on a weekend extension without checking whether the entity falls within an exception.

Final thoughts: A usable DORA reporting process starts before the deadline

The regulatory clock is short because DORA assumes financial entities already have an incident-management process that can identify affected services, classify impact, escalate decisions, and preserve evidence while technical response continues.

The practical goal is to make awareness, classification, reporting, and recovery part of one operating sequence. When those steps are owned separately with no shared data, the deadline becomes the problem. When they are connected, the report becomes a by-product of a functioning response process.

Free guide

Classify incidents faster with the DORA Incident Classification Matrix

See which thresholds make an ICT incident reportable and when the reporting clock starts.

Get the free matrix

Frequently asked questions about DORA incident reporting

What is the DORA incident reporting deadline?

For major ICT-related incidents, the initial notification is due within four hours of classification as major and no later than 24 hours from awareness. The intermediate report follows within 72 hours of the initial notification, and the final report within one month.

Does DORA require every ICT incident to be reported?

No. Financial entities must record and manage ICT-related incidents, but external reporting under Article 19 applies to incidents classified as major under the DORA classification rules.

Which DORA article covers incident reporting?

Article 19 covers reporting of major ICT-related incidents. Article 17 establishes the incident management process, while Article 18 covers classification. Article 20 provides the mandate for technical standards on reporting content, timelines, and templates.

Is the DORA intermediate report due 72 hours after classification?

No. Under the final Delegated Regulation (EU) 2025/301, the intermediate report is due at the latest within 72 hours after submission of the initial notification.

Is the final DORA incident report due in 30 days?

No. The legal deadline is one month after the intermediate report or, where applicable, the latest updated intermediate report. "30 days" is not the wording of the current rule.

What if an incident is classified as major after the first 24 hours?

If the entity did not classify the incident as major within 24 hours after awareness but does so later, it must submit the initial notification within four hours after that later classification.

Does DORA provide an official incident reporting template?

Yes. Commission Implementing Regulation (EU) 2025/302 establishes the standard forms, templates, and procedures for initial, intermediate, and final reporting of major ICT-related incidents.