Construire un SMSI – vers ISO 27001 étape par étape
Introduction
Construire un SMSI n'est pas un projet de documentation, mais une transformation du modèle opérationnel. La plupart des projets échoués que nous devons ensuite corriger présentaient deux symptômes : une bibliothèque de politiques complète sans effet visible dans les opérations quotidiennes – et une analyse des risques que personne dans les métiers ne comprend. La cause en est presque toujours l'absence d'une feuille de route progressive. L'ISO/IEC 27001:2022 exige que les clauses 4 à 10 soient mises en œuvre dans un ordre précis ; avancer certains points sans respecter cet ordre introduit des boucles correctives.
Nous présentons une feuille de route en 12 étapes, éprouvée dans les PME et les entreprises suisses de taille intermédiaire depuis plus de dix ans. Elle couvre :
- initialisation, définition du périmètre, cartographie des parties prenantes ;
- analyse des écarts (GAP) par rapport aux 93 contrôles de l'annexe A et aux clauses 4 à 10 ;
- méthode de gestion des risques, évaluation des risques, plan de traitement des risques et SoA ;
- bibliothèque de politiques, sensibilisation et mise en œuvre opérationnelle des contrôles ;
- audit interne, revue de direction, préparation des Stage 1 et Stage 2.
Le calendrier varie selon le niveau de maturité, mais la séquence est robuste. Chaque étape produit des artefacts que l'auditeur souhaitera voir concrètement par la suite. Nous indiquons à la fin de chaque bloc quel document ou quelle preuve est généré.
Étapes 1 à 3 – Initialisation, périmètre, parties prenantes
Étape 1 – Lancement du projet : sponsor au niveau de la direction, chef de projet dédié (responsable ISO), budget, calendrier, plan de communication. Nous recommandons un cycle de projet initial de 12 à 14 mois avec un comité de pilotage bimensuel et une charte de lancement documentée. Résultat : charte, matrice RACI.
Étape 2 – Définir le périmètre (clause 4) : quels domaines d'activité, sites, filiales, tenants cloud et produits font partie du SMSI ? Pour les entreprises SaaS, nous recommandons de commencer par le stack produit et l'équipe d'ingénierie – c'est la substance de la promesse client – et d'intégrer le marketing/les ventes/les RH l'année suivante. Une déclaration de périmètre contextualisée avec les inclusions et exclusions est un document obligatoire. Résultat : déclaration de périmètre.
Étape 3 – Parties prenantes et exigences (clause 4.2) : clients, autorités de surveillance (PFPDT, FINMA, OFSP), investisseurs, collaborateurs, fournisseurs – chaque groupe de parties prenantes apporte ses propres exigences (normes sectorielles, contrats, lois). Cette liste d'exigences est mise à jour lors de la revue annuelle de direction et sert ensuite d'intrant pour l'évaluation des risques. Résultat : registre des parties prenantes incluant les obligations de conformité.
Étapes 4 et 5 – Analyse des écarts et méthode de gestion des risques
Étape 4 – Analyse des écarts : évaluation du niveau de maturité par contrôle (0 = inexistant, 1 = ad hoc, 2 = documenté, 3 = mis en œuvre, 4 = mesuré, 5 = optimisé). Nous examinons les 93 contrôles de l'annexe A ainsi que les clauses 4 à 10. Le résultat est un aperçu en couleurs qui montre au comité de pilotage les priorités d'investissement. Dans la plupart des PME, nous partons d'une maturité moyenne de 1,5 et devons atteindre au moins 3,0 pour un audit de certification réussi. Résultat : rapport d'écarts avec feuille de route.
Étape 5 – Définir la méthode de gestion des risques (clause 6.1.2) : approche basée sur les actifs, les scénarios ou les processus ? Pour les premiers projets SMSI, une approche hybride a fait ses preuves : basée sur les processus (obligation : chaque processus métier est examiné une fois), complétée d'une analyse approfondie basée sur les actifs pour les systèmes les plus critiques. Les échelles de risques (3x3 ou 5x5) doivent être définies avant l'évaluation des risques, sinon l'échelle est ajustée a posteriori pour correspondre au niveau de risque souhaité – un constat classique d'audit. Résultat : document de méthode de gestion des risques incluant les critères d'acceptation des risques.
Étapes 6 et 7 – Évaluation des risques, SoA, traitement des risques
Étape 6 – Évaluation des risques et SoA (clause 6.1.3 / annexe A) : l'évaluation des risques génère le registre des risques. Du registre découle le plan de traitement des risques, dans lequel pour chaque risque significatif est décidé : éviter, réduire, transférer ou accepter. De là se dérive le Statement of Applicability (SoA) : une liste des 93 contrôles de l'annexe A avec l'applicabilité (oui/non), la justification et le statut de mise en œuvre actuel. Le SoA est le document le plus examiné lors de l'audit et doit être versionné. Résultat : registre des risques, plan de traitement des risques, SoA v1.
Étape 7 – Objectifs de sécurité de l'information et politiques (clause 6.2 / 5.2) : des objectifs mesurables sont dérivés des risques et du registre des parties prenantes (p. ex. « taux de clic phishing inférieur à 5 % », « couverture 100 % des correctifs pour les systèmes critiques dans les 14 jours »). La politique de sécurité de l'information elle-même est un document concis de 2 pages signé par le conseil d'administration. En dessous, une bibliothèque de politiques modulaire (12 à 18 politiques thématiques selon la complexité) : usage acceptable, contrôle des accès, cryptographie, sauvegarde, réponse aux incidents, sécurité des fournisseurs, etc. Résultat : bibliothèque de politiques, ensemble d'indicateurs clés.
Étapes 8 et 9 – Mise en œuvre des contrôles, sensibilisation
Étape 8 – Mise en œuvre opérationnelle des contrôles (clause 8 / annexe A) : le plan de traitement des risques se transforme en un backlog de mesures, mises en œuvre en sprints (ou en jalons pour les organisations projet classiques). Axes typiques :
- IAM et MFA (A.5.16, A.5.17, A.8.5)
- journalisation et supervision (A.8.15, A.8.16)
- sauvegarde et restauration (A.8.13)
- gestion des vulnérabilités et application des correctifs (A.8.8)
- sécurité des fournisseurs et accords de traitement des données (A.5.19–A.5.22)
- réponse aux incidents et communication de crise (A.5.24–A.5.27)
Les décisions d'outillage (SIEM, EDR, MDM, IAM, GRC) sont prises à cette phase – pas avant, sinon l'on achète sans exigences. Résultat : contrôles mis en œuvre avec preuves.
Étape 9 – Sensibilisation et formation (clause 7.2 / 7.3) : intégration obligatoire pour les nouveaux collaborateurs, rafraîchissement annuel, approfondissements par rôle pour l'IT, l'ingénierie, les RH, les ventes. Simulations de phishing au moins semestrielles. Sans taux de participation documenté supérieur à 95 %, l'auditeur posera des questions. Résultat : plan de formation et preuves de formation.
Étapes 10 et 11 – Audit interne et revue de direction
Étape 10 – Audit interne (clause 9.2) : avant l'audit de certification, au moins un audit interne complet doit avoir été réalisé selon un programme d'audit. L'auditeur doit être indépendant du domaine audité – dans les petites organisations, cela signifie en pratique : auditeur externe ou collègue déconnecté d'un autre département. L'audit porte à la fois sur la norme et sur les politiques internes. Les constatations sont catégorisées en Majeures/Mineures/Observations et assorties de mesures correctives.
Étape 11 – Revue de direction (clause 9.3) : au moins une fois par cycle, la direction se réunit et examine un ordre du jour prédéfini : statut des revues précédentes, changements dans les sujets externes/internes, atteinte des indicateurs, constatations des audits internes et externes, incidents, risques, potentiels d'amélioration, besoins en ressources. Le procès-verbal est signé par le CEO ou le COO. Dans les audits, ce procès-verbal est le deuxième document le plus important après le SoA. Résultat : programme d'audit interne, rapports d'audit, procès-verbal de la revue de direction avec décisions.
Étape 12 – Stage 1 et Stage 2
Stage 1 (revue documentaire / évaluation de la préparation) : l'organisme de certification examine l'information documentée – principalement le périmètre, la méthode de gestion des risques, le registre des risques, le SoA, le programme d'audit interne et le procès-verbal de la revue de direction. Le résultat est généralement une liste de « points d'attention » qui doivent être traités avant le Stage 2. Le Stage 1 dure 1 à 2 jours-personnes dans les PME et peut se dérouler à distance. C'est l'occasion de comprendre, avant le Stage 2, sur quoi l'auditeur va mettre l'accent.
Stage 2 (audit de mise en œuvre) : audit sur site ou hybride sur typiquement 3 à 6 jours-personnes selon la taille. L'efficacité est vérifiée – par des entretiens, des échantillons de journaux, des démonstrations, une inspection des sites physiques. Si l'auditeur trouve des non-conformités majeures, elles doivent être levées avant la délivrance du certificat ; les non-conformités mineures sont acceptées comme plan d'action avec délai. Après un Stage 2 réussi, l'organisme de certification délivre un certificat de trois ans. Résultat : rapport de certification et certificat ISO/IEC 27001:2022.
Une erreur fréquente lors de la première année : après la certification, la discipline se relâche. Les audits de surveillance en années 1 et 2 sont stricts – sans discipline PDCA continue, vous risquez une suspension du certificat. Planifiez donc l'année 1 après la certification avec la même capacité que l'année de mise en place.
Comment SIDD vous accompagne
SIDD accompagne les PME et les entreprises de taille intermédiaire de manière pragmatique à travers les douze étapes – soit comme implémentation ISO 27001 complète, soit comme coaching support modulaire lorsque vous disposez de compétences sécurité internes mais souhaitez acquérir méthodologie et expérience. Pour le rôle opérationnel de responsable ISO, nous mettons à disposition si nécessaire un CISO / responsable de la sécurité de l'information externe, qui prend en charge la méthode de gestion des risques, l'audit interne, la revue de direction et l'accompagnement continu des audits.
Sur le plan opérationnel, nous complétons l'implémentation typiquement par nos analyses de vulnérabilités et tests d'intrusion (pentests) comme preuves pour l'annexe A.8.8, ainsi que des ateliers de sécurité informatique comme éléments de sensibilisation. Pour une première évaluation de votre niveau de maturité actuel, contactez-nous via le formulaire de contact. Si vous connaissez déjà le périmètre et l'objectif de certification, demandez une offre – nous livrons dans les cinq jours ouvrables une proposition à prix fixe incluant une feuille de route sur 12 mois.
