Cyber Resilience Act · 2026/2027

Réponse aux incidents du CRA : responsables, délais et preuves de déclaration

Auteur : Piotr AdamskiRevue opérationnelle et de sécurité : Brillnet C-Team

Contenu informatif. Il ne remplace ni un conseil juridique individuel ni une évaluation de conformité.

Vérifier le champ du CRA et télécharger votre évaluation

Depuis le 11 septembre 2026, les fabricants concernés par le CRA doivent signaler les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité des produits comportant des éléments numériques. L’alerte précoce doit être transmise dans les 24 heures suivant la prise de connaissance et la notification complète dans les 72 heures.

Le principal risque opérationnel n’est pas l’absence de formulaire. C’est l’absence de T0 convenu, de responsable de la décision, de remplaçants disponibles, de sources d’information fiables et d’un historique expliquant pourquoi un événement a reçu telle qualification.

Calendrier du signalement

Étape Délai Points à contrôler
Prise de connaissance T0 Horodatage, source de l’information et personne l’ayant reçue
Alerte précoce Dans les 24 h Informations exigées par le CRA et la SRP à cette étape
Notification complète Dans les 72 h Informations complémentaires sur l’événement et son impact
Rapport final — vulnérabilité activement exploitée Au plus tard 14 jours après la mise à disposition d’une mesure corrective Correction et résultat du traitement
Rapport final — incident grave Dans un délai de 1 mois à compter de la notification à 72 heures Déroulement de l’incident, impact, actions et résultat

Vérifiez toujours les instructions actuelles de la plateforme unique de signalement CRA. Les orientations opérationnelles et le portail peuvent évoluer plus vite que le règlement lui-même.

Toute vulnérabilité ne déclenche pas un signalement au titre de l’article 14

Le CRA vise une vulnérabilité activement exploitée, pas chaque résultat produit par un outil d’analyse. De même, « incident grave » est une notion réglementaire et non un synonyme de tout ticket de sécurité classé en priorité élevée.

Un processus bien défini distingue :

  1. la détection ou la réception d’une information ;
  2. le triage technique ;
  3. l’évaluation des critères réglementaires ;
  4. la décision d’une personne responsable ;
  5. la préparation de la notification ;
  6. la transmission par le canal approprié ;
  7. la correction, le suivi et le rapport final.

Étiqueter automatiquement un résultat « à signaler au titre du CRA » sans approbation humaine crée à la fois un risque de faux positifs et un risque d’omission de signalement.

Définissez les responsabilités avant le début du délai

Un rôle intitulé « équipe sécurité » ne suffit pas. Pour chaque produit, précisez :

  • qui reçoit les informations sur les vulnérabilités ou incidents ;
  • qui réalise le triage technique ;
  • qui est responsable du produit ;
  • qui approuve la qualification réglementaire ;
  • qui transmet la notification dans la SRP ;
  • le remplaçant de chaque rôle soumis à une échéance critique ;
  • tout circuit d’escalade hors horaires habituels exigé par le produit et le fonctionnement opérationnel.

Si une personne cumule plusieurs rôles, consignez-le explicitement. Une petite équipe peut fonctionner ; une responsabilité ambiguë ne le peut pas.

Informations à consigner à T0

Créez la première fiche avant que la discussion porte sur le caractère « vraiment grave » de l’événement. Conservez au minimum :

  • l’heure exacte de prise de connaissance ;
  • la source de l’information ;
  • le produit et sa version ;
  • la personne ayant signalé l’événement ou le système de détection ;
  • une description concise de ce qui a été observé ;
  • la personne ayant reçu l’information ;
  • le lien vers le document source ou la preuve.

Sans cette fiche, l’organisation risque de ne plus pouvoir établir, plusieurs heures après, le moment où le délai légal a réellement commencé.

Une séquence opérationnelle pratique

1. Enregistrez

Ouvrez un dossier et conservez le signalement original. Ne remplacez pas la source au fur et à mesure que la compréhension évolue.

2. Effectuez le triage

Confirmez le produit concerné, sa version, le périmètre technique, les effets connus et les preuves disponibles. Distinguez les faits confirmés des hypothèses.

3. Qualifiez

Consignez les raisons favorables et défavorables à un signalement. La décision doit identifier la personne l’ayant approuvée et l’heure de l’approbation.

4. Transmettez l’alerte à 24 heures

Préparez l’alerte précoce à partir des informations disponibles à ce moment. N’attendez pas une analyse complète de la cause racine alors que le délai légal court déjà.

5. Transmettez la notification à 72 heures

Complétez les informations requises par le processus actuel de la SRP.

6. Corrigez et communiquez

Reliez le travail d’ingénierie, les versions publiées, les mises à jour de sécurité et la communication aux clients au même dossier.

7. Terminez le rapport final

Ne clôturez le processus qu’après avoir consigné le résultat, les actions, les preuves de vérification et le rapport final requis.

Exercez le processus avant un événement réel

Utilisez un scénario réaliste mais hypothétique et vérifiez que :

  • l’équipe sait où créer la fiche ;
  • T0 peut être identifié ;
  • la personne chargée de l’approbation est connue ;
  • des remplaçants sont disponibles ;
  • les données du produit et les journaux peuvent être collectés rapidement ;
  • la personne chargée de la transmission dispose d’un accès fonctionnel à la SRP ;
  • l’exercice laisse un historique des décisions et des actions d’amélioration.

Le rôle de Pulsar GRC

Pulsar permet de relier l’incident ou la vulnérabilité aux risques, actions, responsables, documents, preuves, rapports et à l’historique des décisions. Risques, tâches, documents, preuves et rapports conservent le contexte des réponses et des décisions.

Votre organisation évalue si l’article 14 s’applique, approuve la notification et la transmet à la SRP par le canal approprié. Préparer des fiches dans Pulsar ne remplace pas la transmission d’une notification.

Découvrez Pulsar GRC dans un processus opérationnel

Guides associés

Exercice proposé : une information arrive avant le week-end

Prenez une situation fictive : le vendredi, une personne reçoit un message décrivant l’exploitation possible d’un défaut dans une version encore utilisée. Le message est incomplet et le responsable technique habituel est absent. L’exercice doit vérifier ce que l’organisation fait avec cette information, pas supposer d’emblée que tous les critères de signalement sont remplis. Le participant conserve le message original et note l’heure, le canal et les personnes informées.

Demandez au remplaçant de retrouver la fiche produit, les versions concernées et le responsable de la décision réglementaire. S’il faut plusieurs appels pour connaître ce responsable, notez un écart organisationnel. Les délais légaux ne deviennent pas des délais ouvrés parce que le signalement est reçu le vendredi. Les horaires et les modalités d’astreinte doivent donc être conçus selon le risque réel et les engagements applicables, avec une personne capable de prendre la décision.

Préparer une information incomplète sans inventer de faits

Une première notification peut devoir être préparée alors que l’impact exact reste inconnu. Séparez les faits établis, les informations à confirmer et les hypothèses. La présence d’une version dans un message ne prouve pas que toutes ses installations sont touchées. De même, un journal montrant une tentative ne démontre pas nécessairement une exploitation réussie. Le dossier doit conserver ces distinctions pour éviter que les formulations de la première alerte deviennent des conclusions techniques non vérifiées.

Pour chaque information importante, conservez sa source et le nom de la personne qui la vérifie. Le responsable de produit peut confirmer la distribution d’une version ; l’équipe sécurité peut examiner les traces ; le responsable réglementaire apprécie les critères de notification. Si une même personne remplit plusieurs rôles, indiquez les étapes qu’elle a réalisées. Le mécanisme d’approbation doit rester compréhensible dans une petite équipe comme dans une organisation plus grande.

Vérifier les accès sans déclencher une notification réelle

La répétition peut utiliser une copie du formulaire ou les modalités d’exercice officiellement proposées par le canal applicable. Vérifiez la méthode autorisée avant tout essai. Un exercice interne ne doit pas être transmis comme un événement réel. L’équipe peut néanmoins confirmer que le compte prévu existe, que les droits sont appropriés et qu’un remplaçant peut accéder aux informations nécessaires. Les règles du portail restent une source opérationnelle à vérifier au moment de l’exercice.

Conservez le résultat de cette vérification : date, compte ou rôle examiné, limite identifiée et action corrective. Ne stockez ni mots de passe ni codes d’accès dans le dossier d’incident. Référencez le mécanisme de gestion des accès approuvé par l’organisation. Une capture de l’écran de connexion ne suffit pas à montrer qu’une personne dispose du droit de transmettre une notification ; l’exercice doit vérifier le parcours réellement disponible.

Garder une preuve de ce qui a été transmis

Le statut « envoyé » dans un registre interne décrit une déclaration de l’utilisateur. Pour démontrer une transmission, conservez la copie de la notification, son horodatage, l’identifiant ou l’accusé fourni par le canal et la personne ayant réalisé l’opération. Reliez ces éléments au dossier source. Si une information est corrigée ensuite, préservez la version précédente et le motif de la correction au lieu de remplacer silencieusement le contenu envoyé.

Le même principe vaut pour la communication aux utilisateurs. Identifiez les destinataires, le périmètre de la version concernée, le message approuvé et les informations pratiques nécessaires à la correction. Coordonnez cette communication avec les équipes responsables et les règles applicables. Un dossier CRA ne doit pas créer des messages contradictoires entre le support, l’ingénierie et la direction. La sélection des informations à communiquer demande une décision, notamment lorsqu’une divulgation augmente le risque.

Revoir la décision de ne pas signaler

Une décision négative exige également une trace. Indiquez les critères examinés, les faits disponibles et les raisons de la conclusion. La formulation « ticket mineur » ne montre pas que les notions réglementaires ont été appréciées. Fixez les éléments nouveaux qui déclencheraient une réévaluation : preuve d’exploitation, élargissement du périmètre ou découverte d’un impact différent. Le dossier reste ainsi utilisable si l’analyse change dans les heures qui suivent.

Cette pratique évite de traiter une première conclusion comme une vérité définitive. Elle ne signifie pas que tous les tickets doivent faire l’objet d’un dossier juridique complexe. Le niveau de documentation doit permettre d’expliquer une décision proportionnée au contexte. Les responsabilités de qualification et les exigences du CRA restent celles du fabricant concerné ; un outil d’IA ou un questionnaire interne ne peut pas transférer cette responsabilité.

Fermer la boucle après le correctif

La mise à disposition d’un correctif doit être reliée à la version distribuée, au résultat des essais et au traitement de l’événement. Vérifiez ce que la correction couvre et les limites qui restent connues. Un changement de code fusionné ne prouve pas que les utilisateurs disposent du correctif. Le dossier doit distinguer préparation, publication et communication, avec les pièces correspondant à chacune. Le rapport final est ensuite préparé sur cette histoire vérifiable.

Le besoin d’un rapport final et son délai suivent le type d’événement et les règles applicables. Les échéances présentées plus haut n’effacent pas les informations qui doivent encore être confirmées. Planifiez la personne responsable du suivi et les données nécessaires dès la première notification. Le dossier ne doit pas disparaître de l’attention de l’équipe dès que la mesure d’urgence est réalisée.

Mesurer l’exercice et corriger le processus

Après la répétition, examinez le temps nécessaire pour identifier le produit, retrouver les pièces et obtenir une décision. Comparez les observations à vos objectifs internes et aux délais applicables ; aucun chiffre de performance n’est garanti par ce guide. Une difficulté d’accès appelle une action sur les droits. Une qualification hésitante appelle une clarification des critères. Un remplaçant inconnu appelle une décision d’organisation.

Pulsar GRC peut conserver ces écarts, responsables et preuves de vérification. Il ne transmet pas automatiquement une notification depuis votre cloud et n’approuve pas la qualification réglementaire. Utilisez une démonstration sur données fictives pour vérifier le parcours des tâches et de l’historique. Les informations confidentielles, les accès au portail et la décision finale restent sous le contrôle des personnes désignées dans votre organisation.

Simuler un incident sans envoyer de déclaration réelle

Choisissez un produit fictif qui, selon votre exercice, relève de la portée du CRA. Si l’exemple inclut un SaaS ou un backend, expliquez pourquoi il est pertinent pour ce produit ; ne présumez pas que tous les services de navigateur uniquement relèvent de l’CRA. Utilisez une notification synthétique reçue en dehors des heures de bureau, une constatation technique et une décision qui nécessite un réviseur autorisé.

Enregistrez le moment où les participants à l’exercice prennent conscience des faits et distinguez ce moment de l’ouverture d’un ticket. Désignez l’enquêteur, le propriétaire de la décision et le remplaçant. Suivez quels faits sont établis et lesquels restent en cours d’examen. Les délais de l’article 14 concernent les conditions de prise de connaissance et de déclaration applicables, et pas simplement le moment où un responsable ouvre l’application.

Séparez la branche des vulnérabilités activement exploitées de la branche des incidents graves. Leurs conditions de rapport final diffèrent : le rapport de vulnérabilité comprend un délai lié à la disponibilité d’une mesure corrective ou atténuante, tandis que la branche incident grave dispose de son propre calendrier de rapport final. Utilisez le texte juridique en vigueur et les directives officielles en matière de reporting pour la branche que vous avez qualifiée.

Dans Pulsar, préparez les actions de l’exercice, les propriétaires, les délais et les preuves synthétiques. Enregistrez la décision du réviseur et toute information manquante. Vérifiez l’état final après la sauvegarde. Le résultat utile est une répétition documentée qui expose un substitut manquant ou une exigence de preuve avant qu’un événement réel ne se produise.

Ne soumettez pas d’exercice à l’ENISA, à un CSIRT ou à un vrai client. Le dossier de Pulsar ne constitue pas un récépissé officiel et l’essai public ne promet pas de rapport automatique aux autorités. Conservez une soumission réelle, son canal officiel et son reçu en tant qu’actions distinctes lors d’un incident réel. Consultez le mode de paiement et les conditions d’annulation de l’essai de 14 jours avant de vous inscrire.

Sources

CRA pour SaaS : portée, actions détenues et preuves

Vulnérabilités des composants IoT : fournisseurs, décisions et correctifs

KSC/NIS2 polonais pour les fournisseurs informatiques : évaluation et registre d’actions