Sixty-nine percent of chief information security officers in Europe admit they have never tested their incident notification procedure before needing it. Yet Article 23 of the NIS2 Directive is unambiguous: any essential or important entity has 24 hours to send an early warning to the competent national authority after detecting a significant incident. In France, that authority is ANSSI. The window is short. The pressure is intense. And most organisations discover their vulnerability at the worst possible moment: during the incident itself.
In this article, we detail the five operational pitfalls that turn a manageable regulatory obligation into a crisis, compounded by a clear breach of the rules.
The NIS2 framework: a three-stage obligation
Article 23 of NIS2 sets out a three-stage notification structure. First stage: the early warning to the competent authority within 24 hours of detecting a significant incident. This warning may be incomplete. It is not meant to be an exhaustive report, but to inform the regulator that an event is under way. Second stage: the formal notification within 72 hours, with a structured description of the incident, the systems affected and the first measures taken. Third stage: the final report within 30 days, with the root cause analysis, the impact assessment and the remediation actions.
This rhythm is modelled on the DORA framework for the financial sector, now extended to all 18 sectors covered by NIS2. In France, several thousand organisations fall within scope, as essential and important entities, identified by sector or self-declared. Penalties for late or missing notification reach up to EUR 10 million or 2% of worldwide annual turnover for essential entities. An incident qualifies as "significant" where it causes an impact on the availability, integrity, authenticity or confidentiality of networks and information systems.
The challenge is not only technical. It is an organisation's ability to articulate clearly, under pressure, what happened, to whom, when, and with what potential impact, within a timeframe that leaves no room for improvisation.
Pitfall #1: no qualification matrix
The first obstacle is qualifying the incident. NIS2 does not require notifying every incident, only "significant" ones. The Directive sets criteria, but applying them requires an assessment grid established in advance, before any crisis. In the urgency of an active compromise, quickly qualifying "significant versus non-significant" is impossible without a documented framework.
The common mistake: leaving the qualification to the individual discretion of the CISO or the chief information officer on the day. The result: either the organisation over-notifies (alerting ANSSI about minor incidents, which damages its credibility), or it under-notifies (taking on a major legal risk). Good practice: a matrix of thresholds per critical service, co-validated with the head of legal and the data protection officer, updated annually and tested against simulated scenarios.
A concrete example: a transport company subject to NIS2 received a formal recommendation from ANSSI during its first compliance audit in 2025 for lacking a documented qualification procedure, even though it had notified two incidents within the deadlines. The notification had been correct, but the process was informal and not reproducible.
Pitfall #2: an untested notification channel
ANSSI operates an online reporting portal (PRIS, Portail de Renseignement sur les Incidents de Sécurité). This channel is the official route for NIS2 notifications in France. The critical question: how many members of the incident response team know the login credentials? Can they access it at the weekend, at 3 a.m., from a crisis terminal that may itself be compromised?
The primary channel must have a documented fallback channel (a signed email to the official address, the ANSSI on-call number). Testing this channel once a year is not bureaucracy: it is resilience. A 30-minute exercise, once a year, simulating the sending of a test notification in a staging environment, is enough to identify gaps before they cost you dearly.
Pitfall #3: waiting until you have all the answers before notifying
This is the most frequent and most costly pitfall. In the first hours of an incident, information is partial, uncertain and sometimes contradictory. The natural instinct is to wait for a full picture before notifying, so as not to "raise unnecessary alarm" or "pass on incorrect information".
NIS2 anticipated precisely this situation. The 24-hour early warning may be incomplete. It must state that the incident is under way, its likely nature, and the first measures taken. That is all. The regulator does not expect a full forensic analysis within this deadline: it expects to be informed that you are aware of the situation and acting on it.
A timing error turns a late notification into a clear breach. An early warning sent at H+20 with 30% of the information complies. The same warning sent at H+26 with 90% of the information does not.
Pitfall #4: a decision chain that is too long
A NIS2 notification commits the organisation towards the national authority. In most medium-sized or large structures, this triggers a reflex of multi-level validation: chief executive, legal department, CISO, communications director, and sometimes the board. If each validation takes two hours, the 24-hour deadline is missed before the notification has even been drafted.
The operational solution: a formal mandate established in advance, signed outside any crisis, empowering the CISO to issue the early warning without prior validation from the executive board. This authorisation covers only the 24-hour alert: the 72-hour notification and the 30-day report can follow the usual validation route. This mandate must be documented, known to all parties, and reviewed annually.
Pitfall #5: neglecting contractual obligations with third parties
If your cloud provider, your outsourcer or your software vendor is involved in an incident, whether as an attack vector or as an affected system, the qualification and the notification remain your responsibility, not theirs. NIS2 does not transfer the notification burden to subcontractors. Your regulatory obligation is independent of that of your provider.
The direct consequence: your contracts with critical providers must include clauses requiring accelerated internal notification, typically within less than 4 hours of detecting an incident involving them. Without this clause, you risk learning that an incident concerns you at H+18: too late to meet the 24-hour deadline. Article 21 of NIS2 explicitly requires that security measures apply to the supply chain, including contractual arrangements.
During a simulated crisis exercise held in France in the first quarter of 2026 with mid-sized NIS2 entities, 6 organisations out of 10 identified the absence of an accelerated notification clause in their MSP contracts as the main risk factor for missing the regulatory deadline.
Assessing the maturity of your arrangements
Three questions help you quickly diagnose the most critical gaps. First question: does your team have a documented qualification matrix that has been tested against scenarios? Second question: can your CISO access the ANSSI portal at 3 a.m. from a backup terminal, with an identified fallback channel? Third question: do your provider contracts include an internal notification clause within 4 hours?
If any of these answers is "no" or "I don't know", the regulatory risk is real and immediate. Presidio includes an incident management module compliant with NIS2: qualification guided by service criticality, a timestamped and immutable notification log, and pre-structured report templates for the 24-hour, 72-hour and 30-day stages. To assess your current arrangements, contact our team: we offer a 45-minute diagnostic focused on your notification procedure. Also read: NIS2: preparing your maturity audit in 90 days.
Conclusion
NIS2 does not penalise organisations for being the victims of incidents. It penalises those that lack the means to respond clearly and within the deadlines. The five pitfalls described share a common feature: they are all avoidable through decisions taken in advance, well before the crisis. The qualification matrix, the tested channel, the early warning sent in advance, the formal notification mandate, and the accelerated contractual clauses together form your regulatory emergency infrastructure.
Organisations that come through major incidents well do not have fewer breaches than others: they have more preparation. And in your context: at what exact time could your team send the first notification tonight, if a significant incident were detected at midnight?