RGPD et NIS2 : un incident, deux notifications — comment tenir les délais sans improviser

Quand un incident de sécurité implique des données personnelles, vous êtes potentiellement soumis à deux régimes de notification distincts : RGPD (72 h à la CNIL) et NIS2 (24 h à l'ANSSI). La superposition est méconnue — et elle coûte cher à ceux qui la découvrent en plein incident.

Poste de travail affichant un terminal de réponse à incident

La majorité des Directeurs GRC connaissent le délai de 72 heures du RGPD pour notifier une violation de données personnelles à leur autorité de contrôle. Une part croissante connaît désormais l'obligation NIS2 de transmettre une alerte précoce à l'ANSSI dans les 24 heures suivant un incident significatif. Ce que beaucoup ignorent encore : quand un incident de sécurité implique à la fois des données personnelles et des systèmes d'une entité essentielle ou importante, les deux régimes s'appliquent simultanément — avec des autorités différentes, des formats différents, et des calendriers qui se chevauchent sans s'annuler. L'ENISA estime que plus de 60 % des entités dans le scope NIS2 traitent des données personnelles à caractère sensible. Pour ces organisations, la question n'est pas de savoir si elles devront gérer deux notifications un jour. C'est de savoir si elles y sont préparées.

Deux régimes, deux logiques — et aucun ne suspend l'autre

Le RGPD (Article 33) impose de notifier l'autorité de contrôle compétente — la CNIL en France — dans les 72 heures suivant la prise de connaissance d'une violation de données à caractère personnel « susceptible d'engendrer un risque pour les droits et libertés des personnes physiques ». La notification doit décrire la nature de la violation, les catégories de données concernées, le nombre approximatif de personnes affectées, et les mesures prises ou envisagées.

NIS2 (Article 23) impose un calendrier différent — et plus contraignant sur la première étape. L'entité essentielle ou importante doit transmettre une alerte précoce à l'autorité compétente nationale (ANSSI en France) dans les 24 heures suivant la détection d'un incident significatif. Cette alerte précoce n'est pas un rapport complet : elle signale l'existence de l'incident, indique s'il est suspecté d'être d'origine malveillante, et précise son impact cross-frontalier potentiel. Le rapport intermédiaire suit à 72 heures, avec une évaluation plus complète. Le rapport final arrive dans le mois suivant la clôture de l'incident.

Ce qui rend cette superposition difficile à gérer en pratique : les deux régimes démarrent au même moment — la « prise de connaissance » (RGPD) et la « détection » (NIS2) sont souvent identiques sur le plan opérationnel. Votre équipe de réponse aux incidents dispose donc simultanément de 24 heures pour l'ANSSI et de 72 heures pour la CNIL. Ce ne sont pas deux délais indépendants : ce sont deux horloges qui tournent en même temps, vers des destinataires différents, avec des contenus différents.

Les quatre erreurs les plus fréquentes en situation réelle

Prioriser la gestion technique au détriment de la notification réglementaire. La réaction naturelle face à un incident actif est de concentrer toutes les ressources sur la containment et la remédiation. Le délai de notification passe alors au second plan. Résultat : à T+36, votre équipe sort de la phase de containment et réalise que l'alerte NIS2 aurait dû être envoyée à T+24 et que la notification CNIL est due dans 36 heures. La gestion technique ne suspend aucun délai réglementaire — une obligation n'attend pas l'autre.

Traiter les deux notifications comme un seul document. Une pratique observée régulièrement : copier-coller le même rapport d'incident à destination de la CNIL et de l'ANSSI. Les deux autorités n'attendent pas les mêmes informations. La CNIL veut comprendre l'impact sur les personnes physiques : qui est affecté, quelles données, quel risque pour leurs droits. L'ANSSI veut comprendre l'impact sur la sécurité des systèmes : quelle est la nature de l'attaque, quel est le vecteur d'entrée suspecté, y a-t-il un risque de propagation transfrontalière. Un rapport unique ne satisfait structurellement aucun des deux.

Oublier que l'alerte précoce NIS2 est intentionnellement incomplète. L'Article 23.1 précise explicitement que l'alerte précoce à 24 heures ne nécessite pas d'être une analyse complète. Elle doit être transmise dès que l'organisation a une « connaissance initiale » de l'incident — pas dès qu'elle en comprend toute l'étendue. Des organisations retardent l'alerte NIS2 en attendant d'avoir une image complète de l'incident. C'est une erreur d'interprétation : NIS2 attend une notification partielle rapide, pas un rapport exhaustif tardif. L'analyse complète vient au rapport de 72 heures.

Absence de RACI clair entre équipe sécurité et DPO. Dans la majorité des incidents qui déclenchent les deux régimes, la gestion de l'incident technique est pilotée par le RSSI ou le SOC. La notification RGPD relève du DPO. NIS2 n'a pas toujours de pilote désigné — c'est souvent un angle mort. Résultat : à T+18, personne n'a encore décidé si l'incident relève du RGPD, de NIS2 ou des deux. Cette décision, non tranchée, bloque les deux workflows de notification simultanément.

La structure des 48 premières heures

Un incident de sécurité impliquant des données personnelles dans une entité NIS2 exige une structure en quatre temps :

T+0 à T+4 — Classification de l'incident. La première décision n'est pas technique, elle est réglementaire. Trois questions : l'incident implique-t-il des données à caractère personnel ? L'entité est-elle dans le scope NIS2 ? L'incident atteint-il le seuil de « significatif » au sens NIS2 ? Le RSSI, le DPO et, si disponible, le responsable conformité doivent répondre à ces trois questions ensemble dans les quatre premières heures. C'est cette réponse qui décide si une, deux, ou aucune notification réglementaire doit être déclenchée — et à quelle vitesse.

T+4 à T+24 — Alerte précoce NIS2. Si l'incident est dans le scope NIS2, une alerte précoce doit être transmise à l'ANSSI avant T+24. Rappel : cette alerte est intentionnellement minimale. Elle doit indiquer la nature de l'incident (cyberattaque, défaillance, accès non autorisé), s'il est suspecté d'être d'origine malveillante, et s'il y a un impact cross-frontalier potentiel. Un template pré-approuvé par votre conseil juridique accélère considérablement cette étape. Sans template, l'exercice de rédaction à T+18 sous pression de l'incident actif prend deux à trois fois plus longtemps que prévu.

T+24 à T+72 — Évaluation RGPD et rapport NIS2 intermédiaire. C'est la fenêtre la plus chargée. Simultanément : votre DPO évalue le risque pour les droits et libertés des personnes (la notification CNIL n'est pas automatique — elle dépend d'une évaluation de risque) ; votre équipe rédige le rapport NIS2 intermédiaire (72 heures) avec les éléments disponibles sur la nature de l'incident, son étendue et ses vecteurs. Si l'évaluation RGPD conclut à un risque pour les personnes, la notification CNIL doit partir avant T+72. Ces deux actions ne peuvent pas être séquentielles — elles doivent être parallèles.

T+72 et au-delà — Clôture et rapport final NIS2. La CNIL peut avoir besoin d'informations complémentaires dans les jours suivants. Le rapport final NIS2 est attendu dans le mois suivant la clôture de l'incident, avec une analyse complète des causes, de l'étendue et des mesures correctives. Une trace de l'ensemble des échanges — dates, destinataires, contenus — doit être conservée dans le registre des incidents pour répondre aux éventuelles inspections des deux autorités.

Ce que vous pouvez préparer avant le prochain incident

Trois éléments réduisent le chaos des premières 48 heures : un arbre de décision de classification des incidents (personnel data? NIS2 scope? significant?), un RACI explicite avec le nom des personnes responsables de chaque notification réglementaire — pas les fonctions, les personnes — et deux templates de notification pré-validés par votre DPO et votre conseil juridique : un pour l'ANSSI (alerte précoce), un pour la CNIL (notification initiale). Ces templates doivent être revus annuellement et testés lors d'un exercice de simulation. Presidio intègre ces workflows de notification dans son module de gestion des incidents, avec les délais NIS2 et RGPD configurés comme alertes automatiques dès la création d'un incident. En savoir plus →

Conclusion

Un incident, deux régimes, une équipe sous pression : c'est le scénario que la majorité des organisations dans le scope NIS2 n'a pas encore simulé. La superposition RGPD-NIS2 ne produit pas de conflit juridique — les deux régimes sont indépendants et complémentaires. Elle produit un défi opérationnel : comment coordonner deux workflows de notification vers deux autorités différentes, avec des délais différents, sans ralentir la gestion de l'incident en cours ?

Les organisations qui traversent ce scénario avec le moins de friction ont préparé deux choses : un arbre de décision qui tranche en moins d'une heure si un incident relève du RGPD, de NIS2, ou des deux — et des templates de notification pré-validés qui permettent à chaque pilote de travailler en parallèle sans attendre l'autre.

Dans votre organisation, qui décide à T+2 h qu'un incident est dans le scope RGPD, NIS2, ou les deux ? Et cette décision a-t-elle déjà été testée ?

Lire aussi : NIS2 — les pièges opérationnels de la notification d'incident en 24 hNIS2 dix-huit mois après : piloter votre audit de maturité en 90 jours.

Un projet ? Une question ?

Nous contacter →