[{"data":1,"prerenderedAt":14},["ShallowReactive",2],{"article:fr:le-delai-d-incident-nis2-pour-une-entreprise-de-logiciels-24-heures-72-heures-un-mois-ce-qui-rend-un-incident-important-pour-un-fournisseur-cloud-et-une-page-qui-redige-les-trois-rapports":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"answer":9,"body":13},"fr","le-delai-d-incident-nis2-pour-une-entreprise-de-logiciels-24-heures-72-heures-un-mois-ce-qui-rend-un-incident-important-pour-un-fournisseur-cloud-et-une-page-qui-redige-les-trois-rapports","Le délai d'incident NIS2 pour une entreprise de logiciels : l'alerte précoce à 24 heures, la notification à 72 heures, le rapport final à un mois, ce qui rend un incident important pour un fournisseur cloud, et une page qui rédige les trois rapports","L'article 23, paragraphe 4, de NIS2 fait courir trois délais à partir du moment où une entité essentielle ou importante a connaissance d'un incident important : une alerte précoce dans les 24 heures, une notification d'incident dans les 72, et un rapport final dans le mois qui suit cette notification, avec un rapport intermédiaire sur demande et un rapport d'avancement lorsque l'incident est encore en cours. Pour un fournisseur de services d'informatique en nuage, le règlement d'exécution (UE) 2024\u002F2690 dit quand un incident est important : une perte financière directe supérieure à 500 000 EUR ou à 5 % du chiffre d'affaires, le montant le plus bas étant retenu, un service totalement indisponible pendant plus de 30 minutes, une disponibilité limitée pour plus de 5 % ou 1 million de ses utilisateurs dans l'Union pendant plus d'une heure, ou une compromission des données soupçonnée d'être malveillante. Ce que chaque rapport contient, à quel CSIRT il va, et une page gratuite qui calcule les délais et rédige les trois en six langues.","2026-09-13",{"who":10,"when":11,"do":12},"Une entreprise de logiciels qui est une entité essentielle ou importante au titre de NIS2, ce qui, pour un fournisseur de services d'informatique en nuage, un fournisseur de services gérés ou un fournisseur de services de sécurité gérés, est le cas par l'annexe I ou II quel que soit l'État ; et la même entreprise comme le fournisseur dont dépendent les propres rapports de ses clients au titre de l'article 23.","À partir du moment de la connaissance d'un incident important : l'alerte précoce dans les 24 heures, la notification dans les 72, le rapport final au plus tard un mois après la soumission de la notification ; l'obligation s'applique depuis la date limite de transposition du 17 octobre 2024, et le règlement d'exécution (UE) 2024\u002F2690 fixe les seuils pour les fournisseurs numériques depuis le 7 novembre 2024.","Consignez le moment de la connaissance et lisez l'incident au regard de l'article 23, paragraphe 3, et, pour un fournisseur numérique, des seuils du règlement ; envoyez l'alerte précoce dans les 24 heures avec les deux indications qu'elle demande, la notification dans les 72 avec l'évaluation initiale, le rapport final dans le mois avec ses quatre éléments ; la page gratuite calcule les trois délais, nomme le CSIRT et rédige les rapports.","\nNIS2 a un délai qu'une entreprise de logiciels ne peut pas externaliser : la notification d'un incident important, à l'article 23, en trois étapes avec trois délais comptés en heures et en mois à partir du moment où l'entité en a connaissance. Le CRA a son propre délai pour les vulnérabilités activement exploitées et le RGPD ses 72 heures pour une violation de données à caractère personnel, et l'[article d'aiguillage](\u002Farticles\u002Fnis2-or-cra-which-incident-clock-runs-for-a-software-company-and-what-makes-an-incident-significant) dit lequel court ; celui-ci porte sur le délai NIS2 lui-même, sur ce que chacun de ses trois rapports contient, et sur le moment où un incident est assez important pour le déclencher, lu au regard du [catalogue](\u002Fnis2\u002Fscope) que StandardOS tient de la directive et de la [page gratuite](\u002Fnis2\u002Fincident-clock) qui calcule les délais et rédige les rapports.\n\n## Les trois délais de l'article 23, paragraphe 4\n\nL'article 23, paragraphe 4, compte à partir de la connaissance d'un incident important. Point a) : une alerte précoce sans retard injustifié et en tout état de cause dans les 24 heures, qui, le cas échéant, indique si l'incident est soupçonné d'être causé par des actes illicites ou malveillants et s'il pourrait avoir un impact transfrontière. Point b) : une notification d'incident sans retard injustifié et en tout état de cause dans les 72 heures, qui met à jour l'alerte précoce et donne une évaluation initiale de l'incident, y compris sa gravité et son impact, ainsi que, lorsqu'ils sont disponibles, les indicateurs de compromission ; un prestataire de services de confiance donne cette notification dans les 24 heures (article 23, paragraphe 4, deuxième alinéa). Point c) : un rapport intermédiaire sur les mises à jour pertinentes de la situation, à la demande du CSIRT ou de l'autorité compétente. Point d) : un rapport final au plus tard un mois après la soumission de la notification, avec quatre éléments : une description détaillée de l'incident, y compris sa gravité et son impact, le type de menace ou la cause profonde qui l'a probablement déclenché, les mesures d'atténuation appliquées et en cours, et, le cas échéant, l'impact transfrontière. Point e) : lorsque l'incident est encore en cours à l'échéance du rapport final, un rapport d'avancement à ce moment-là et le rapport final dans le mois qui suit le traitement de l'incident. Le destinataire est le CSIRT ou, lorsque l'État membre le prévoit, l'autorité compétente (article 23, paragraphe 1), et le cas échéant les destinataires des services sont informés sans retard injustifié d'un incident important susceptible de les affecter. La page gratuite nomme le CSIRT de l'État d'après le registre du réseau des CSIRT, calcule les trois délais et compte le mois du rapport final à partir du délai de la notification tant que l'heure de soumission n'est pas saisie.\n\n## Ce qui rend un incident important\n\nL'article 23, paragraphe 3, de la directive pose deux conditions, dont chacune rend un incident important : il a causé ou est susceptible de causer une perturbation opérationnelle grave des services ou des pertes financières pour l'entité, ou il a affecté ou est susceptible d'affecter d'autres personnes physiques ou morales en causant un dommage matériel ou moral considérable. Pour les fournisseurs numériques, le règlement d'exécution (UE) 2024\u002F2690 va plus loin et dit en chiffres quand ces conditions sont remplies. L'article 3, paragraphe 1, énumère sept critères généraux dont un seul suffit : une perte financière directe supérieure à 500 000 EUR ou à 5 % du chiffre d'affaires annuel total de l'entité au cours de l'exercice précédent, le montant le plus bas étant retenu ; l'exfiltration de secrets d'affaires ; le décès d'une personne physique ; un dommage considérable à la santé d'une personne physique ; un accès réussi, soupçonné d'être malveillant et non autorisé, aux réseaux et systèmes d'information, susceptible de causer une perturbation opérationnelle grave ; des incidents récurrents qui ensemble remplissent le critère financier (article 4 : au moins deux fois en six mois, la même cause profonde apparente) ; ou l'un des critères par service des articles 5 à 14. Pour un fournisseur de services d'informatique en nuage, l'article 7 en fixe quatre : le service totalement indisponible pendant plus de 30 minutes ; sa disponibilité limitée pour plus de 5 % de ses utilisateurs dans l'Union ou plus de 1 million d'entre eux, le nombre le plus petit étant retenu, pendant plus d'une heure ; l'intégrité, la confidentialité ou l'authenticité des données compromise à la suite d'une action soupçonnée d'être malveillante ; ou une telle compromission avec un impact sur plus de 5 % ou 1 million des utilisateurs dans l'Union, le nombre le plus petit étant retenu. L'article 10 fixe les quatre mêmes pour les fournisseurs de services gérés et de services de sécurité gérés. L'article 3, paragraphe 2, exclut les interruptions programmées et la maintenance planifiée. Une panne SaaS de 31 minutes est donc un incident important et déclenche le délai de 24 heures ; une fenêtre de maintenance planifiée de deux heures ne l'est pas ; un courriel d'hameçonnage parvenu dans une boîte ne l'est pas, sauf si le compte a servi à atteindre les systèmes.\n\n## Ce que chaque rapport dit, et ce qu'il ne doit pas attendre\n\nL'alerte précoce, ce sont deux indications et un horodatage : malveillant ou non, transfrontière ou non, envoyés dans les 24 heures même quand les réponses sont « pas encore connu ». La notification est la première évaluation : ce qui s'est passé, quelle gravité, ce qui est affecté, avec les indicateurs de compromission là où l'entreprise les a ; elle est due dans les 72 heures et n'est pas retenue en attendant le rapport forensique. Le rapport final est l'enregistrement : la description avec la gravité et l'impact, la cause profonde ou le type de menace, les mesures appliquées et encore en cours, et l'impact transfrontière s'il y en a un, un mois après la notification. Aucun des trois n'attend que l'incident soit terminé : l'article 23, paragraphe 4, point e), est écrit précisément pour l'incident encore ouvert à l'échéance du rapport final, et le rapport d'avancement en est la réponse. Une entreprise de logiciels qui notifie en retard parce qu'elle voulait le tableau complet a notifié en retard ; la directive est conçue pour que le tableau se construise en trois étapes.\n\n## Deux délais à côté\n\nUne entreprise de logiciels qui est une entité NIS2 est souvent aussi responsable du traitement ou sous-traitant au titre du RGPD, et le même incident qui atteint le CSIRT dans les 24 heures atteint l'autorité de contrôle dans les 72 lorsque des données à caractère personnel sont affectées, sur le [délai de violation RGPD](\u002Fgdpr\u002Fbreach-clock), et le fabricant d'un produit comportant des éléments numériques notifie une vulnérabilité activement exploitée à la plateforme unique de notification de l'ENISA sur le délai du CRA de 24 heures, 72 heures et 14 jours. Les trois délais courent à partir d'un même moment de connaissance avec trois destinataires et trois seuils différents, et c'est pourquoi la seule chose à régler d'avance est l'enregistrement qui les déclenche : l'incident consigné avec son horodatage, les systèmes affectés, les données affectées et les produits affectés, pour que chaque rapport soit un rendu du même enregistrement et non une enquête à part.\n\n## Quoi en faire\n\nDécidez aujourd'hui quel type de fournisseur l'entreprise est au titre du règlement d'exécution et mettez ses seuils dans la procédure d'incident comme test de « important ». Nommez le CSIRT de l'État, ou l'autorité compétente là où la loi de transposition l'a choisie, avec son portail et son contact, avant le premier incident. Faites tourner la [page gratuite](\u002Fnis2\u002Fincident-clock) une fois avec un incident passé pour voir les trois rapports qu'elle rédige, puis gardez son lien avec le moment de la connaissance comme premier enregistrement de l'incident. StandardOS ouvre le délai à partir de l'enregistrement de l'incident et rédige les trois rapports à partir de lui ; l'[outil de champ d'application](\u002Fnis2\u002Fscope) dit si l'entreprise est une entité essentielle ou importante en premier lieu.\n",1789383964499]