Most GRC directors know the GDPR's 72-hour deadline for notifying a personal data breach to their supervisory authority. A growing number now know the NIS2 obligation to send an early warning to ANSSI within 24 hours of a significant incident. What many still do not realise: when a security incident involves both personal data and the systems of an essential or important entity, the two regimes apply simultaneously, with different authorities, different formats, and timelines that overlap without cancelling each other out. ENISA estimates that more than 60% of entities within NIS2's scope process sensitive personal data. For these organisations, the question is not whether they will one day have to manage two notifications. It is whether they are prepared for it.
Two regimes, two logics: neither suspends the other
The GDPR (Article 33) requires notifying the competent supervisory authority, the CNIL in France, within 72 hours of becoming aware of a personal data breach "likely to result in a risk to the rights and freedoms of natural persons". The notification must describe the nature of the breach, the categories of data concerned, the approximate number of individuals affected, and the measures taken or envisaged.
NIS2 (Article 23) sets a different timeline, and a more demanding one for the first step. The essential or important entity must send an early warning to the competent national authority (ANSSI in France) within 24 hours of detecting a significant incident. This early warning is not a full report: it signals the existence of the incident, indicates whether it is suspected to be of malicious origin, and specifies its potential cross-border impact. The intermediate report follows at 72 hours, with a more complete assessment. The final report is due within a month of closing the incident.
What makes this overlap hard to manage in practice: both regimes start at the same moment. The "awareness" (GDPR) and the "detection" (NIS2) are often identical on an operational level. Your incident response team therefore has 24 hours for ANSSI and 72 hours for the CNIL at the same time. These are not two independent deadlines: they are two clocks running simultaneously, towards different recipients, with different content.
The four most common mistakes in real situations
Prioritising technical handling over regulatory notification. The natural reaction to an active incident is to concentrate all resources on containment and remediation. The notification deadline then slips into the background. Result: at T+36, your team comes out of the containment phase and realises that the NIS2 alert should have been sent at T+24 and that the CNIL notification is due within 36 hours. Technical handling does not suspend any regulatory deadline: one obligation does not wait for the other.
Treating the two notifications as a single document. A practice regularly observed: copying and pasting the same incident report for both the CNIL and ANSSI. The two authorities do not expect the same information. The CNIL wants to understand the impact on natural persons: who is affected, which data, what risk to their rights. ANSSI wants to understand the impact on system security: the nature of the attack, the suspected entry vector, the risk of cross-border propagation. A single report structurally satisfies neither.
Forgetting that the NIS2 early warning is intentionally incomplete. Article 23.1 explicitly states that the 24-hour early warning does not need to be a complete analysis. It must be sent as soon as the organisation has an "initial awareness" of the incident, not once it understands its full extent. Some organisations delay the NIS2 alert while waiting for a full picture of the incident. This is a misreading: NIS2 expects a rapid partial notification, not a late exhaustive report. The full analysis comes with the 72-hour report.
No clear RACI between the security team and the DPO. In most incidents that trigger both regimes, technical incident handling is led by the CISO or the SOC. GDPR notification falls to the DPO. NIS2 does not always have a designated owner: this is often a blind spot. Result: at T+18, nobody has yet decided whether the incident falls under the GDPR, NIS2, or both. This undecided question blocks both notification workflows simultaneously.
The structure of the first 48 hours
A security incident involving personal data in a NIS2 entity requires a four-stage structure:
T+0 to T+4: incident classification. The first decision is not technical, it is regulatory. Three questions: does the incident involve personal data? Is the entity within NIS2's scope? Does the incident reach the NIS2 threshold of "significant"? The CISO, the DPO and, if available, the compliance lead must answer these three questions together within the first four hours. This answer decides whether one, two or no regulatory notifications must be triggered, and how quickly.
T+4 to T+24: NIS2 early warning. If the incident is within NIS2 scope, an early warning must be sent to ANSSI before T+24. Reminder: this warning is intentionally minimal. It must state the nature of the incident (cyberattack, failure, unauthorised access), whether it is suspected to be of malicious origin, and whether there is a potential cross-border impact. A template pre-approved by your legal counsel considerably speeds up this step. Without a template, drafting at T+18 under the pressure of an active incident takes two to three times longer than expected.
T+24 to T+72: GDPR assessment and NIS2 intermediate report. This is the busiest window. Simultaneously, your DPO assesses the risk to the rights and freedoms of individuals (CNIL notification is not automatic: it depends on a risk assessment), and your team drafts the intermediate NIS2 report (72 hours) with the elements available on the nature of the incident, its scope and its vectors. If the GDPR assessment concludes there is a risk to individuals, the CNIL notification must be sent before T+72. These two actions cannot be sequential: they must run in parallel.
T+72 and beyond: closure and NIS2 final report. The CNIL may need additional information in the following days. The final NIS2 report is expected within a month of closing the incident, with a full analysis of causes, scope and corrective measures. A record of all exchanges (dates, recipients, content) must be kept in the incident register to respond to any inspection by either authority.
What you can prepare before the next incident
Three elements reduce the chaos of the first 48 hours: an incident classification decision tree (personal data? NIS2 scope? significant?), an explicit RACI naming the people responsible for each regulatory notification (not functions: people), and two notification templates pre-validated by your DPO and legal counsel: one for ANSSI (early warning), one for the CNIL (initial notification). These templates should be reviewed annually and tested during a simulation exercise. Presidio integrates these notification workflows into its incident management module, with NIS2 and GDPR deadlines configured as automatic alerts as soon as an incident is created. Learn more →
Conclusion
One incident, two regimes, one team under pressure: this is the scenario most organisations in NIS2 scope have not yet simulated. The GDPR-NIS2 overlap does not produce a legal conflict: the two regimes are independent and complementary. It produces an operational challenge: how to coordinate two notification workflows towards two different authorities, with different deadlines, without slowing the handling of the incident in progress?
Organisations that get through this scenario with the least friction have prepared two things: a decision tree that settles within an hour whether an incident falls under the GDPR, NIS2, or both, and pre-validated notification templates that allow each lead to work in parallel without waiting for the other.
In your organisation, who decides at T+2 hours that an incident is within GDPR scope, NIS2 scope, or both? And has that decision already been tested?
Also read: NIS2: the operational pitfalls of 24-hour incident notification and NIS2 eighteen months on: running your maturity audit in 90 days.