ISO/IEC 27035 pour les PME : structurer sans complexifier

Et si chaque incident devenait un levier d’amélioration continue ? ISO 27035 vous aide à structurer la gestion des incidents, même sans SOC ni RSSI. Checklist, exemple concret et intégration GRC : tout ce qu’il faut pour démarrer simplement.

Par: Joachim Fontfreyde · 2025-06-20

La cybersécurité ne se limite pas à la détection ou à la mise en place de contrôles préventifs. Le cœur d’une approche mature repose aussi sur la capacité à bien gérer les incidents, de manière structurée, documentée et connectée à l’ensemble de votre dispositif de gouvernance.

C’est exactement ce que propose la norme ISO/IEC 27035, souvent moins connue que sa grande sœur ISO 27001, mais pourtant essentielle.

ISO 27035 : une norme pour structurer la réponse à incident

La norme ISO/IEC 27035 définit une approche méthodique de la gestion des incidents de sécurité de l’information. Elle ne se limite pas à l’intervention technique : elle fournit un cadre pour l’ensemble du cycle de vie d’un incident, depuis la préparation jusqu’à la clôture en passant par la communication et le retour d’expérience.

Elle repose sur 5 étapes principales :

1. Préparation (politiques, procédures, outils, rôles),
2. Identification (détection, qualification, enregistrement),
3. Évaluation (analyse de l’impact, priorisation),
4. Réponse (contenu de la remédiation, coordination),
5. Leçons tirées (analyse post-incident, amélioration continue).

Autrement dit : ISO 27035 ne vous dit pas uniquement quoi faire quand ça brûle, mais comment éviter que ça reprenne feu de la même façon.

Checklist ISO 27035 pour TPE/PME : par où commencer

La norme ISO 27035 demande en général énormément de documentation, avec des processus formalisés de détection, d’analyse, de réponse et de retour d’expérience sur les incidents.

Ces grands principes sont applicables même dans une petite structure, à condition d’en faire une version allégée et pragmatique.

Voici une checklist pensée pour les PME et startups, sans SOC ni CSIRT, mais qui veulent quand même structurer un minimum leur gestion des incidents :

• Un point de contact cybersécurité est-il désigné ?

  Il ne s’agit pas nécessairement d’un RSSI dédié. Il suffit d’une personne identifiée (souvent le responsable IT ou le CTO) qui saura coordonner les actions en cas d’incident, centraliser les informations et alerter les bonnes personnes.

• Avez-vous une procédure de remontée des incidents ?

  Même très simple (par exemple une fiche type), elle permet d’éviter que certains signaux faibles passent à la trappe. L’idée est d’avoir un réflexe : dès qu’un incident est détecté, on le documente, même sommairement.

• Les incidents sont-ils tracés quelque part ?

  Un fichier Excel ou un espace Notion peut suffire au début. L’objectif est de garder un historique, utile pour tirer des enseignements, identifier des récurrences, ou montrer à un auditeur que vous avez une démarche structurée.

• Une escalade est-elle prévue ?

  Si l’incident dépasse les compétences de l’équipe interne (chiffrement de fichiers, compromission de compte, etc.), savez-vous qui contacter ? Votre prestataire IT ? Un expert cybersécurité ? Un CSIRT externalisé ? Avoir ces contacts listés à l’avance évite la panique.

• Tirez-vous des leçons de vos incidents ?

  La norme insiste sur le retour d’expérience. À chaque incident, même bénin, prenez 10 minutes pour vous demander : que s’est-il passé ? Qu’est-ce qui a fonctionné ou pas ? Peut-on prévenir ça à l’avenir ? Même un simple commentaire ajouté à la ligne Excel peut initier une amélioration continue.

Cette checklist, est une excellente première brique pour aligner votre démarche sécurité avec les attendus d’ISO 27035.

Un incident au service de l’amélioration continue

Prenons un exemple:

L’équipe IT pensait avoir activé l’authentification multifacteur (MFA) sur l’ensemble des comptes à privilèges. C’était écrit dans la politique de sécurité, considéré comme “fait”, et souvent cité comme une mesure forte auprès de la direction.

Pourtant un opérateur détecte une activité suspecte sur un compte administrateur inactif depuis plusieurs mois. Après vérification, il s’avère que ce compte, oublié dans un coin de l’annuaire, n’avait pas le MFA activé. Pire : il était encore rattaché à des droits critiques sur les environnements cloud.

L’étude de cause profonde révèle une faille de gouvernance : la règle était bien définie, mais aucun contrôle récurrent ne permettait de vérifier réellement son application. C’était un “angle mort” de la sécurité.

Plutôt que de se contenter de corriger le problème ponctuellement, l’entreprise décide d’en tirer une leçon structurée, dans l’esprit d’ISO 27035 :

• Un contrôle mensuel est mis en place, pour auditer tous les comptes à privilèges et vérifier la présence effective du MFA.
• Une règle de détection est ajoutée dans le SIEM/SOC, pour alerter automatiquement lorsqu’un compte administrateur perd son MFA (désactivation manuelle, modification de configuration, etc.).
• Le processus de création de comptes est revu : désormais, aucun compte administrateur ne peut être validé sans preuve d’activation MFA, avec vérification croisée.

Cet exemple montre comment un incident apparemment simple peut devenir un levier d’amélioration continue, s’il est correctement analysé et capitalisé.

C’est exactement ce que promeut ISO 27035 : transformer chaque erreur ou faille en opportunité de renforcer le dispositif global.

Pourquoi l’intégrer à votre approche GRC ?

L’intérêt d’intégrer ISO 27035 dans votre outillage GRC, c’est de sortir la gestion d’incident de son silo technique pour l’intégrer au pilotage global.

Un incident de sécurité n’est pas qu’un événement opérationnel : c’est aussi un signal faible, un indicateur de maturité, et un déclencheur d’action.

Voici ce que ça change quand vous le faites bien :

• Vous tracez chaque incident de manière centralisée, avec son analyse, ses impacts, ses causes, et son traitement.
• Vous pouvez lier les incidents aux risques concernés, aux contrôles qui ont échoué, ou à ceux qu’il faudra renforcer.
• Vous alimentez votre pilotage de la sécurité avec des indicateurs tangibles : temps moyen de résolution, nombre d’incidents critiques non détectés, etc.

Cela transforme chaque incident en opportunité d’amélioration continue, au lieu de le traiter comme une simple crise à éteindre dans l’urgence.

👉 C’est exactement ce que propose Keepya : un outil GRC pensé pour rendre la conformité simple, traçable et intégrée.