ISO 27035 : gérer les incidents de sécurité

ISO 27035 est la série de normes internationales consacrée à la gestion des incidents de sécurité de l'information : se préparer, détecter, apprécier, répondre et tirer les enseignements. Elle ne remplace pas les obligations légales, mais elle donne le cadre qui permet de les tenir : NIS 2 demande une alerte en 24 heures, DORA une notification en quelques heures, le RGPD une notification à la CNIL en 72 heures.

ISO/IEC 27035 appartient à la famille ISO/IEC 27000. Publiée conjointement par l'ISO et la Commission électrotechnique internationale (CEI), elle compte aujourd'hui quatre parties, toutes intitulées Information security incident management.

ISO 27035 distingue deux notions. Un événement de sécurité est quelque chose que l'on observe et qui pourrait concerner la sécurité : une alerte de l'antivirus, une connexion à une heure inhabituelle, un courriel suspect signalé par un salarié. Un incident est un événement, ou une suite d'événements, dont on a établi qu'il porte atteinte, ou risque fortement de porter atteinte, à la sécurité de l'information.

Le passage de l'un à l'autre ne se fait pas tout seul : il résulte d'une appréciation. Comme le résume le commentaire ISO27k, les événements peuvent être, ou devenir, des incidents, et il faut les examiner pour en décider. Cette étape évite deux écueils opposés : traiter chaque alerte comme une crise, ce qui épuise les équipes, ou laisser passer un vrai incident faute de qualification. C'est aussi là que se décide si une notification réglementaire est due.

Le sommaire public d'ISO/IEC 27035-1:2023 décrit le processus en cinq phases. Le schéma ci-dessous les enchaîne et montre le tri qui s'opère à l'appréciation : une alerte sans suite sort du circuit, un incident confirmé va jusqu'au bout et nourrit le retour d'expérience.

ISO 27035 est une norme volontaire : on ne certifie pas une organisation ISO 27035. Elle sert surtout à mettre en œuvre les exigences d'ISO 27001 sur les incidents. L'annexe A d'ISO 27001:2022 contient en effet une série de mesures dédiées, rappelées par l'organisme de certification DQS : planification et préparation de la gestion des incidents (5.24), appréciation des événements et prise de décision (5.25), réponse aux incidents (5.26), tirer des enseignements des incidents (5.27) et collecte des preuves (5.28). On y reconnaît presque mot pour mot les phases d'ISO 27035.

Pour une organisation qui construit son système de management de la sécurité de l'information, la combinaison est donc naturelle : ISO 27001 fixe ce qui doit exister, ISO 27035 décrit comment l'organiser. Notre guide ISO 27001 détaille le reste du référentiel.

ISO 27035 ne fixe pas de délai de notification : ce sont les textes qui s'en chargent, et un même incident peut en déclencher plusieurs.

• NIS 2. Pour un incident important, la directive (UE) 2022/2555 prévoit, selon la présentation de la Commission européenne, une alerte précoce dans les 24 heures après en avoir pris connaissance, une notification d'incident dans les 72 heures et un rapport final au plus tard un mois après la notification, adressés au CSIRT ou à l'autorité compétente. En France, la transposition passe par le projet de loi résilience, qui n'est pas encore adopté ; notre article sur la loi résilience et notre guide NIS 2 font le point.
• DORA. Pour les entités financières, le règlement (UE) 2022/2554 s'applique depuis le 17 janvier 2025. Le règlement délégué (UE) 2025/301 fixe les délais pour un incident majeur lié aux technologies de l'information et de la communication (TIC) : notification initiale dans les 4 heures suivant son classement comme majeur, et au plus tard 24 heures après en avoir pris connaissance ; rapport intermédiaire dans les 72 heures suivant la notification initiale ; rapport final au plus tard un mois après le dernier rapport intermédiaire. Les déclarations vont à l'autorité de supervision compétente, par exemple l'AMF pour les entités qu'elle supervise. Voir notre guide DORA.
• RGPD. Si l'incident est une violation de données personnelles présentant un risque pour les personnes, il faut la notifier à la CNIL dans les meilleurs délais, si possible dans les 72 heures après en avoir pris connaissance, en plusieurs temps si nécessaire. Les personnes concernées doivent être informées si le risque est élevé. Toute violation, même non notifiée, est documentée en interne.

Le schéma suivant superpose ces horloges pour un incident qui cumulerait les trois régimes, par exemple une attaque chez une entité financière qui expose des données de clients.

• Écrire une politique courte signée par la direction : périmètre, rôles, critères de gravité, règles d'escalade.
• Définir une grille de qualification qui intègre les seuils réglementaires : incident important au sens de NIS 2, incident majeur au sens de DORA, violation de données au sens du RGPD.
• Tenir un registre des événements et des incidents, avec les horodatages de détection, de qualification et de notification.
• Préparer des fiches réflexes pour les scénarios les plus probables : rançongiciel (voir notre article sur les rançongiciels qui entrent par les équipements de bordure), compromission de messagerie, fuite de données.
• Garder hors ligne les contacts d'urgence, la cartographie et les procédures.
• S'exercer au moins une fois par an, puis appliquer la cinquième phase : corriger ce que l'exercice a révélé.

La gestion des incidents fait partie des mesures de gestion des risques que NIS 2 impose aux entités concernées. Pour piloter l'ensemble de ces exigences, consultez notre page logiciel de conformité NIS 2.