The 4-Hour Clock: DORA Major Incident Reporting Step by Step

A critical system goes down at 09:15. By 13:15 your regulator expects to know about it. That is the reality of DORA major incident reporting.

Most organisations understand that DORA has incident reporting requirements. Fewer understand exactly how the timeline works, what triggers it, what has to be in each report, and what happens if you miss a deadline. This article works through each stage clearly.

What Counts as a Major Incident

Not every system outage is a major incident under DORA. The regulation defines classification criteria in Article 18, and the European Banking Authority has published a regulatory technical standard that sets out how to apply those criteria in practice.

The classification criteria cover several dimensions. The number of clients or counterparts affected matters. So does the duration of the disruption, the geographic spread, the nature and volume of any data loss, the criticality of the affected services, and the reputational impact on your organisation. Each criterion has a threshold. If your incident crosses one or more of those thresholds, it qualifies as major.

The important point is that classification is a decision your organisation makes. There is no external authority that classifies incidents for you. Your internal process must include a clear classification step, carried out promptly after the incident is detected, using documented criteria that align with the RTS thresholds. That classification decision is what starts the clock.

The Three-Stage Reporting Process

DORA Article 19 sets out a three-stage reporting structure. Each stage has its own timeline and its own content requirements.

Stage One: Initial Notification — Within 4 Hours

Once you classify an incident as major, you have four hours to send an initial notification to your competent authority.

This is not a full report. It is an alert. The purpose is to make your regulator aware that a significant incident is in progress. The content required at this stage is limited: who you are, when the incident was detected, when you classified it as major, what happened in broad terms, which systems or services are affected, and what the current status is.

The initial notification does not need to be perfect. It does not need root cause analysis or a full impact assessment. What it needs to be is timely and complete enough for your regulator to understand the basic situation. A prompt but brief notification is better than a late but detailed one.

One practical note: the four-hour window runs from classification, not from the moment the incident first occurred. But classification must happen quickly after detection. Deliberately slow classification is not a way to extend the notification deadline. Regulators are aware of that approach and view it negatively.

Stage Two: Intermediate Report — Within 72 Hours

Within 72 hours of the initial notification, you must submit an intermediate report. This provides significantly more detail.

The intermediate report should cover the current status of the incident, the scope and scale of the impact, the actions your organisation has taken to contain and investigate, any effect on clients or counterparts, and your current assessment of how long resolution will take.

If the incident is still developing when the 72-hour deadline arrives, you send what you know. You may need to submit multiple intermediate reports as the situation evolves. The regulation allows for this. What it does not allow is silence.

Stage Three: Final Report — Within One Month

After the incident is resolved, you have one month to submit a final report. If the incident has not been resolved within one month of the intermediate report deadline, you still submit a final report at that point, with a note that the matter remains ongoing.

The final report is the most detailed of the three. It should include a full timeline of the incident, the root cause or causes, the full extent of the impact on clients and services, the actions taken at each stage, and the remediation measures put in place to prevent recurrence. This is the document that regulators will assess most carefully when reviewing your incident management capability.

Who Receives the Reports

Your reports go to your competent authority, which is the regulatory body responsible for supervising your organisation under DORA.

For most financial entities, that is the national financial supervisor in the country where you are authorised. In Norway it is Finanstilsynet. In Germany it is BaFin. In Ireland it is the Central Bank of Ireland. In the Netherlands it is DNB or AFM depending on the entity type.

For significant credit institutions under direct ECB supervision, the ECB is involved as well. The EBA, ESMA, and EIOPA receive aggregated and anonymised incident data but your reports go to your primary supervisor, not directly to the EU-level authorities.

Know your regulator's submission process before you need it. Some competent authorities have online portals. Others accept structured email submissions. Finding out which applies to you during an active incident is not a situation you want to be in.

What the Reports Must Contain

The EBA has published implementing technical standards on incident reporting formats, referenced as EBA ITS 2024/2956. These standards define the exact fields required at each reporting stage.

The initial notification fields include: a unique incident identifier, the entity's name and LEI, the date and time the incident was first detected, the date and time of classification as major, a description of the incident and its nature, the systems and services affected, and a brief summary of the current impact.

Do not try to write these in a Word document from scratch under time pressure. The ITS format is structured and specific. Prepare a template in advance. Better still, use a system that generates the structured report in the correct format automatically, so that the content fields are populated from the data you have already recorded in your incident log.

The Most Common Mistakes

Three mistakes appear repeatedly in how organisations approach DORA incident reporting.

Waiting to classify. When an incident is severe, there is a natural instinct to wait and see whether it resolves before treating it as major. That instinct is understandable but it creates risk. If the incident does qualify as major, every hour spent waiting to classify is an hour taken from the four-hour notification window. Build a clear classification decision point into your incident response process, ideally within the first 30 to 60 minutes of detection. Confusing detection time and classification time. The four hours run from classification, not from when the incident started. But that is not a reason to delay classification. Regulators expect the time between detection and classification to be short. An incident detected at 09:15 and classified at 12:45 raises questions, even if the notification goes out at 16:30 and technically meets the four-hour window from classification. Sending an incomplete initial notification. Some teams hold the initial notification until they have more information, wanting to avoid sending something that turns out to be inaccurate. This is the wrong trade-off. The initial notification is explicitly designed to be a partial report. Send what you know when the deadline arrives. You can correct and expand on it in the intermediate report.

How to Be Ready Before It Happens

The organisations that handle DORA incident reporting well are the ones that built the process before they needed it.

Assign a named incident response owner. This person is responsible for making the classification decision and for ensuring notifications go out on time. It should not be a committee decision under time pressure.

Document your classification criteria and align them with the RTS thresholds. Your legal or compliance team should review this document. It should be accessible to whoever is managing the incident, not buried in a policy handbook.

Build the initial notification template in advance. Know exactly what fields it requires and how you will populate them from your incident log.

Test the process at least once a year. Run a tabletop exercise where a simulated incident forces your team to classify, prepare the initial notification, and identify the submission route for your competent authority.

DORA GRC includes an incident register where you can log incidents, track classification decisions, and generate ITS-structured reports in the correct format. When an incident is classified as major, the system records the timestamp and tracks the reporting deadlines automatically, so your team always knows how much time is left at each stage.

The Preparation Pays Off

The four-hour deadline sounds tight. It is. But it becomes manageable when the classification process is clear and the notification template is already prepared.

The organisations that struggle with DORA incident reporting are usually the ones that try to build the process while the incident is happening. Writing a notification template during an active outage, looking up your regulator's submission portal under pressure, debating whether an incident qualifies as major while the impact is growing — none of that has to happen if the groundwork is in place.

The regulation expects you to be prepared. The reporting requirements are demanding precisely because regulators want to know that financial entities take incident response seriously, not just incident recovery. The four-hour clock is a test of your preparation as much as a test of your response.

For a full compliance readiness check across all five DORA pillars, take the free DORA readiness assessment.