The 4-hour window: designing data flows for DORA major incident notification

This article is for informational purposes only and does not constitute legal advice. Consult a qualified legal professional for advice specific to your situation.

The 4-hour clock starts at classification, not at awareness: DORA’s initial notification deadline is 4 hours from formal classification, which itself must occur within 24 hours of first awareness. Both deadlines run in sequence, so the entire upstream process (detection, data assembly, classification decision) must be engineered to complete within that outer 24-hour envelope.
Classification requires pre-assembled data against specific RTS criteria: Commission Delegated Regulation (EU) 2025/301 sets the classification thresholds: client impact (including reputational damage as a secondary element), duration, geographic spread, data loss, and criticality of affected services. The data needed to assess each criterion must be captured during the incident, not reconstructed afterward.
Three reports, three purposes, each with distinct content requirements: The initial notification captures the incident at point-in-time. The intermediate report, due within 72 hours, assesses causes and current impact. The final report, due within one month, provides root cause analysis and remediation. The log underpinning all three is also the primary compliance evidence regulators will examine.
Manual processes cannot meet these timelines at scale: The 4-hour window fails under concurrent incidents, out-of-hours events, or slow classification. The detection layer must produce structured incident records (not raw alerts) populated from the firm’s service catalogue and client data automatically. This is an infrastructure design problem, not a response design problem.

The timeline that reveals the design requirement

DORA’s major incident reporting obligation is, on its face, straightforward. Major ICT-related incidents must be reported to the relevant national competent authority in three stages: initial notification, intermediate report, final report. The timelines are set in Commission Delegated Regulation (EU) 2025/301 (CELEX: 32025R0301), the RTS on major incident reporting.

The initial notification must be submitted within 4 hours of the moment the incident is classified as major, and no later than 24 hours after the firm first became aware of the incident. The intermediate report follows within 72 hours of the initial notification. The final report is due within one month of the intermediate report.

Those deadlines, read in isolation, look achievable. Four hours to submit a notification. Three days to produce an intermediate assessment. A month for the final report.

The timelines and content requirements for these three reports are set in the regulatory technical standards developed by the Joint Committee of the ESAs under the mandate at Article 20 of Regulation (EU) 2022/2554 (CELEX: 32022R2554). Article 20 required the ESAs to submit those draft RTS to the Commission by 17 July 2024. The Commission adopted the incident reporting RTS on 23 October 2024; it was published in the Official Journal on 20 February 2025 as Commission Delegated Regulation (EU) 2025/301 (CELEX: 32025R0301). That adopted instrument is the operative document for any firm implementing its incident reporting process. References in this article to the RTS on major incident reporting refer to that adopted instrument under the Article 20 mandate.

The 4-hour deadline is the one that reveals the design requirement, because it does not start when the firm knows it has a major incident. It starts after the classification decision has been made. The 24-hour limit on classification means that classification must happen first, leaving the 4-hour submission window to run within a total envelope of 24 hours from first awareness.

Consider what must happen within that envelope. The firm must become aware of the incident. The detection layer must surface it with enough information to enable a classification decision. The classification process must run against the RTS criteria. The classification decision must be documented. The content of the initial notification must be assembled. The notification must be submitted through the competent authority’s reporting channel.

A firm that handles any of those steps manually, ad hoc, or sequentially without pre-built process will frequently fail the deadline. Not because the people involved are slow, but because the aggregate of detection latency, classification decision time, content assembly, and submission process takes longer than the window allows when each step depends on the previous one completing before it can start.

What the RTS requires for classification

The classification criteria are the first design constraint. Whether an incident qualifies as major is determined by reference to specific criteria set out in Article 18(1) of Regulation (EU) 2022/2554 (CELEX: 32022R2554) and further specified in the RTS adopted under Article 18(3). Each criterion requires data that must have been captured during the incident.

The classification criteria are:

Client and counterpart impact. An incident affecting a number of clients above a threshold set in the RTS, or affecting specific categories of counterpart, satisfies the impact criterion. This requires the firm to have logged which clients and counterparts were affected and to be able to count or categorise them at the point of classification.

Duration. An incident that causes a service disruption lasting above a defined threshold meets the duration criterion. This requires a logged start time for the disruption and a current or projected end time at the point of classification. A firm that cannot tell how long an incident has been running at the point it is first escalated for classification cannot assess this criterion.

Geographic spread. An incident affecting clients or operations in more than one EU member state triggers specific classification considerations. This requires visibility into the geographic distribution of affected clients or systems at classification time.

Data loss. An incident involving the loss, corruption, or unauthorised access to data meets the data criterion. This requires the firm to have a view, even if preliminary, of whether data integrity or confidentiality has been compromised.

Criticality of affected services. An incident affecting systems or services assessed as critical or important in the firm’s ICT risk framework triggers the criticality criterion. This requires the firm to have a current and accessible map of which services are designated as critical or important.

Reputational impact. Reputational impact is not a standalone classification criterion under Article 18(1). It appears as a secondary element within the client and counterpart impact criterion at Article 18(1)(a), alongside the number and relevance of affected clients and the volume of transactions affected. A structured assessment is still required, but reputational damage is one factor within a broader criterion rather than a separate threshold in its own right.

For most of these criteria, the data required to make the assessment must have been logged before the classification decision can be made. A firm that begins collecting the relevant data after it decides to classify an incident is working in the wrong order.

The data pipeline from detection to classification

The detection layer is the upstream constraint on the entire reporting process. An incident cannot be classified until it has been detected and characterised well enough to apply the RTS criteria. The design question is what characterisation the detection layer must provide, and how quickly.

The minimum characterisation required at detection, to enable a timely classification decision, is: the timestamp of first occurrence or first awareness; the affected systems, services, or functions identified by their place in the critical function register; an initial scope assessment covering the number and type of affected clients or counterparts; and an initial data integrity assessment, even if only “unknown at this stage” with a flag for escalation.

This characterisation is not produced automatically by an alerting system that fires when a threshold is breached. It requires the alerting system to be integrated with the firm’s service catalogue and client data in a way that allows it to produce a structured incident record rather than a raw alert. A security operations centre that receives a high-severity alert and begins investigating from scratch each time has not built the pipeline that DORA’s classification step requires.

The practical architecture that works is one where a high-severity alert automatically populates a structured incident record with the relevant system context, initiates a lookup of affected clients and services against the firm’s data, and routes the record to the individual or team responsible for the classification decision, with the data they need to make it already assembled.

That routing step is also a design choice. The classification decision is a compliance decision, not a security operations decision. It should involve a person who understands the RTS criteria and has authority to make the classification. A classification process that runs through the same escalation chain as the technical incident response will be slower and more variable than one that has a dedicated decision path for the regulatory step.

The content of the initial notification

The initial notification is not a free-form description of what happened. The RTS specifies the content fields that must be completed. These include: the date and time of first detection, the date and time of classification, the type of incident, the affected functions and services, the client impact assessment, the geographic spread, the initial root cause assessment if available, and the remediation or containment measures taken or in progress.

Not all of these fields require precise data at the initial notification stage. The RTS recognises that the initial notification is a point-in-time report under time pressure. But the fields that can be completed from the logged incident record should be completed from it, not reconstructed from memory under time pressure.

The initial notification is also the document that establishes the regulatory timestamp for the incident. A notification that is submitted late, or that understates the scope of the incident at the initial stage and then reveals a larger impact in the intermediate report, will attract scrutiny. Competent authorities assessing the quality of a firm’s incident reporting will look at the progression from initial to intermediate to final report and will examine whether the initial report reflected the information that was available at the time of submission.

A firm that submits a minimal initial notification because its internal data assembly process was not fast enough to populate the full picture has documented its own pipeline failure.

The 72-hour intermediate report

The intermediate report, due within 72 hours of the initial notification, serves a different purpose from the initial notification. Where the initial notification captures the incident at its first-characterisation stage, the intermediate report assesses causes, current impact, and the state of the response.

The RTS content requirements for the intermediate report include: an updated assessment of client and operational impact, a preliminary root cause analysis or at minimum a characterisation of the incident type, a description of the mitigation measures in place, an assessment of whether the incident is contained or ongoing, and any updated information on geographic spread or data impact.

The 72-hour window for the intermediate report is more achievable than the 4-hour window for the initial notification, but it introduces its own design requirement. The intermediate report must be produced during what is typically the most operationally demanding phase of the incident response: the period when technical teams are still working to contain and remediate, and when management attention is divided between the operational problem and the external communication obligation.

The firm’s incident management process must have a dedicated reporting thread that runs in parallel with the technical response. The reporting function’s job during the 72-hour window is to track the incident’s evolution, collect updated data against the RTS fields, and draft the intermediate report without diverting the technical response team from their work.

In practice, this means the reporting function needs: a live view of the incident status from the technical team, structured in terms that map to the RTS content fields; access to updated client impact data as the scope of the incident becomes clearer; and a drafting workflow that produces the report in the required format for the competent authority’s submission system.

The final report

The final report, due within one month of the intermediate report, is the root cause analysis and remediation account. It is the most substantive of the three reports and the one that will be scrutinised most closely by the competent authority in the context of any supervisory follow-up.

The RTS requires the final report to include: a detailed root cause analysis, which must be specific rather than generic; a description of all remediation measures taken; a timeline of the incident from first occurrence through containment through resolution; a revised assessment of client and operational impact; and a statement of the lessons learned and the changes made or planned to the firm’s ICT risk management framework as a result.

The lessons-learned component is the connection back to DORA’s risk management pillar. An incident that resulted in a major ICT incident report is, by definition, a risk materialisation event. DORA requires that the learnings from incidents feed back into the ICT risk management framework. The final report is the document that makes that loop visible to the competent authority.

A final report that describes remediation measures taken and then states generic process improvements has not met this standard. The connection between the specific root cause identified and the specific changes made to the risk framework must be explicit.

The log as the compliance record

Throughout the entire process, from first detection to final report submission, the timestamps and decisions that constitute the process must be logged in a way that is accessible and reviewable.

The log is not just an internal record. It is the compliance evidence that a competent authority reviewing the firm’s incident reporting practices will examine. It should show: the timestamp of first detection, the timestamp of escalation to the classification decision-maker, the timestamp of the classification decision and the outcome, the timestamp of initial notification submission, the timestamp of intermediate report submission, and the timestamp of final report submission.

Any gap between the RTS timelines and the firm’s actual timestamps is visible in this log. A classification decision made 22 hours after first awareness, followed by an initial notification submitted 3.5 hours after classification, shows a firm that was close to its limits on both counts. The same pattern across multiple incidents suggests a structural capacity problem rather than incident-specific difficulty.

The log also captures the data that was available at the time of each classification decision. A firm that classified an incident as non-major and later revised that classification following an investigation should have logged the basis for the initial decision and the basis for the revision. Reclassification without documentation of the original classification rationale is a gap that supervisors will notice.

Building the process before the incident

The operational implication of all of the above is that DORA’s incident reporting requirements cannot be addressed as a response design problem. They are an infrastructure design problem.

The detection layer must produce structured incident records, not raw alerts. The incident records must be populated from the firm’s service catalogue and client data at detection time. The classification decision must have a designated path, a designated decision-maker, and documented criteria. The reporting function must have a live view of incident status and a drafting workflow that produces submissions in the format required by the competent authority’s reporting system. The log must capture timestamps and decision rationale automatically rather than depending on manual entry under time pressure.

None of that infrastructure can be built during a live incident. The four-hour window from classification to initial notification submission is achievable if the upstream steps run well. It is not achievable if any of them are being designed in real time.

For the full DORA compliance framework in which incident reporting sits, including the ICT risk management, testing, and third-party risk pillars, see DORA compliance checklist for financial entities.

For the RTS and ITS structure that governs the detail of DORA’s requirements, including how technical standards interact with the framework regulation, see what are regulatory technical standards and why do they matter more than the regulation itself?.

Forseti monitors DORA implementing guidance, incident reporting RTS developments, and supervisory interpretations continuously, anchored to verified EUR-Lex sources with full CELEX traceability. Start for free.