ISO 27001 & SMSI
ISO 27001 : la conformité ne se documente pas seulement, elle se pilote
La conformité ISO 27001 est souvent abordée sous l’angle des documents à produire, des mesures de sécurité à mettre en œuvre ou de l’audit à préparer.
Le véritable enjeu commence lorsque l’organisation doit faire vivre son SMSI dans le temps : suivre les risques, maintenir sa cartographie, traiter les incidents, conserver les preuves, piloter les actions et donner à la Direction une vision claire de la situation.
Le point de départ
Structurer avant de vouloir certifier
Toutes les organisations qui s’appuient sur ISO 27001 n’ont pas nécessairement pour objectif immédiat d’obtenir une certification.
Pour une PME ou une ETI, la norme constitue déjà un excellent cadre pour structurer la cybersécurité, clarifier les responsabilités, organiser la gestion des risques et construire progressivement une gouvernance de la sécurité de l’information.
ISO 27001 n’est pas une liste de produits de sécurité à installer. Elle repose sur un système de management : contexte, gouvernance, gestion des risques, politiques, responsabilités, mesures de sécurité, surveillance, audits et amélioration continue.
La vraie question
L’organisation sait-elle expliquer pourquoi une mesure existe, quel risque elle permet de traiter, qui en est responsable et comment elle peut démontrer qu’elle fonctionne réellement ?
Installer un nouveau firewall, activer le MFA ou renforcer les sauvegardes peut être nécessaire. Mais la conformité demande également de relier ces mesures aux risques, aux responsabilités et aux preuves.
Le terrain d’abord
Tout commence par un atelier… et parfois une feuille de papier
Avant la GRC, les tableaux de bord et les outils de pilotage, il y a généralement une réunion.
Autour de la table : Direction, DSI, RSSI lorsqu’il existe, responsables métiers, RH, qualité ou encore prestataires selon le contexte.
Il faut définir ce que l’on cherche à protéger, pourquoi l’organisation engage la démarche, quelles sont ses contraintes, quelles activités sont critiques et où se situent les principaux écarts.
Une procédure existe mais n’est pas formalisée.
Une sauvegarde est réalisée mais son dernier test de restauration est difficile à retrouver.
Une application critique dépend d’un prestataire absent de la cartographie.
Une responsabilité supposée attribuée ne l’est finalement à personne.
C’est précisément pour cela qu’une Gap Analysis reste une excellente première étape. Elle permet de confronter les exigences de la norme à la situation réelle et d’identifier les écarts avant de construire un plan d’action.
Dans sa version 2022, ISO 27001 s’appuie notamment sur les clauses 4 à 10 et sur 93 mesures de l’Annexe A réparties en quatre grandes familles.
Checklist Gap Analysis ISO 27001
Un support simple pour préparer les ateliers, évaluer la situation existante, identifier les écarts et construire les premières actions.
À ce stade, inutile de transformer immédiatement la démarche en projet logiciel complexe. Un tableau Excel, quelques ateliers bien préparés et des décisions clairement consignées peuvent largement suffire.
Gouvernance
Donner au projet un cadre et une légitimité
Une démarche ISO 27001 ne peut pas reposer durablement sur le seul volontarisme du DSI ou du RSSI.
Elle nécessite un engagement de la Direction et un minimum de gouvernance. La première étape consiste donc à formaliser le projet : objectifs, périmètre prévisionnel, pilote, acteurs concernés et soutien de la Direction.
Pourquoi l’organisation engage-t-elle la démarche ?
Une responsabilité claire est nécessaire pour faire avancer le projet.
La sécurité de l’information dépasse largement le périmètre de l’IT.
Les activités et entités concernées doivent être clairement identifiées.
Lettre de cadrage ISO 27001
Un modèle Word pour formaliser les objectifs, le périmètre prévisionnel, le pilote, les enjeux et l’engagement de la Direction.
Périmètre & responsabilités
Définir ce qui fait réellement partie du SMSI
Une organisation doit pouvoir expliquer précisément quelles activités, quels sites, quels systèmes et quelles entités sont concernés par son SMSI.
Un périmètre trop vague devient rapidement impossible à piloter. À l’inverse, certaines exclusions artificielles peuvent rendre la démarche incohérente.
Il faut également documenter les dépendances avec les éléments situés hors périmètre : prestataires, applications SaaS, infrastructures externalisées, filiales ou processus connexes.
Le périmètre doit rester compréhensible
Il ne s’agit pas seulement de décrire ce qui est inclus. Il faut également comprendre les dépendances, les responsabilités et les interfaces avec le reste de l’organisation.
Déclaration de périmètre + gouvernance
Un modèle Word pour formaliser le périmètre du SMSI, les dépendances, les instances de gouvernance et les responsabilités.
Politique de sécurité
Une PSSI ne doit pas devenir un document que personne ne lit
La Politique de Sécurité des Systèmes d’Information constitue naturellement l’un des documents structurants de la démarche.
Mais sa valeur ne dépend pas de son nombre de pages.
Une PSSI utile doit poser les principes essentiels : engagement de la Direction, champ d’application, responsabilités, règles de sécurité, comportement attendu des utilisateurs et modalités de diffusion et de révision.
Une PSSI générique ne crée pas de sécurité
Un modèle téléchargé, renommé puis signé sans confrontation avec la réalité de l’organisation n’apporte qu’une conformité de façade.
Une politique courte, comprise et réellement appliquée aura toujours plus de valeur qu’un document particulièrement détaillé qui restera oublié dans une GED.
Politique de sécurité des systèmes d’information
Une base de travail Word à adapter à votre organisation, à votre périmètre, à vos risques et à vos règles internes.
Applicabilité
La SoA : relier les exigences aux choix de l’organisation
La Déclaration d’Applicabilité, ou SoA — Statement of Applicability — constitue l’un des documents centraux d’une démarche ISO 27001.
Elle permet de reprendre les mesures de l’Annexe A, d’indiquer celles qui sont applicables, leur niveau de mise en œuvre et les justifications associées.
La mesure est-elle applicable au contexte de l’organisation ?
Les choix d’application ou d’exclusion doivent être expliqués.
Une mesure déclarée mise en œuvre doit pouvoir être prouvée.
Une mesure applicable mais non mise en œuvre devient potentiellement une action. Une mesure non applicable nécessite une justification. Une mesure annoncée comme déployée doit pouvoir être démontrée.
Nous commençons alors à quitter le simple domaine documentaire.
Déclaration d’applicabilité (SoA)
Un modèle Excel permettant de suivre les mesures de l’Annexe A, leur applicabilité, leur état de mise en œuvre et les justifications.
Pilotage projet
ISO 27001 est aussi un projet
On l’oublie parfois derrière les termes de conformité, SMSI ou gestion des risques : une démarche ISO 27001 reste un projet transverse.
Il y a des étapes, des responsabilités, des dépendances, des arbitrages, des livrables et des échéances.
Et comme dans n’importe quel projet, ce qui n’est attribué à personne finit souvent par ne pas être réalisé.
Planning projet + RACI ISO 27001
Le document regroupe les phases du projet, les principaux jalons, les responsables, les livrables, le planning et la matrice RACI.
Ce n’est certainement pas la partie la plus spectaculaire du projet. Mais elle est presque inévitable.
Le changement d’échelle
Puis vient le moment où Excel commence à montrer ses limites
Jusqu’ici, beaucoup de choses peuvent parfaitement être réalisées avec des outils bureautiques.
Et il n’y a rien de problématique à cela.
Excel, une GED correctement organisée, un outil de tickets et un calendrier partagé permettent déjà d’aller très loin.
Les outils ne créent pas la conformité
Un SMSI commence par des décisions, des responsabilités, des ateliers et une compréhension partagée des risques. Le logiciel intervient ensuite pour faciliter le pilotage.
Le problème apparaît progressivement lorsque le SMSI commence réellement à vivre.
La cartographie évolue et de nouvelles applications apparaissent.
Les prestataires et les dépendances changent.
Les risques sont réévalués au fil des événements.
Des incidents surviennent et des audits produisent de nouveaux constats.
Les actions, documents, échéances et responsabilités évoluent.
Quelques mois plus tard, il faut être capable de reconstituer ce qui a été décidé, réalisé, vérifié et amélioré.
La difficulté change de nature
Il ne s’agit plus simplement de documenter. Il faut désormais piloter dans le temps et conserver la capacité de démontrer.
Le cœur du SMSI
Documenter, piloter, démontrer
Ces trois notions sont proches, mais elles ne désignent pas la même chose.
Formaliser une règle, une décision, un risque, une procédure ou une action.
Suivre l’évolution, identifier les écarts, affecter les responsabilités et décider des priorités.
Retrouver la preuve qu’une action annoncée a réellement été effectuée.
Dire qu’une restauration de sauvegarde est testée périodiquement n’a pas la même valeur que pouvoir présenter la date du dernier test, son résultat, le compte rendu associé et les éventuelles actions correctives.
La preuve fait partie de l’action
Un SMSI mature ne reconstruit pas ses preuves à l’approche d’un audit. Il conserve naturellement son historique au fil de l’activité.
C’est également pour cette raison que l’audit ne devrait jamais être considéré comme un sprint final.
Un SMSI crédible montre une histoire.
Faire vivre le SMSI
ORKA : soutenir le pilotage, pas remplacer la démarche
Une fois le cadrage, la Gap Analysis, la PSSI, la SoA et les premiers plans d’action réalisés, le SMSI commence véritablement à prendre forme.
Il rassemble progressivement les politiques, les procédures, la cartographie, les risques, les incidents, les audits, les plans de traitement, les preuves, les indicateurs et les revues régulières.
Ces informations ne sont pas indépendantes les unes des autres.
Applications, infrastructures, sites et flux structurent la cartographie.
Risques, incidents, audits et situations prennent leur contexte.
Tableaux de bord et rapports consolident une vision exploitable.
Une application critique est liée à des infrastructures et à des flux. Elle peut être exposée à certains risques. Un incident peut remettre en cause l’évaluation de ces risques. Un audit peut identifier un écart. Cet écart peut produire une action.
Cette action doit avoir un responsable et une échéance. Et la Direction doit pouvoir disposer d’une vision consolidée de l’ensemble.
ORKA ne remplace pas ISO 27001
Un logiciel ne déterminera jamais à votre place ce qui constitue un risque acceptable, ne définira pas automatiquement votre périmètre et ne remplacera pas les décisions de la Direction ou le travail du RSSI.
En revanche, lorsque la démarche est engagée, disposer d’un environnement commun permet de maintenir une vision cohérente du SMSI.
Applications, infrastructures, sites et flux participent à la cartographie du SI.
Les risques sont suivis dans leur propre registre.
Les incidents conservent les événements de sécurité et leur traitement.
Les alertes CERT apportent un niveau complémentaire de surveillance.
Les audits permettent de conserver les constats et leur évolution.
Les situations suivent les sujets nécessitant une attention particulière.
Les documents restent accessibles dans le référentiel.
Les tableaux de bord et rapports facilitent le pilotage dans le temps.
La philosophie ORKA
Ce n’est pas ISO 27001 qui doit s’adapter à l’outil.
C’est l’outil qui doit accompagner la manière dont l’organisation décide de faire vivre son SMSI.
Ressources pratiques
Les modèles ISO 27001 à télécharger
Pour faciliter le démarrage de la démarche, nous mettons à disposition les principaux documents utilisés dans cet article.
Kit complet ISO 27001
Tous les modèles dans une seule archive
Retrouvez la lettre de cadrage, la Gap Analysis, le périmètre et la gouvernance, la PSSI, la SoA ainsi que le planning et le RACI dans une archive unique.
Des modèles à adapter
Ces documents constituent des supports de travail. Ils doivent être adaptés à votre organisation, à votre périmètre, à vos risques et à vos objectifs.
Amélioration continue
La conformité n’est pas un état
Une organisation ne devient pas « conforme » une fois pour toutes parce qu’elle a produit une PSSI, une analyse de risques et quelques procédures.
La sécurité de l’information repose sur une boucle permanente : observer, évaluer, décider, agir, contrôler et améliorer.
ISO 27001 donne un cadre particulièrement solide à cette démarche. Les premiers outils peuvent être très simples.
L’essentiel est de ne pas perdre ce qui fait progressivement la valeur du SMSI : sa cohérence, son historique, ses responsabilités et sa capacité à démontrer ce qui est réellement fait.
Le principe à retenir
La conformité ne se documente pas seulement. Elle se pilote.
C’est là que se situe la différence entre une conformité documentaire et une véritable gouvernance de la sécurité de l’information.