Un système de management de la sécurité de l'information ne se résume ni à une collection d'outils cyber ni à une déclaration d'applicabilité copiée. Il relie un périmètre, des risques, des mesures, des responsabilités et des contrôles capables de montrer que les informations importantes restent protégées.
Définir un périmètre qui suit les activités
Commencez par les services, informations, sites, équipes, fournisseurs et technologies qui produisent la valeur à protéger. Un périmètre dessiné autour du seul service informatique masque les dépendances métier et les traitements externalisés. Décrivez aussi les interfaces avec le reste de l'organisation et justifiez les limites. La formulation doit permettre à un client et à un auditeur de comprendre ce qui est couvert. Toute acquisition, migration ou nouveau prestataire déclenche ensuite une revue de périmètre plutôt qu'une simple mise à jour de l'inventaire technique.
Rendre l'analyse de risques reproductible
La méthode définit les critères d'impact, de vraisemblance, d'acceptation et de réévaluation. Elle n'a pas besoin d'une précision mathématique artificielle ; elle doit produire des décisions comparables et explicables. Identifiez les scénarios avec les métiers, car l'indisponibilité, l'altération ou la divulgation n'ont pas le même effet selon le service. Pour chaque risque, conservez le propriétaire, l'évaluation, la décision de traitement et le risque résiduel accepté. Une liste d'actifs sans scénario ni arbitrage ne suffit pas à piloter.
Des repères publics à confronter au dossier
Certification ISO/IEC 27001 apporte un repère directement vérifiable : AFNOR présente ISO/IEC 27001 comme un système de management de la sécurité de l'information fondé sur l'identification des menaces, la maîtrise des risques et la protection de la confidentialité, de l'intégrité et de la disponibilité.
Sécurité et analyse de risques apporte un repère directement vérifiable : La CNIL relie l'étude des risques aux mesures de sécurité, recommande des audits périodiques et demande qu'ils débouchent sur un plan d'action suivi au plus haut niveau de l'organisme.
Guide d'hygiène informatique apporte un repère directement vérifiable : Le guide de l'ANSSI propose un état des lieux puis un plan d'action gradué autour de mesures concrètes de sécurité. Il constitue un socle opérationnel, sans se substituer à l'analyse de risques propre à l'organisation.
Relier les mesures aux risques et obligations
La déclaration d'applicabilité explique quelles mesures sont retenues, pourquoi elles le sont, leur état et les exclusions justifiées. Elle ne doit pas devenir un catalogue indépendant. Reliez chaque mesure à un risque, une exigence légale, un engagement client ou une pratique nécessaire. Une mesure annoncée comme mise en œuvre possède un responsable et une preuve observable. Lorsque plusieurs outils couvrent le même objectif, décrivez leur rôle plutôt que multiplier les cases. Cette cohérence facilite les tests et évite de découvrir pendant l'audit qu'une formulation ne correspond plus à l'architecture.
Tester l'efficacité, pas seulement la présence
Un contrôle d'accès configuré n'est pas automatiquement efficace. Échantillonnez les habilitations, simulez les procédures de reprise, examinez les alertes et suivez les écarts issus des incidents ou audits. Les indicateurs portent sur un objectif de sécurité et appellent une décision lorsqu'ils dérivent. La périodicité dépend du risque et du rythme de changement. Les résultats alimentent le plan d'amélioration et la revue de direction, avec les limites du test. Un taux vert sans protocole ni population observée ne démontre rien.
Articuler sécurité et protection des données
L'analyse de risques sécurité et l'analyse de risques pour les personnes peuvent partager des informations, mais leurs finalités ne sont pas identiques. Identifiez les traitements de données personnelles, les responsabilités et les obligations de notification sans supposer que la certification couvre automatiquement toute conformité. Les équipes sécurité, juridique et métiers définissent les points communs et conservent des décisions distinctes lorsque c'est nécessaire. Cette articulation réduit les doublons tout en évitant qu'un certificat soit présenté comme une garantie absolue de protection des données.
La fiche d'action pour ISO 27001 SMSI
- Écrire le périmètre avec les dépendances métier. Le dossier nomme le responsable, la date de revue et la preuve attendue.
- Appliquer une méthode de risque stable et explicable. Le dossier nomme le responsable, la date de revue et la preuve attendue.
- Relier chaque mesure à une raison et une preuve. Le dossier nomme le responsable, la date de revue et la preuve attendue.
- Tester l'efficacité sur des échantillons définis. Le dossier nomme le responsable, la date de revue et la preuve attendue.
- Présenter limites et décisions à la direction. Le dossier nomme le responsable, la date de revue et la preuve attendue.
Un cas qui révèle la méthode
Une entreprise externalise son support client dans un outil SaaS. Le fournisseur figure dans l'inventaire, mais le processus de suppression des comptes et l'export de données ne sont jamais testés. L'analyse de risques fait apparaître une dépendance opérationnelle et contractuelle. L'équipe ajoute des tests périodiques, clarifie les responsables et conserve les résultats, plutôt que de déclarer le risque traité sur la seule existence du contrat.
Les questions à poser pendant la prochaine revue
Pour le dossier « ISO 27001 SMSI », demandez d'abord ce qui a changé depuis la dernière décision, puis cherchez une preuve dans un cas récent plutôt qu'un exemple préparé. Reprenez notamment « Écrire le périmètre avec les dépendances métier. » et « Présenter limites et décisions à la direction. ». Qui utilise réellement cette information, quelle limite a été observée et quelle action serait déclenchée si le résultat se dégradait ? Faites reformuler la réponse par la personne qui exécute le processus. Si le support et la pratique racontent deux histoires différentes, notez l'écart sans fabriquer immédiatement un nouveau document. La revue sert à rendre une décision possible, pas à produire une apparence de maîtrise.
Tester la reprise par une autre personne
Confiez « ISO 27001:2022 : construire un SMSI piloté par les risques » à un collègue qui n'a pas préparé le dossier. Il doit retrouver le périmètre, les hypothèses, les pièces consultées, la dernière décision et l'action suivante sans interroger son auteur. Les hésitations révèlent une dépendance à la mémoire, une version ambiguë ou un classement trop personnel. Corrigez le chemin de preuve avant d'ajouter un contrôle. Cette passation courte mesure une qualité essentielle du système : sa capacité à continuer lorsque les rôles, les outils ou les équipes changent.
Garder une trace qui reste utile
Lors de chaque revue, choisissez quelques chaînes complètes : un risque, sa décision, la mesure appliquée, le test réalisé et l'action ouverte. Cette lecture révèle mieux les ruptures qu'une revue séparée de chaque registre. Pour « ISO 27001:2022 : construire un SMSI piloté par les risques », la trace finale indique aussi les limites de la vérification et le prochain événement qui imposera une nouvelle lecture.
Commentaires
Aucun commentaire pour le moment