--- name: "Modèles de rapport d'incident NIS2 — Pack article 23" version: "1.0" updated: "2026-07-14" source: "https://www.orbiqhq.com/templates/nis2-incident-reporting-pack" license: "Free to use; attribution appreciated" legal_basis: - "https://eur-lex.europa.eu/eli/dir/2022/2555/oj" - "https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj" --- # Modèles de rapport d'incident NIS2 — Pack article 23 Toutes les étapes du signalement des incidents importants au titre de NIS2, sous forme de formulaires structurés : l'alerte précoce à 24 heures, la notification d'incident à 72 heures, le rapport intermédiaire / d'avancement et le rapport final à un mois, mis en correspondance avec l'article 23(4)(a)–(e) de la directive (UE) 2022/2555. Un agent IA ou un pilote d'incident peut dérouler la séquence complète de signalement à partir de ce seul fichier : (1) ouvrir une entrée de registre à la prise de connaissance, (2) déposer l'alerte précoce sous 24 heures, (3) déposer la notification d'incident sous 72 heures, (4) répondre aux demandes de l'autorité par des rapports intermédiaires, (5) déposer le rapport final sous un mois — ou un rapport d'avancement si l'incident est toujours en cours. ## 1. Test de déclenchement — l'incident est-il « important » ? Article 23(3) : à signaler lorsque l'incident (a) a causé ou est susceptible de causer une perturbation opérationnelle grave des services ou une perte financière pour l'entité, ou (b) a affecté ou est susceptible d'affecter d'autres personnes physiques ou morales en causant un dommage matériel ou immatériel considérable. Pour les fournisseurs DNS, les registres de TLD, le cloud, les centres de données, les CDN, les fournisseurs de services managés / de sécurité managée, les places de marché en ligne, les moteurs de recherche, les réseaux sociaux et les prestataires de services de confiance, le règlement d'exécution (UE) 2024/2690 de la Commission (applicable depuis le 7 novembre 2024) ajoute des critères quantitatifs. Déclencheurs transversaux de l'article 3 (UN seul suffit) : - `financial-loss` — perte financière directe > 500 000 EUR ou > 5 % du chiffre d'affaires annuel de l'exercice précédent, le montant le plus bas étant retenu - `trade-secret-exfiltration` - `death-of-natural-person` - `considerable-damage-to-health` - `malicious-unauthorised-access` susceptible de causer une perturbation opérationnelle grave - `recurring` — ≥ 2 incidents de même cause racine apparente en 6 mois, franchissant collectivement le seuil de perte financière Plus des seuils par service aux articles 4–14 (p. ex. résolution DNS indisponible > 30 minutes ; temps de réponse DNS moyen > 10 secondes pendant > 1 heure ; intégrité compromise pour > 1 000 domaines ou 1 % du portefeuille). ## 2. L'échelle de signalement (échéances à compter de la prise de connaissance) | Étape | Échéance | Ancrage | Contenu obligatoire | |---|---|---|---| | `early-warning` | ≤ 24 h | Art 23(4)(a) | cause illicite/malveillante soupçonnée (`yes\|no\|unknown`) ; impact transfrontière possible (`yes\|no\|unknown`) | | `incident-notification` | ≤ 72 h (prestataires de services de confiance : ≤ 24 h) | Art 23(4)(b) | mise à jour de l'alerte précoce ; évaluation initiale de la gravité et de l'impact ; indicateurs de compromission lorsqu'ils sont disponibles | | `intermediate-report` | sur demande de l'autorité | Art 23(4)(c) | mises à jour pertinentes du statut | | `final-report` | ≤ 1 mois après la notification d'incident | Art 23(4)(d) | description détaillée incl. gravité et impact ; type de menace ou cause racine ; mesures d'atténuation appliquées et en cours ; impact transfrontière le cas échéant | | `progress-report` | à l'échéance du rapport final si l'incident est en cours ; rapport final ensuite ≤ 1 mois après la fin du traitement | Art 23(4)(e) | comme l'intermédiaire, plus le calendrier prévu | Remarque : l'article 23(5) oblige le CSIRT / l'autorité compétente à répondre à l'alerte précoce dans les 24 heures, y compris par des orientations et, sur demande, un appui technique. Article 23(1)–(2) : les destinataires des services doivent être informés des incidents importants qui les affectent défavorablement, ainsi que des cybermenaces importantes et des contre-mesures possibles ; les autorités peuvent ordonner une information du public. L'article 30 permet la notification volontaire d'incidents et de menaces non importants. ## 3. Champs des formulaires ### Formulaire 0 — entrée du registre des incidents (interne, à la détection) ```yaml incident_id: "" # p. ex. INC-2026-041 entity: name: "" classification: "" # essential | important ; secteur annexe I/II authority_registration: "" incident_commander: "" # nom, rôle, contact 24/7 reporting_officer: "" awareness_at: "" # date-heure ISO avec fuseau horaire — démarre le délai de 24 h detection_source: "" # monitoring | employee | customer | third-party | authority affected_services: [] significance: basis: "" # art23-3-a | art23-3-b | identifiant du critère cir-2024-2690 reasoning: "" cross_border: "" # États membres / entités potentiellement affectés report_log: [] # {stage, submitted_at, channel, authority_reference} ``` ### Formulaire 1 — alerte précoce (≤ 24 h) Obligatoire : `entity`, `contact`, `awareness_at`, `brief_description` (2–4 phrases), `affected_services`, `malicious_suspected: yes|no|unknown` (+ une ligne de justification), `cross_border_possible: yes|no|unknown` (+ États membres s'ils sont connus). Facultatif : `assistance_requested: yes|no`, `contained: yes|no`. ### Formulaire 2 — notification d'incident (≤ 72 h) Obligatoire : `early_warning_reference`, `changes_since_early_warning`, `severity_assessment` (étendue, utilisateurs/destinataires affectés, durée), `impact_assessment` (opérationnel, estimation financière, effets CID), `iocs` (si disponibles), `significance_criteria_met`, `mitigation_taken`, `cross_border_update`, `recipient_communication` (destinataires du service informés conformément à l'art 23(1)–(2)). ### Formulaire 3 — rapport intermédiaire / d'avancement Obligatoire : `reference`, `trigger` (`authority-request` | `one-month-ongoing`), `status_update`, `updated_impact`, `new_findings`, `next_steps_timeline`. ### Formulaire 4 — rapport final (≤ 1 mois après le formulaire 2) Obligatoire (les quatre éléments sont impératifs au titre de l'art 23(4)(d)) : 1. `detailed_description` — chronologie narrative, chiffres définitifs de gravité et d'impact 2. `threat_and_root_cause` — type de menace ; cause racine déclenchante probable 3. `mitigation` — mesures appliquées et en cours, avec responsables et échéances 4. `cross_border_impact` — le cas échéant Recommandé : `lessons_learned` — changements préventifs alimentant les mesures de gestion des risques de l'article 21 de l'entité ; revue du respect des délais de 24 h / 72 h. ## 4. Où déposer - **Allemagne :** portail de signalement du BSI (Melde- und Informationsportal) ; NIS2UmsuCG en vigueur depuis le 6 décembre 2025 (24 h / 72 h / 1 mois). - **Norvège :** NSM + autorité sectorielle au titre de la digitalsikkerhetsloven (en vigueur depuis le 1er octobre 2025) : notification ≤ 24 h, mise à jour ≤ 72 h, rapport ≤ 1 mois. NIS2 elle-même n'est pas encore intégrée à l'accord EEE à la mi-2026. - **Royaume-Uni :** le Cyber Security and Resilience Bill (devant le Parlement, sanction royale attendue fin 2026) propose une notification initiale à 24 heures et un rapport complet à 72 heures au régulateur, le NCSC étant informé en parallèle. - Autres États membres de l'UE : le portail de votre CSIRT national / autorité compétente (en France : l'ANSSI) ; vérifiez l'état de la transposition et les canaux sectoriels. --- Formats : DOCX (cinq formulaires prêts à déposer) + PDF (compagnon d'impression et de revue) sur https://www.orbiqhq.com/templates/nis2-incident-reporting-pack. Les lois nationales de transposition peuvent ajouter des champs ou des délais sectoriels plus courts. Ceci n'est pas un avis juridique.