72-hour incident notification: GDPR, NIS2 and DORA compared

The day a serious incident occurs, the clock starts ticking in several directions at once. Incident notification is one of the obligations where the regulatory overlap is most felt. The GDPR, NIS2 and DORA impose different deadlines and recipients on, very often, the same event. Without a single process, that day becomes chaos.

Three regulations, three clocks

The GDPR requires notifying the supervisory authority of a personal data breach. The limit is 72 hours from becoming aware of it. NIS2 imposes a much stricter early warning: 24 hours for significant incidents, with a more detailed report afterwards. And the DORA regulation adds, in the financial sector, its own deadlines for major ICT-related incidents.

The problem is obvious. The same cyberattack that compromises personal data at a financial institution can trigger all three obligations at once. Each has its own deadline and recipient.

Comparison of deadlines and recipients

GDPR

72 hours to notify the data protection authority. You must also inform those affected if there is a high risk to their rights. The focus is personal data.

NIS2

Early warning in 24 hours, notification in 72 hours and a final report afterwards. All go to the CSIRT or competent authority. The focus is the impact on the essential service.

DORA

Its own deadlines for major ICT-related incidents, with notification to the competent financial authority. The focus is the operational resilience of the financial system.

How to design a single notification process

The solution is not to have three procedures, but one well-designed one. I define a single flow of detection, classification and escalation. Depending on the type of incident, it automatically triggers the notifications required by each framework. That logic of one process covering several regulations is exactly what I have built into the compliance tool I develop. Coordinating three clocks by hand under pressure is a recipe for non-compliance.

The key is to classify the incident well from the very first minute. Knowing which dimensions it affects determines which clocks start.

The mistake of having three separate processes

The failing I come across most often in organisations is keeping three independent notification procedures. One for data protection, one for NIS2 and one for DORA. On paper it looks tidy. However, real incidents happen at three in the morning. Then no one knows which clock runs first or who alerts whom. The result is missed deadlines and penalties that could have been avoided. That is why I advocate a single detection and classification process. Once activated, it triggers in parallel the notifications required by the nature of the incident.

The key is in the triage phase. In the first few minutes you have to answer three questions: are personal data affected? is an essential service compromised? is it a financial institution under DORA? The answers determine which clocks start. That decision must be protocolised, not improvised. It makes the difference between meeting the deadlines and being left out of the game.

The supply chain complicates the deadlines

A nuance many companies overlook is that the incident may not happen at your own premises, but at a supplier’s. If a service you depend on suffers a breach, your notification obligations may still be triggered. The clock does not stop while you wait for your supplier to inform you. That is why it is wise to require rapid alerts by contract. You should also review how third-party risk is assessed. I develop that topic in my article on NIS2 and the supply chain.

My practical recommendation is to map, before anything happens, which suppliers could trigger a notification obligation. Then agree with them on alert channels and timings. When the incident arrives, that groundwork saves critical hours that, with a 72-hour clock running, are worth gold.

Fundamentally, incident notification is not a bureaucratic formality: it is the acid test of your entire resilience strategy. An organisation that notifies well has rehearsed. It knows who decides and has the contacts to hand. That maturity is not improvised on the day of the attack. It is built beforehand, with clear procedures and regular drills.

The key to meeting such a tight deadline is not rushing when the incident arrives. It is having rehearsed beforehand. In the teams I work with, I organise regular drills. We practise who decides that something is notifiable, who drafts the communication and who sends it. Those rehearsals reveal the real bottlenecks —an unreachable owner, a template that did not exist— long before they truly count. When the real incident arrives, the team does not improvise. It executes a process it already knows, and that is where the deadline is won or lost.

Many of the incidents that have to be notified do not originate at home. They start at a supplier. That is why managing the 72-hour deadline is closely tied to how you control your third parties, a topic I develop in my article on NIS2 and supplier assessment. If a critical supplier takes days to alert you to a breach, your regulatory clock has already started. It runs without your knowing it.

Conclusion: rehearse before it happens

Incident notification is not improvised. A single, documented process, rehearsed with drills, lets you respond sensibly when all the clocks are running at once. I have seen how that preparation makes the difference between professional management and a crisis within the crisis.

Frequently asked questions about incident notification