Délais de notification d’incident NIS2 RGPD DORA

Un délai réglementaire ne commence pas quand l’équipe a fini l’investigation, mais quand l’organisation a connaissance d’éléments suffisants pour soupçonner un incident qualifiable. Attendre une cause racine certaine est l’erreur la plus coûteuse : le régulateur attend un signalement progressif, pas une autopsie parfaite.

→ Lire l’explication complète de la marmotte

NIS2, RGPD et DORA : trois horloges distinctes

La directive NIS2 (Network and Information Security 2) impose aux entités essentielles et importantes de notifier les incidents significatifs à l’autorité compétente ou à l’équipe de réponse nationale désignée par la transposition nationale. Le mécanisme européen prévoit trois jalons :

une alerte précoce dans les 24 heures suivant la connaissance de l’incident significatif ;
une notification formelle dans les 72 heures ;
un rapport final au plus tard un mois après cette notification, ou un rapport d’avancement si l’incident n’est pas encore résolu.

L’alerte précoce indique notamment si l’incident semble résulter d’actes malveillants et s’il peut avoir un effet transfrontière. La notification à 72 heures enrichit le dossier : évaluation initiale de la gravité, indicateurs de compromission quand ils sont disponibles, impact sur les services et premières mesures de réduction du risque. Le rapport final documente les causes, les conséquences et les actions correctrices.

Le Règlement général sur la protection des données, ou RGPD, utilise une autre logique. Une violation de données à caractère personnel doit être notifiée à l’autorité de contrôle dans les 72 heures après en avoir pris connaissance lorsqu’elle est susceptible d’engendrer un risque pour les droits et libertés des personnes. Si le risque est élevé, les personnes concernées doivent aussi être informées sans délai injustifié, sauf exception applicable, par exemple lorsque les données rendues indisponibles sont effectivement illisibles pour un attaquant.

DORA (Digital Operational Resilience Act) vise les entités financières et leurs prestataires concernés. Il impose un signalement des incidents majeurs liés aux technologies de l’information et de la communication. Les délais opérationnels prévus par les normes techniques sont plus serrés que les réflexes hérités du RGPD : notification initiale dès la classification de l’incident, au plus tard dans les quatre heures ouvrées suivant cette classification et dans les 24 heures suivant la prise de connaissance, rapport intermédiaire dans les 72 heures, puis rapport final dans le mois. Une astreinte qui ne peut pas classifier un incident hors horaires ouvrés ne possède pas une procédure DORA, seulement un document décoratif.

Ces régimes peuvent se cumuler. Une indisponibilité par rançongiciel affectant un service financier et exposant des données personnelles peut déclencher DORA, RGPD, NIS2 selon le statut de l’entité, et des obligations contractuelles. Un ticket unique ne suffit pas à démontrer que chaque autorité a reçu le bon contenu au bon moment.

La gouvernance de la sécurité doit donc maintenir une matrice d’applicabilité par entité juridique, service, autorité compétente et type de donnée. Cette matrice ne relève pas du juriste isolé ni du centre opérationnel isolé : elle dépend de l’architecture réelle, des périmètres d’exploitation et des flux de données.

Qualification de l’incident et démarrage du compteur

Le compromis central est brutal : notifier tôt réduit le risque réglementaire et accélère la coordination externe, mais augmente le risque de transmettre une analyse incomplète. La recommandation est de notifier tôt avec un niveau de confiance explicite, puis de corriger. Cette position vaut à condition de disposer d’un canal approuvé, d’un modèle de notification et d’une chaîne de validation joignable à toute heure.

La date pertinente doit être horodatée : première détection, premier signal crédible, première qualification, décision de notification, transmission effective et accusé de réception. Ces événements doivent être conservés dans un système dont les journaux sont synchronisés sur une source de temps fiable. Un export manuel d’outil de ticketing réalisé quatre jours plus tard ne prouve pas grand-chose, hormis l’existence d’un tableur courageux.

La « connaissance » ne se confond pas avec la confirmation forensic. Une alerte isolée et non corroborée peut ne pas suffire. En revanche, un compte privilégié utilisé depuis une localisation anormale, suivi d’exfiltration visible dans les journaux de proxy, constitue un faisceau d’indices exploitable. L’enquête peut préciser le périmètre ; elle ne suspend pas l’horloge.

Pour NIS2, l’incident significatif est notamment celui qui cause ou peut causer une perturbation opérationnelle grave, affecte d’autres personnes physiques ou morales, ou cause ou peut causer des préjudices matériels ou immatériels considérables. Pour le RGPD, l’analyse porte sur le risque pour les personnes, pas sur le niveau de gêne interne. Une base de données de production chiffrée par un attaquant sans exfiltration établie reste un incident de disponibilité ; elle devient une violation de données dès lors que confidentialité, intégrité ou disponibilité de données personnelles est compromise.

La qualification doit être séparée en quatre axes :

service : quels produits, interfaces ou processus métier sont dégradés ;
données : quelles catégories, quels volumes connus, quelles protections cryptographiques ;
identités : quels comptes, privilèges, jetons et mécanismes de fédération sont concernés ;
propagation : quels environnements, filiales, fournisseurs ou clients dépendent du périmètre touché.

Une compromission d’identité ne se limite pas au compte observé. La révocation d’un compte ne révoque pas automatiquement les sessions déjà émises, les jetons d’accès ni les cookies d’authentification. La page sur les identités et mécanismes d’accès doit être traduite en procédures d’incident : durée de vie des sessions, invalidation centralisée, rotation des secrets applicatifs et propagation des révocations.

Registre de décision et contenu de notification

Le registre de décision est la pièce maîtresse. Il doit lier chaque fait observé à une heure, une source, un niveau de confiance et une décision. Sans cette structure, l’incident se raconte après coup avec la précision habituelle des souvenirs de crise : très affirmée, étrangement incompatible avec les journaux.

Conserver au minimum :

l’identifiant unique de l’incident ;
les horodatages en temps universel coordonné, ou UTC (Coordinated Universal Time) ;
le déclencheur, la source du signal et l’analyste ayant qualifié ;
les systèmes, données et tiers potentiellement affectés ;
les hypothèses en cours et les faits confirmés ;
les décisions de notification, leur approbateur et leur canal ;
la version exacte de chaque message envoyé ;
les accusés de réception et demandes de complément ;
les mesures de confinement, d’éradication et de rétablissement.

Une notification initiale n’a pas besoin de contenir la cause racine. Elle doit éviter trois défauts : masquer l’incertitude, affirmer une absence d’exfiltration sans preuve, ou annoncer un retour à la normale avant validation de l’intégrité. Formuler « aucune exfiltration détectée à ce stade, investigation en cours sur les journaux disponibles » est défendable. Formuler « aucune exfiltration » sans visibilité réseau ni journal d’audit, c’est donner un statut juridique à un angle mort.

Les indicateurs de compromission doivent être partagés selon le canal demandé et le niveau de sensibilité. Une adresse IP, une empreinte de fichier ou un domaine malveillant peut aider à protéger l’écosystème, mais un journal brut peut contenir des données personnelles, des secrets ou des détails exploitables. Le registre distingue donc les éléments partageables, les éléments restreints et les éléments interdits de diffusion externe.

Exemple de calcul des échéances de notification

Le calcul doit être automatisé à partir de l’horodatage de connaissance, puis contrôlé par une personne responsable. Le script suivant utilise GNU date et jq pour générer les échéances NIS2 et RGPD. Il ne décide pas de l’applicabilité réglementaire : aucun script ne lit une transposition nationale entre deux cafés.

#!/usr/bin/env bash
# Prérequis : GNU date et jq.
# L'heure de connaissance doit être saisie en UTC, format ISO 8601.
set -euo pipefail

known_at="2026-09-21T08:30:00Z"

nis2_early=$(date -u -d "$known_at + 24 hours" +"%Y-%m-%dT%H:%M:%SZ")
nis2_formal=$(date -u -d "$known_at + 72 hours" +"%Y-%m-%dT%H:%M:%SZ")
nis2_final=$(date -u -d "$known_at + 30 days" +"%Y-%m-%dT%H:%M:%SZ")
rgpd_authority=$(date -u -d "$known_at + 72 hours" +"%Y-%m-%dT%H:%M:%SZ")

jq -n \
  --arg known_at "$known_at" \
  --arg nis2_early "$nis2_early" \
  --arg nis2_formal "$nis2_formal" \
  --arg nis2_final "$nis2_final" \
  --arg rgpd_authority "$rgpd_authority" \
  '{
    connaissance: $known_at,
    nis2: {
      alerte_precoce: $nis2_early,
      notification: $nis2_formal,
      rapport_final_ou_avancement: $nis2_final
    },
    rgpd: {
      notification_autorite_si_risque: $rgpd_authority
    }
  }'

Ce calcul doit intégrer les délais spécifiques DORA, les heures ouvrées définies par le texte applicable et les exigences nationales. Le moteur de calcul doit aussi déclencher des alertes avant l’échéance, pas à l’échéance. Un rappel à H-0 est une alarme incendie installée dans les cendres.

Surface d’attaque de la notification et conditions d’exploitation

La notification crée une surface d’attaque propre. Un attaquant informé de la procédure peut provoquer de faux signaux pour saturer l’astreinte, usurper une autorité afin d’obtenir des détails, ou exploiter les communications de crise pour diffuser du hameçonnage ciblé. Les canaux officiels, les coordonnées vérifiées hors bande et l’authentification forte sont donc des exigences de sécurité, pas de confort administratif.

Le contenu transmis doit être chiffré si le portail ou le canal l’exige. Les clés, certificats et comptes d’accès aux portails de notification doivent être inventoriés, testés et renouvelés. Un certificat expiré le jour d’un incident ne devient pas philosophique parce qu’il est associé à la conformité. Il bloque le dépôt, point.

Prévoir une sauvegarde chiffrée du registre, des journaux critiques et des modèles de notification. La reprise doit inclure un mode dégradé : coordonnées téléphoniques vérifiées, procédures hors du système de ticketing compromis, copies contrôlées des mandats de délégation. Le stockage de crise ne doit pas dépendre exclusivement du domaine d’identité potentiellement compromis.

La notification ne garantit pas le confinement, la préservation de preuve, la continuité d’activité ni l’information contractuelle des clients. Ces résultats viennent du plan de réponse, de la journalisation, de la segmentation et de la gestion des fournisseurs. La cartographie des menaces doit alimenter les scénarios testés : rançongiciel, compromission d’identité, fuite via fournisseur, effacement de journaux et indisponibilité cloud.

🐝 Ce qui arrive si on s’en passe

Sans horloge de notification tenue, la première perte n’est pas réglementaire mais probatoire : les journaux utiles tournent et s’effacent selon leur rétention pendant que la qualification traîne, si bien que l’étendue réelle d’un accès ne peut plus être reconstituée, ni infirmée. La charge de démontrer la date de connaissance revient alors à l’entité, avec pour seule pièce des échanges informels. En l’absence de signalement précoce, l’équipe de réponse nationale ne peut pas corréler l’événement avec d’autres victimes de la même campagne : les indicateurs restent locaux et les entités voisines conservent la même faiblesse ouverte. Les clients, assureurs et donneurs d’ordre découvrent l’incident par un canal tiers, ce qui déclenche des demandes contradictoires et des versions divergentes selon l’interlocuteur. La reprise se négocie ensuite sous contrainte externe plutôt que selon le plan technique prévu.

🦫 Explication de la marmotte 🍫

Lorsqu’un problème de sécurité est découvert, l’organisation doit d’abord noter l’heure exacte où elle a obtenu des éléments crédibles. Cette heure lance parfois un délai légal. Il ne faut pas attendre de connaître toute l’histoire : une première déclaration peut dire ce qui est connu, ce qui reste incertain et quelles mesures sont déjà prises.

Plusieurs règles peuvent s’appliquer en même temps. Certaines concernent les services essentiels, d’autres les données sur des personnes, d’autres encore les entreprises financières. Elles ne demandent pas toutes les mêmes informations ni les mêmes délais. Il faut donc identifier le type de service touché, les données concernées, les personnes ou organisations affectées et les autorités à prévenir.

Pendant l’enquête, chaque décision doit être enregistrée avec son heure, sa source et sa raison. Les messages envoyés doivent être conservés avec la preuve de leur réception. Si une information change, une mise à jour est envoyée : cacher l’incertitude crée un risque plus grand que reconnaître qu’une vérification continue.

La procédure peut échouer si les journaux ont disparu, si le système de suivi est inaccessible, si les accès aux portails ne fonctionnent plus ou si une personne malveillante se fait passer pour une autorité. Il faut donc protéger les accès, garder des copies des procédures et prévoir un moyen de communiquer quand les outils habituels sont compromis.

Pages voisines

La citent

Délais de notification d’incident NIS2 RGPD DORA

Elle cite

: les deux pages se citent l’une l’autre.

Délais de notification d’incident NIS2 RGPD DORA

Délais de notification d’incident NIS2 RGPD DORA

NIS2, RGPD et DORA : trois horloges distinctes

Qualification de l’incident et démarrage du compteur

Registre de décision et contenu de notification

Exemple de calcul des échéances de notification

Surface d’attaque de la notification et conditions d’exploitation

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines