ISO 27001 · le plan de réponse aux incidents
Le plan de réponse aux incidents, rédigé à partir de quelques réponses
Un incident est bien ou mal traité dans la première heure, et le plan est ce que la première heure lit ; cette page le rédige donc avant qu'il soit nécessaire : qui dirige et qui supplée, comment chacun signale un événement, comment il est jugé faible, moyen ou élevé, les cinq étapes de la réponse, quels délais réglementaires démarrent à la prise de connaissance, quelles preuves sont conservées, ce qui est revu après coup et à quelle fréquence le plan est exercé.
Le plan
Chaque partie que les mesures demandent, dans l'ordre où un incident se déroule ; une entrée vide est écrite comme un blanc à remplir, pas omise.
# Plan de réponse aux incidents de sécurité de l'information : [entreprise] Responsable de l'incident : [le responsable de l'incident] · Suppléant : [le suppléant] · Approuvé par : [la direction] Rédigé le avec la page gratuite de getstandardos.com contre les mesures de l'annexe A sur la gestion des incidents de l'ISO/IEC 27001:2022. La formulation est celle de StandardOS ; les délais réglementaires sont lus depuis le paquet qui alimente aussi les pages de délais RGPD, NIS2 et CRA. ## 1. Objet et périmètre Ce plan dit ce que [entreprise] fait depuis le moment où un événement de sécurité de l'information est remarqué jusqu'à ce que l'incident soit clos et ses leçons appliquées. Il couvre chaque système, service et site dans le périmètre du système de management, chaque personne travaillant sous le contrôle de l'entreprise, et les fournisseurs dont les incidents atteignent les données ou les clients de l'entreprise. ## 2. Rôles - [le responsable de l'incident] dirige chaque incident : le déclare, fixe la gravité, conduit la réponse, décide des notifications, clôt l'incident et porte la revue après coup. - [le suppléant] supplée quand le responsable n'est pas disponible, avec la même autorité, et les deux ne sont jamais injoignables le même jour. - Tout le monde signale : toute personne qui remarque un événement le signale aussitôt par le canal ci-dessous, et personne n'a besoin d'une permission pour signaler. - Seuls [le responsable de l'incident] ou la direction parlent aux clients, aux autorités ou à la presse d'un incident ; personne d'autre n'en confirme ni n'en nie un. ## 3. Signaler un événement Un événement est signalé par [à compléter], à toute heure. Un signalement n'est jamais fautif d'être précoce ou de s'avérer sans suite ; l'événement vu et non signalé est l'échec. Un signalement dit ce qui a été vu, où, quand, par qui, et ce qui a déjà été fait ; il n'attend pas que la cause ou l'impact soient connus. ## 4. Évaluation et gravité [le responsable de l'incident] décide dans l'heure si l'événement est un incident et fixe l'un des trois niveaux de gravité, révisé à mesure que le tableau change : - Faible: un système ou une personne touché, aucune donnée personnelle ni donnée client exposée, aucun service interrompu ; traité par l'équipe aux heures de bureau, revu à la réunion hebdomadaire suivante. - Moyen: des données client ou un service destiné aux clients touchés, contenu dans la journée ; le responsable le conduit, les clients dont les données ou le service sont touchés sont informés, les délais réglementaires sont vérifiés. - Élevé: exposition confirmée de données personnelles, un service interrompu pour les clients, un rançongiciel ou un attaquant disposant d'un accès ; tout le monde sur le pont, la direction informée dans l'heure, les délais réglementaires démarrent, une aide extérieure engagée là où l'équipe ne peut pas contenir seule. ## 5. La réponse 1. Contenir : arrêter d'abord la propagation, isoler le système, révoquer l'identifiant, bloquer l'adresse, mettre le service hors ligne s'il le faut ; le confinement avant la compréhension. 2. Évaluer : établir ce qui s'est passé, ce qui est touché, si des données personnelles ou des données client sont en cause, et depuis quand ; l'écrire à mesure que c'est appris, avec l'heure de chaque constat. 3. Éradiquer : supprimer la cause, le logiciel malveillant, le compte, la vulnérabilité, la mauvaise configuration, et confirmer qu'elle a disparu avant de restaurer quoi que ce soit. 4. Rétablir : restaurer depuis des sauvegardes saines ou reconstruire, vérifier le service, le surveiller de près les jours suivants, et lever les mesures de confinement dans l'ordre. 5. Communiquer : tenir un journal d'incident ouvert dès la première minute, informer les personnes de l'entreprise qui doivent agir, et informer les clients, les autorités et les partenaires comme le plan et les délais ci-dessous l'exigent, dans cet ordre. Outils : [à compléter]. ## 6. Notifications et délais réglementaires Chaque délai ci-dessous court à partir du moment de la prise de connaissance, pas du moment où la cause est trouvée ; le responsable enregistre ce moment dans le journal lorsque l'incident est déclaré. [Aucun règlement n'a été sélectionné. Si l'entreprise détient des données personnelles, est une entité essentielle ou importante, fabrique un produit comportant des éléments numériques ou sert des entités financières, le délai correspondant a sa place ici.] À l'extérieur de l'entreprise, nous informons : [à compléter]. ## 7. Preuves Dès la première minute, le responsable préserve ce dont une enquête ultérieure, un assureur, une autorité ou un tribunal pourrait avoir besoin : le journal d'incident avec les heures, les journaux et alertes en copies exportées, les images disque et mémoire là où un attaquant était présent, les messages envoyés et reçus, et les décisions avec qui les a prises ; les originaux restent intacts, on travaille sur des copies, et la chaîne de qui a détenu quoi est enregistrée. ## 8. Tirer les leçons de l'incident Dans les 10 jours suivant la clôture d'un incident de gravité moyenne ou élevée, [le responsable de l'incident] tient une revue avec les personnes impliquées : ce qui s'est passé, ce qui a fonctionné, ce qui n'a pas fonctionné, et quelle mesure, procédure ou formation l'a laissé se produire. Chaque cause devient une action corrective avec un responsable et une date, et l'incident et ses actions sont un élément d'entrée de la prochaine revue de direction. ## 9. Exercices Le plan est exercé une fois par an sur table, sur un scénario écrit, avec le responsable, le suppléant et les personnes qui agiraient, et le plan est modifié là où l'exercice le montre faux. ## 10. Enregistrements Chaque événement signalé, devenu incident ou non, est enregistré avec sa date, son évaluation et son issue ; le journal d'incident, les notifications envoyées et la revue sont conservés comme information documentée du système de management, disponibles pour l'organisme de certification, et comptés dans la revue de direction. Approuvé par [la direction] le [date]. Revu après chaque incident de gravité élevée, après chaque exercice, et au moins une fois par an. Ce plan est rédigé à partir des réponses données. Ce n'est pas un conseil en certification ni un conseil juridique ; l'organisme de certification lit le plan pour les rôles, la procédure, les enregistrements et les preuves qu'il est suivi, et les délais réglementaires se lisent contre les règlements eux-mêmes.
Dans StandardOS, le dossier d'incident fait tourner les délais
Un incident ouvert dans StandardOS porte l'heure de la prise de connaissance, la gravité, le journal et les preuves, démarre les délais RGPD, NIS2 et CRA qui s'appliquent à l'entreprise, rédige les notifications, ouvre les actions correctives issues de la revue et compte l'incident dans la prochaine revue de direction.
Le délai de violation RGPDLe délai d'incident NIS2Les délais de signalement CRALa fiche d'action corrective