Sur la base des travaux de recherche du Dr iur. Dr rer. pol. Fabian M. A. Teichmann

Il est 3 heures du matin. Le département informatique constate que des attaquants se sont infiltrés de manière active dans les systèmes de l'entreprise depuis des heures. Le conseil d'administration est réveillé. Et alors commence une question à laquelle personne ne peut répondre précisément à ce moment-là : qui devons-nous informer en réalité, à quel moment – et dans quel délai ?

En pratique, c'est précisément la situation dans laquelle de nombreuses entreprises se rendent compte qu'elles n'ont jamais vraiment assimilé les obligations de notification du droit européen de la cybersécurité. En effet, avec DORA, NIS-2 et le Cyber Resilience Act (CRA), il existe aujourd'hui trois réglementations européennes différentes qui prévoient toutes des obligations de notification en cas d'incident cybernétique – avec des délais différents, des destinataires différents, des autorités différentes et des déclencheurs différents. Teichmann a analysé méthodiquement cette situation complexe dans plusieurs articles scientifiques. Les enseignements tirés sont pertinents pour toute entreprise relevant de plus d'une de ces réglementations.

Pourquoi il existe trois régimes de notification différents

La création d'obligations de notification parallèles n'est pas une erreur du législateur européen, mais l'expression de trois logiques de régulation distinctes.

NIS-2 s'adresse aux exploitants – c'est-à-dire aux entreprises qui exploitent des services et infrastructures critiques. L'objectif est que les perturbations de ces services soient signalées rapidement aux autorités de contrôle afin que celles-ci puissent évaluer et coordonner les risques systémiques. NIS-2 est multisectoriel et centré sur l'exploitant (Teichmann, Neue Cybersicherheitspflichten durch das NIS-2-Umsetzungsgesetz, K&R 2026, p. 26–32).

DORA s'adresse aux entités financières – c'est-à-dire à un secteur spécifique d'une importance systémique particulière. La logique est la même que pour NIS-2, mais les exigences sont plus strictes et plus détaillées. Les défaillances financières peuvent déstabiliser l'ensemble du système économique, c'est pourquoi le législateur impose ici des normes plus rigoureuses (Teichmann, Digital Operational Resilience Act – EU-weit einheitliche IT-Sicherheitsregeln für Finanzinstitute, BB 2025, p. 2760–2770).

Le CRA, quant à lui, s'adresse aux fabricants de produits connectés – donc pas aux exploitants, mais aux producteurs de la technologie elle-même. Lorsqu'une vulnérabilité d'un produit est activement exploitée, le fabricant doit le signaler afin que les autorités puissent réagir et avertir les autres utilisateurs de ce même produit (Teichmann, Cyber Resilience Act – Produktsicherheit, SBOM und Herstellerhaftung entlang des Lebenszyklus, CCZ 2025, p. 165–171).

Le problème se pose lorsque la même entreprise remplit plusieurs rôles simultanément – ce qui est très fréquent en pratique. Une banque qui développe et exploite son propre logiciel peut simultanément être soumise à DORA en tant qu'entité financière, à NIS-2 en tant qu'entité essentielle et au CRA en tant que fabricant. À ce moment-là, trois obligations de notification différentes avec des délais distincts s'appliquent en parallèle.

Les obligations de notification en détail : qui signale quoi, quand et à qui

NIS-2 : Le modèle standard en trois étapes. NIS-2 a instauré la procédure de notification en trois étapes, qui sert aujourd'hui de modèle de référence pour l'ensemble du droit européen de la cybersécurité. Dans les 24 heures suivant la prise de connaissance d'un incident important, une alerte précoce doit être envoyée à l'autorité nationale de cybersécurité (le BSI en Allemagne). Cette notification initiale ne doit pas nécessairement contenir une analyse complète ; il suffit d'informer qu'un incident important a eu lieu et de fournir une première évaluation indiquant s'il s'agit potentiellement d'un acte malveillant. Dans les 72 heures, la notification d'incident proprement dite suit, avec une première évaluation. Un rapport final doit être soumis au plus tard un mois après la notification initiale. Un incident est considéré comme important s'il a causé ou peut causer des perturbations opérationnelles majeures ou des pertes financières importantes – le critère est donc l'impact potentiel, et non pas seulement le dommage déjà survenu (Teichmann, Die neue 24-Stunden-Meldepflicht for Cyberangriffe nach ISG, Jusletter, 29 septembre 2025).

DORA : Plus strict, plus rapide, spécifique au secteur financier. DORA reprend le modèle de base en trois étapes, mais le durcit sur plusieurs points. Le durcissement décisif concerne le premier délai : une notification initiale doit être adressée à l'autorité de surveillance financière (la BaFin en Allemagne) dans les quatre heures suivant la classification de l'incident comme majeur – et non pas après 24 heures. Cela suppose que l'entité financière dispose de processus de classification internes efficaces permettant une telle évaluation en peu de temps. DORA définit des seuils basés sur des critères financiers spécifiques : nombre et proportion de clients et de transactions concernés, impact géographique, durée de l'indisponibilité, atteinte à la réputation et pertes financières. La notification intermédiaire suit dans les 72 heures, et le rapport final dans un délai d'un mois – de manière analogue à NIS-2. DORA étant considéré comme une lex specialis par rapport à NIS-2, la notification à la BaFin remplace en principe la notification au BSI ; les deux autorités se coordonnent entre elles (Teichmann, Harmonisierung von Incident-Reporting-Meldefristen nach DORA, NIS2 und CRA, ZRFC 2026, p. 81–88).

CRA : Une logique totalement différente. Le CRA introduit une obligation de notification qui diffère structurellement de NIS-2 and DORA. Il ne s'agit pas d'incidents d'exploitation, mais de vulnérabilités de produits. Selon l'art. 14 du CRA, les fabricants de produits connectés doivent signaler activement les vulnérabilités exploitées dans les 24 heures suivant leur prise de connaissance au BSI et, en parallèle, à l'Agence européenne pour la cybersécurité ENISA. Une notification plus complète suit dans les 72 heures, et un rapport final dans les 14 jours – et non un mois comme pour NIS-2 et DORA. La différence structurelle clé : les notifications du CRA concernent les vulnérabilités d'un produit, pas les incidents survenant dans sa propre exploitation. Un fabricant n'a donc pas à signaler un incident parce qu'il a lui-même été victime d'une attaque, mais parce que son produit a été ou pourrait être la porte d'entrée d'une attaque contre un tiers (Teichmann, CCZ 2025, p. 165–171).

Le problème de coordination : lorsque les trois régimes s'appliquent simultanément

Le véritable défi apparaît dans les configurations où une entreprise est soumise à plusieurs régimes en même temps. L'exemple classique est celui d'un éditeur de logiciels qui développe des solutions de sécurité pour des banques et qui opère lui-même en tant que prestataire de services informatiques critique dans le secteur financier. En cas d'incident de sécurité majeur, cette entreprise peut être concernée simultanément en tant qu'entité NIS-2 avec une obligation de notification au BSI dans les 24 heures, en tant que fabricant CRA avec une obligation de notifier une vulnérabilité de produit activement exploitée dans les 24 heures au BSI et à l'ENISA, et en tant que prestataire tiers de TIC sous DORA avec l'obligation d'informer les entités financières concernées, lesquelles doivent à leur tour notifier la BaFin dans un délai de quatre heures (Teichmann, ZRFC 2026, p. 81–88).

Ce qui est identique – et ce qui ne l'est pas

Le déclencheur diffère fondamentalement. NIS-2 déclenche l'obligation de notification lors d'un incident de sécurité important qui perturbe l'exploitation. DORA la déclenche lors d'un incident lié aux TIC majeur avec des répercussions financières concrètes. Le CRA la déclenche lors d'une vulnérabilité de produit activement exploitée – indépendamment du fait que le fabricant lui-même soit affecté sur le plan opérationnel.

Le délai initial varie : 24 heures sous NIS-2 et CRA, quatre heures sous DORA. Pour les entités financières, le délai DORA est donc le plus strict – et il ne commence pas à la découverte de l'incident, mais à partir du moment de sa classification interne comme majeur.

L'autorité notificatrice est différente : sous NIS-2 et CRA, les notifications sont envoyées au BSI, et sous DORA à la BaFin. Les notifications CRA sont également envoyées à l'ENISA au niveau européen. Le rapport final est dû après un mois selon NIS-2 et DORA, et après seulement 14 jours selon le CRA. Enfin, le contenu diffère : NIS-2 et DORA se concentrent sur l'incident d'exploitation, tandis que le CRA se concentre sur la vulnérabilité du produit et le statut du correctif.

Le RGPD comme quatrième couche

Parallèlement à DORA, NIS-2 et le CRA, il existe une quatrième obligation de notification qui s'applique à de nombreux incidents cybernétiques : le Règlement Général sur la Protection des Données (RGPD). Si des données à caractère personnel sont concernées – ce qui est le cas dans la plupart des attaques contre les systèmes d'entreprise –, l'art. 33 du RGPD impose une obligation de notification à l'autorité de protection des données compétente dans les 72 heures. La notification RGPD s'effectue en parallèle des notifications de cybersécurité et s'adresse à sa propre autorité. Une coordination est nécessaire pour éviter que des informations contradictoires ne soient transmises aux différentes instances. Teichmann souligne que de nombreuses entreprises sous-estiment cette structure parallèle et s'empêtrent dans des obligations de communication contradictoires en cas d'urgence (Teichmann, CCZ 2025, p. 165–171).

Ce que cela signifie en pratique

Chaque entreprise doit d'abord comprendre de quels régimes elle relève. Ce n'est pas une question simple : un éditeur de logiciels de taille moyenne qui développe des produits pour des clients industriels et intervient à cette occasion comme prestataire informatique pour des entités NIS-2 peut tomber sous le coup des trois réglementations.

Le processus de notification doit être défini précisément et à l'avance. Qui décide si un incident doit être notifié ? Qui est responsable de la notification ? Quel modèle est utilisé ? Ces décisions ne peuvent pas être prises pour la première fois dans une situation de crise – et encore moins face à des délais de quatre heures.

La communication avec les différentes autorités doit être coordonnée. Si un incident déclenche simultanément une notification NIS-2 au BSI, une notification DORA à la BaFin et une notification RGPD à l'autorité de protection des données, ces notifications doivent être cohérentes. Des informations contradictoires peuvent nuire à la confiance des autorités de contrôle.

De plus, toutes les notifications, les faits sous-jacents et la chronologie des décisions doivent être documentés de manière infalsifiable pour pouvoir faire l'objet d'un audit. À la suite d'un incident, les autorités vérifieront si les délais de notification ont été respectés – et la charge de la preuve incombe à l'entreprise (Teichmann, ZRFC 2026, p. 81–88).

Conclusion : Connaître la complexité avant que l'horloge ne tourne

DORA, NIS-2 et le CRA partagent tous le même objectif fondamental : informer rapidement les autorités lorsqu'un incident cybernétique survient ou qu'une vulnérabilité est exploitée. Mais les voies pour y parvenir diffèrent en termes de délais, d'autorités, de déclencheurs et de contenus.

La recherche de Teichmann le démontre : celui qui tente de comprendre ces différences seulement lorsque l'incident survient a déjà perdu. Le délai de quatre heures de DORA, le délai de 24 heures de NIS-2, le délai de 14 jours pour le rapport final du CRA – ce ne sont pas des dispositions juridiques abstraites. Ce sont des exigences opérationnelles qui doivent être ancrées dès aujourd'hui au sein de chaque entreprise concernée.

Toutes les références renvoient à des contributions scientifiques publiées par le Dr iur. Dr rer. pol. Fabian M. A. Teichmann. La bibliographie complète est documentée dans la liste des publications (à jour en mai 2026).