ISO/CEI 27001

ISO 27001 – Annexe A.16 : Gestion des incidents de sécurité de l'information

Découvrez comment atteindre la norme ISO 27001 plus rapidement avec ISMS.online

Voir en action
Par Max Edwards | Mis à jour le 14 décembre 2023

Veuillez noter qu'en octobre 2022, la norme ISO 27001:2013 a été révisée et est désormais connue sous le nom d'ISO 27001:2022. Veuillez consulter la version révisée complète des contrôles de l'Annexe A de la norme ISO 27001 pour obtenir les informations les plus récentes.

Voir les contrôles révisés de l'annexe A.

Aller au sujet


Quel est l’objectif de l’annexe A.16.1 ?

L'annexe A.16.1 concerne la gestion des incidents, événements et faiblesses en matière de sécurité de l'information. L’objectif de ce domaine de l’annexe A est de garantir une approche cohérente et efficace du cycle de vie des incidents, des événements et des faiblesses. La norme ISO 27001:2013 aborde clairement le cycle de vie via A.16.1.1 à A.16.1.7 et constitue une partie importante du système de gestion de la sécurité de l'information (ISMS), en particulier si vous souhaitez obtenir la certification ISO 27001. Comprenons maintenant ces exigences et ce qu'elles signifient de manière un peu plus approfondie.

A.16.1.1 Responsabilités et procédures

Un bon contrôle décrit la façon dont la direction établit les responsabilités et les procédures afin d'assurer une réponse rapide, efficace et ordonnée pour remédier aux faiblesses, aux événements et aux incidents de sécurité. En termes simples, un incident est une perte de confidentialité, d'intégrité ou de disponibilité.

Un exemple est celui où une fenêtre est restée ouverte et qu'un voleur a volé un fichier important posé sur le bureau… Suite à ce fil, un événement est celui où la fenêtre est restée ouverte mais personne n'a volé le fichier. Une faiblesse est que la fenêtre est facilement cassée ou vieille et pourrait être un endroit évident pour une effraction. Une faiblesse est également une opportunité courante de gestion des risques ou d’amélioration.

Les procédures de planification de la réponse aux incidents, aux événements et aux faiblesses devront être clairement définies avant qu'un incident ne se produise et approuvées par vos dirigeants. Ces procédures sont assez faciles à développer car le reste de ce contrôle de l'annexe A les précise. Votre auditeur s’attendra à voir toutes ces procédures formelles et documentées en place et à prouver qu’elles fonctionnent.

A.16.1.2 Signalement des événements liés à la sécurité des informations

Un bon contrôle garantit ici que les incidents et événements liés à la sécurité des informations peuvent être signalés dans les plus brefs délais via des canaux de gestion appropriés.

Les employés et les parties intéressées associées (par exemple les fournisseurs) doivent être informés de leurs obligations de signaler les incidents de sécurité et vous devez couvrir cela dans le cadre de votre sensibilisation générale et de votre formation. Pour bien faire cela, ils devront être conscients de ce qui constitue exactement une faiblesse, un événement ou un incident en matière de sécurité de l'information. Soyez donc clair à ce sujet, en vous basant sur l'exemple simple ci-dessus. Si un événement lié à la sécurité des informations se produit ou semble s'être produit, il doit être immédiatement signalé à l'administrateur de la sécurité des informations désigné et doit être documenté en conséquence.

Certaines des raisons possibles pour signaler un incident de sécurité comprennent : contrôles de sécurité inefficaces ; des violations supposées de l'intégrité ou de la confidentialité des informations, ou des problèmes de disponibilité, par exemple l'impossibilité d'accéder à un service.

L'auditeur voudra voir et échantillonnera pour prouver qu'il est conscient de ce qui constitue une faiblesse, un événement ou un incident au sein de l'état-major, et qu'il est conscient des procédures et des responsabilités en matière de signalement des incidents.

A.16.1.3 Signalement des faiblesses en matière de sécurité des informations

Ce contrôle s'appuie simplement sur des incidents et des événements mais peut être traité légèrement différemment une fois signalé (voir A.16.1.4). Il est essentiel que les employés soient conscients du fait que lorsqu'ils découvrent une faille de sécurité, ils ne doivent pas tenter de prouver cette faiblesse. , car le tester peut être interprété comme une mauvaise utilisation du système, tout en risquant également d'endommager le système et ses informations stockées, provoquant des incidents de sécurité !

A.16.1.4 Évaluation et décision concernant les événements liés à la sécurité de l'information

Les événements liés à la sécurité de l'information doivent être évalués, puis il peut être décidé s'ils doivent être classés comme incidents de sécurité de l'information ou événements de faiblesse. Une fois qu’un événement de sécurité a été signalé puis enregistré, il devra alors être évalué afin de déterminer la meilleure marche à suivre. Cette action doit viser à minimiser toute compromission de la disponibilité, de l'intégrité ou de la confidentialité des informations et à prévenir de nouveaux incidents. Idéalement, cela aura un impact minimal sur les autres utilisateurs des services. La détermination des personnes exactes qui doivent être informées de l'incident, en interne (clients, fournisseurs, régulateurs), peut également avoir lieu dans cette partie du cycle de vie.

Le RGPD et la loi sur la protection des données de 2018 signifient que certains incidents de sécurité des informations liés aux données personnelles doivent également être signalés à l'autorité de surveillance. Vos contrôles doivent donc également tenir compte de ces considérations pour répondre aux exigences réglementaires et éviter les duplications ou les lacunes dans le travail.

A.16.1.5 Réponse aux incidents de sécurité de l'information

Il est toujours bon d'attribuer des propriétaires, d'être clair sur les actions et les délais et, comme pour tout ce qui concerne la norme ISO 27001, de conserver les informations à des fins d'audit (également essentiel si vous devez prendre en compte d'autres parties prenantes et régulateurs). La personne chargée de gérer l'événement de sécurité sera chargée de rétablir un niveau de sécurité normal tout en :

  • recueillir des preuves dès que possible après l'événement ;
  • effectuer une analyse médico-légale de la sécurité de l'information (terme général mais au moins être clair sur la cause profonde et les aspects associés ou sur ce qui s'est passé et qui était impliqué, pourquoi, etc.) ;
  • escalade, si nécessaire, par exemple vers les régulateurs concernés ;
  • s'assurer que toutes les activités d'intervention impliquées sont correctement enregistrées pour une analyse ultérieure ;
  • communiquer l'existence de l'incident de sécurité de l'information ou tout détail pertinent à la direction afin qu'ils soient ensuite communiqués à diverses personnes ou organisations en cas de besoin ; et
  • traiter les failles de sécurité de l’information qui ont causé ou contribué à l’incident.

A.16.1.6 Tirer les leçons des incidents de sécurité de l'information

Il s'agit d'un contrôle important et votre politique doit démontrer que les connaissances acquises lors de l'analyse et de la résolution des incidents de sécurité des informations seront utilisées pour contribuer à réduire la probabilité ou l'impact de tout incident futur. Dans le cadre de votre engagement envers l'amélioration continue du service, vous devez vous assurer que vous tirez les leçons de tout incident de sécurité afin de contribuer à l'évolution et à l'adaptation du SMSI pour répondre au paysage changeant dans lequel vous travaillez.

Une fois qu'un incident a été résolu, il doit être placé dans un état d'examen et d'apprentissage, où le principal intervenant pour cet incident discutera de tout changement requis dans les processus des politiques ISMS en conséquence. Toutes les recommandations pertinentes devraient ensuite être soumises au Conseil d'administration du SMSI pour une discussion plus approfondie. Une fois l'examen et l'apprentissage terminés, des mises à jour ont été apportées aux politiques selon les besoins, le personnel concerné doit être informé et recyclé si nécessaire, et le cycle de sensibilisation et d'éducation à la sécurité de l'information se poursuit.

A.16.1.7 Collecte de preuves

L'organisation doit définir et appliquer des contrôles pour l'identification, la collecte, l'acquisition et la conservation des informations, qui peuvent être utilisées comme preuve, en particulier si des poursuites pénales ou civiles sont susceptibles d'être engagées à la suite de l'incident.

Lorsque l’organisation soupçonne ou sait qu’un incident de sécurité peut entraîner des mesures juridiques ou disciplinaires, elle doit procéder à la collecte des preuves avec soin, garantir une bonne chaîne de contrôle et éviter toute menace d’être surprise par une mauvaise gestion.

Il est également judicieux de lier clairement la gestion des incidents de sécurité de l'information aux procédures disciplinaires. Tout le monde doit savoir prendre des précautions tout en étant clair sur les conséquences pour ceux qui ne les prennent pas au sérieux.

La conformité ne doit pas être compliquée.

Nous avons travaillé dur pour vous, vous offrant une longueur d'avance de 81 % dès votre connexion.
Il ne vous reste plus qu'à remplir les espaces vides.

Demander demo

Exigences ISO 27001


Contrôles ISO 27001 Annexe A


À propos d'ISO 27001


Explorez toutes les fonctionnalités de la plateforme


ISMS.online prend désormais en charge ISO 42001 – le premier système de gestion de l'IA au monde. Cliquez pour en découvrir davantage