Partnerblog
À partir du 11 septembre 2026, l’obligation de notification prévue à l’art. 14 du Cyber Resilience Act s’appliquera. Les fabricants de produits comportant des éléments numériques devront dès lors notifier les vulnérabilités activement exploitées et les incidents graves, avec un avertissement précoce dans les vingt-quatre heures et une notification dans les septante-deux heures. Un régime de notification supplémentaire s’ajoute ainsi à un paysage où une notification est déjà requise au titre de NIS2, du RGPD et, pour le secteur financier, de DORA. Le nombre d’obligations de notification croît plus vite que leur articulation mutuelle, et l’entreprise qui constate un incident doit déterminer elle-même lesquels de ces régimes elle déclenche simultanément.
Trois régimes, trois qualifications distinctes
Supposons que le système de planification des ressources de l’entreprise (ERP) d’une société belge tombe entièrement en panne, alors qu’il héberge sa facturation, sa comptabilité, sa gestion des stocks ainsi que les applications de planification de la production et de gestion des entrepôts. La gestion de cet environnement est confiée à un prestataire ICT externe, qui signale une activité suspecte et ouvre une enquête. À ce stade, il n’est pas encore établi qu’il y ait un incident, ni donc que des délais aient commencé à courir. L’horloge ne démarre que lorsque l’entreprise sait, avec une certitude raisonnable, qu’un incident s’est produit, et ce séparément sous chaque cadre applicable. Sous la loi NIS2, un avertissement précoce doit être adressé au CCB dans les vingt-quatre heures, suivi de la notification de l’incident dans les septante-deux heures et du rapport final dans le mois. Sous le RGPD, un délai de septante-deux heures s’applique pour la notification à l’Autorité de protection des données, à compter de la prise de connaissance de la violation de données à caractère personnel. Pour une entité financière soumise à DORA, ce délai est de quatre heures après la classification de l’incident comme grave, et en tout état de cause de vingt-quatre heures après la prise de connaissance.
Un seul et même ensemble de faits peut ainsi déclencher plusieurs obligations de notification, chacune assortie de sa propre définition, de son propre seuil, de son propre délai et de sa propre autorité compétente. Un incident est important lorsqu’il satisfait aux critères de l’art. 23, § 3, de la directive NIS2, transposé à l’art. 34 de la loi belge du 26 avril 2024 établissant un cadre pour la cybersécurité des réseaux et des systèmes d’information d’intérêt général pour la sécurité publique. Une violation de données à caractère personnel s’apprécie au regard de l’art. 4, 12), RGPD et des art. 33 et 34 RGPD. Pour le secteur financier, l’obligation de notification est déclenchée lorsqu’un incident grave lié aux TIC survient au sens de l’art. 3, 10), j° art. 19 DORA.
Ces qualifications se recoupent sur le fond mais ne sont pas identiques, et ne peuvent donc pas être assimilées l’une à l’autre. Une attaque par ransomware qui perturbe gravement la prestation de services peut constituer un incident important au sens de NIS2 sans pour autant entraîner une obligation de notification au titre du RGPD. Il est ainsi possible qu’aucune donnée à caractère personnel n’ait été touchée – hypothèse rare en pratique, dès lors que le simple chiffrement de données à caractère personnel peut déjà constituer une violation – mais que cette violation ne présente vraisemblablement pas de risque pour les droits et libertés des personnes concernées, par exemple lorsqu’une sauvegarde adéquate existait, que l’interruption de service est restée limitée et qu’aucune exfiltration n’a eu lieu. Inversement, un accès non autorisé à des données à caractère personnel peut constituer une violation au sens du RGPD sans que l’impact opérationnel n’atteigne le seuil de NIS2. Chaque régime applicable requiert une appréciation distincte des mêmes faits.
Pour les entités financières, DORA s’applique comme lex specialis par rapport à NIS2, de sorte que l’obligation de notification NIS2 ne s’applique pas à ces entités et qu’une notification DORA suffit (art. 1er, § 2, DORA, j° art. 4 de la directive NIS2). Cet avantage cumulatif ne vaut pas à l’égard du RGPD, ni à l’égard d’autres régimes. Si, par exemple, cet établissement financier utilise un système d’IA à haut risque pour son évaluation de la solvabilité, un incident grave au sens du règlement IA entraînera également une notification à l’autorité de surveillance du marché. À partir du 11 septembre 2026, s’y ajoutera, pour les fabricants de produits comportant des éléments numériques, la cascade de notification de l’art. 14 du Cyber Resilience Act.
L’horloge démarre à la certitude raisonnable, pas à la certitude forensique
Le point de départ du délai est, en pratique, l’aspect le plus sensible. Ce qui est déterminant n’est pas le moment où l’attaquant a pénétré dans l’infrastructure ICT de l’entreprise, mais le moment où l’entreprise a su, avec une certitude raisonnable, qu’un incident s’était produit. Le CCB retient cette lecture dans son NIS2 Notification Guide v1.3 (titre A4), et le Comité européen de la protection des données (« CEPD ») applique une logique similaire sous le RGPD dans ses lignes directrices 9/2022 (§ 31).
Cyberincident transfrontalier
Dès que des établissements situés dans plusieurs États membres sont touchés, se pose la question de savoir quelle autorité doit être informée. La réponse varie selon le régime juridique concerné (RGPD/NIS2/DORA, etc.).
Sous le RGPD, un mécanisme de guichet unique existe bel et bien. Le critère déterminant est de savoir si le traitement sous-jacent (et donc pas nécessairement l’incident lui-même) revêt un caractère transfrontalier au sens de l’art. 4, 23), RGPD, l’autorité de contrôle chef de file étant ensuite déterminée sur la base de l’établissement principal au sens de l’art. 4, 16), RGPD. Dans les structures de groupe complexes, cette appréciation repose sur le pouvoir de décision effectif quant aux finalités et aux moyens du traitement, et l’entreprise doit être en mesure d’étayer sa qualification.
NIS2 part d’une logique de compétence différente. En vertu de l’art. 26, § 1er, de la directive, une entité relève en principe de la juridiction de l’État membre dans lequel elle est établie, avec des critères de rattachement particuliers notamment pour les fournisseurs de services d’informatique en nuage et de services gérés. Un impact transfrontalier n’implique pas que la même notification doive être introduite auprès de chaque autorité concernée. La directive appréhende cette dimension au moyen d’un échange d’informations entre les autorités nationales et les CSIRT.
La proposition d’omnibus numérique du 19 novembre 2025 (COM(2025) 837 final) entend instaurer un point d’entrée unique européen pour certaines notifications d’incidents, ce qui signifierait qu’une entité n’introduirait un incident qu’une seule fois au niveau de l’UE, celui-ci étant ensuite transmis aux autorités nationales compétentes. Tant que ce texte n’est toutefois pas adopté, la procédure de réponse aux incidents ne peut s’appuyer dessus.
Contrat avec le prestataire IT
Tout ce qui précède suppose que l’entreprise connaisse les faits. Dans un environnement externalisé faisant appel à plusieurs prestataires IT, c’est rarement le cas. L’obligation légale repose sur l’entité elle-même et ne peut être externalisée, pas même à un conseiller externe ou à un prestataire IT. Il est dès lors important que l’entreprise fasse répercuter ses propres obligations légales et contractuelles dans la chaîne de prestataires IT dont elle dépend.
Concrètement, cela implique, premièrement, un délai de notification contractuel auprès du prestataire qui soit sensiblement plus court que le délai légal propre de l’entreprise. Selon le CCB, les procédures internes ne peuvent engendrer de retard injustifié dans les notifications d’incidents NIS2. L’art. 33, § 2, RGPD ne fixe aucun délai concret pour le sous-traitant, de sorte que c’est en réalité la clause contractuelle qui détermine si le responsable du traitement respecte ses propres septante-deux heures.
Deuxièmement, la conservation des journaux, la préservation des preuves et une obligation de collaboration exécutoire à l’enquête forensique, de préférence sous la forme d’une clause distincte, à côté de la clause d’audit ordinaire. Une crise exige des délais de réaction et des droits d’accès différents de ceux d’un audit de routine. Les clauses qui limitent les moyens de preuve de l’autre partie figurent d’ailleurs sur la liste grise de l’art. VI.91/5, 7°, CDE.
Troisièmement, la localisation des données et l’accès des autorités publiques, avec une obligation d’information préalable à toute modification et une réponse encadrée aux injonctions émanant d’autorités (de pays tiers).
Quatrièmement, le régime de sortie, dont le fondement légal s’est entre-temps considérablement renforcé. Le chapitre VI du règlement sur les données (art. 23 à 31 du règlement (UE) 2023/2854) confère aux clients de services de traitement de données des droits de changement de prestataire opposables et affecte également les contrats cloud existants. Les frais de changement de prestataire seront interdits à partir du 12 janvier 2027.
Ce que cela signifie pour votre pratique
Déterminez et documentez les régimes dont relèvent vos entités, qui est responsable du traitement pour quel traitement, et quelle autorité est compétente dans quel État membre. Révisez les clauses de notification, de conservation des journaux, de collaboration forensique et de sortie dans vos contrats avec les prestataires de services gérés (managed service providers), et alignez-les sur les délais de notification prévus dans vos contrats clients.
Auteurs
