Back to blog

DORA incident notification deadlines: 4h, 24h, and beyond — the countdown

Initial notification, intermediate report, final report: how the DORA countdown works for major incidents, and why classification matters.

By Arthur Chédeville··Read time : 6 min·For Payment institutions, e-money, CISO
DORA incident notification deadlines

When it comes to incidents, DORA leaves no room for improvisation. As soon as an ICT-related incident is classified as major, a clock starts, and the regulator expects notifications at fixed deadlines. And it is precisely this pillar — incident management — that the ACPR has placed at the top of its control priorities for 2026. Understanding the countdown is therefore not a luxury: it is a first-order requirement.

The starting point: classification, not detection

This is the subtlety with the heaviest consequences. The deadline does not start from the moment you detect an incident, but from the moment you classify it as major. And you must classify quickly: DORA also frames this upstream deadline.

In practice, in France, the entity must notify a major incident to the ACPR within 4 hours of classifying it as major — and, in any case, no later than 24 hours after detection. In other words, you cannot indefinitely delay classification to push back notification: the 24-hour-from-detection limit closes that door.

The three notification stages

The reporting is structured in three distinct steps:

  1. The initial notification. Within 4 hours of classification (and no later than 24 hours after detection). This is not a complete report: it is an alert. It gives the basic facts — when, where, what type of incident, which services affected, preliminary impact, a point of contact. The important message: it is better to notify with partial information within the deadline than to wait for a complete picture.

  2. The intermediate report. As the situation evolves, the entity submits an update: preliminary root cause, containment timeline, refined impact data, third parties involved. This is when the initial picture is completed and corrected.

  3. The final report. Once root-cause analysis is complete and corrective measures are underway: full root-cause analysis, identified control gap, corrective actions, lessons learned and forward-looking actions (for example, including the scenario in the next testing programme).

The mistakes to avoid

The regulator's feedback points to several recurring pitfalls:

  • Waiting until you have all the information. The initial notification is an alert, not an investigation. Delaying to « be complete » misses the deadline.
  • Under-classifying to avoid notifying. An understandable temptation, but a dangerous one: if the regulator later discovers that an incident should have been classified as major, the consequences are far heavier than a « precautionary » notification.
  • Neglecting compensating measures. An incident must be classified independently of any compensating measures put in place after detection. You do not « catch up » a classification by correcting afterwards.
  • Forgetting incidents at a provider. An outage at your cloud host that affects your services is an incident within the meaning of DORA — and you are the one who notifies.

The special case of payments

For credit institutions, payment institutions, account information service providers and e-money institutions, DORA additionally requires the notification of payment-related operational or security incidents (Article 23). These players therefore have a dual scope of vigilance: major ICT incidents and payment incidents.

Interaction with GDPR

If the incident involves a personal-data breach, a double notification applies: DORA to the ACPR or AMF, GDPR to the CNIL. Both can be carried out in parallel, but their contents differ: GDPR focuses on the impact on data subjects, DORA on the operational impact and service resilience.

Why a tooled process changes everything

Meeting these deadlines means being able, mid-crisis, to classify the incident, identify the impacted functions and assets, retrieve the third parties involved, and produce the notification in the right format. Entities with a well-drilled process and ready templates gain decisive time. The others discover the regulator's forms at the worst possible moment.

Where Axenia fits in. Axenia structures the regulatory path of each incident: classification, notification deadlines displayed, impacted assets and functions, third parties involved, timeline — and prepares the declaration elements. The countdown becomes a controlled process rather than a race against the clock.


This article is educational in purpose and does not constitute legal advice. The precise deadlines and procedures are set out in the official texts (DORA regulation, delegated and implementing regulations) and your competent authority's FAQ. Sensitive topic: in the event of a real incident, rely on your validated internal procedures.

See how Axenia drives your incident notifications. Book a demo →