Que garantit réellement une certification ISO 27001

La certification ISO/IEC 27001 (International Organization for Standardization et International Electrotechnical Commission) atteste la conformité d’un système de management de la sécurité de l’information à une norme, dans un périmètre donné et à une date donnée. Elle ne certifie ni l’absence d’incident, ni l’invulnérabilité des systèmes, ni la qualité de chaque ligne de code.

→ Lire l’explication complète de la marmotte

Certification ISO 27001 : la garantie réelle, et sa frontière

ISO/IEC 27001 porte sur un système de management de la sécurité de l’information, ou SMSI. Un SMSI organise la manière d’identifier les risques, de choisir des mesures, de désigner des responsables, de contrôler leur exécution et de corriger les écarts. Le certificat atteste qu’un organisme certificateur indépendant a audité ce système et l’a jugé conforme aux exigences applicables de la norme.

Cette formulation compte. Le certificat ne dit pas « les systèmes sont sécurisés ». Il dit : « le système de management décrit dans le périmètre certifié respecte les exigences de la norme et produit des éléments vérifiables ». La différence paraît sémantique jusqu’au premier incident, puis elle devient très concrète.

La certification garantit notamment :

l’existence d’un périmètre documenté, avec activités, sites, services et interfaces inclus ou exclus ;
une méthode d’appréciation des risques, avec des critères de vraisemblance et d’impact définis ;
un plan de traitement des risques approuvé, suivi et révisé ;
une déclaration d’applicabilité, ou SoA (Statement of Applicability), qui justifie les mesures retenues, écartées ou déjà couvertes ;
des audits internes, une revue de direction, des actions correctives et une amélioration continue ;
un audit périodique par un tiers, fondé sur des entretiens, des échantillons et des preuves.

Elle ne garantit pas qu’un contrôle est exhaustif. Un auditeur vérifie un échantillon, pas chaque compte d’administration, chaque règle de pare-feu ni chaque secret stocké dans une chaîne d’intégration. Une politique de revue trimestrielle des accès peut être certifiée alors que la revue porte sur une source d’identités incomplète. Le processus existe, les preuves existent, mais le système cible reste mal inventorié. La conformité administrative a alors gagné contre la sécurité opérationnelle. C’est un sport connu, avec beaucoup de tableaux colorés et assez peu de sommeil.

Le compromis central est net : ISO 27001 apporte de la répétabilité, de la traçabilité et une pression structurante sur les écarts, au prix d’une charge de preuve continue. La recommandation est de viser la certification lorsque le périmètre peut être réellement gouverné et mesuré. La viser pour rassurer un appel d’offres sans capacité d’exploitation transforme le SMSI en décor de théâtre, avec des procédures qui applaudissent toutes seules.

Périmètre certifié et déclaration d’applicabilité

Le périmètre est la première limite de toute garantie. Un certificat couvrant « l’hébergement d’une plateforme » ne couvre pas automatiquement les postes d’administration, les fournisseurs d’identité, les filiales, les environnements de développement ou les outils de support. Il faut lire la formulation exacte du périmètre, puis cartographier les dépendances qui franchissent sa frontière.

Une exclusion peut être légitime si le service concerné est réellement hors de responsabilité. Elle devient dangereuse lorsque le périmètre évite précisément les composants qui portent le risque : annuaire d’entreprise, poste d’administration, pipeline de déploiement, sauvegarde mutualisée ou fournisseur de cloud. Un serveur certifié ne résiste pas mieux à un compte administrateur compromis situé hors périmètre.

La déclaration d’applicabilité relie l’analyse de risques aux contrôles sélectionnés. Depuis l’édition 2022, l’annexe A d’ISO/IEC 27001 regroupe 93 contrôles organisés en thèmes organisationnels, humains, physiques et technologiques. Ces contrôles ne sont pas une liste de courses à cocher avec une latte de café tiède. Chaque contrôle retenu doit avoir une justification, un propriétaire, une mise en œuvre et une méthode de vérification.

L’analyse de risques doit partir des actifs, processus, dépendances et scénarios d’attaque réels. Un risque « perte de données » sans système concerné, vecteur d’attaque, seuil d’acceptation ni responsable de traitement ne permet aucune décision d’architecture. À l’inverse, un scénario tel que « compromission d’un compte d’administration de l’outil d’orchestration » conduit à des exigences testables : authentification multifacteur, postes d’administration dédiés, journalisation centralisée, accès à privilèges temporaires et procédure de révocation.

La gouvernance de la sécurité doit donc imposer une relation explicite entre registre des risques, exigences d’architecture et preuves de fonctionnement. Pour les dépendances d’identité, la page identités et accès complète ce travail : une revue d’accès ne vaut que si la source d’autorité, les comptes techniques et les comptes d’urgence sont inclus.

Ce que l’audit ISO 27001 ne détecte pas à coup sûr

Un audit de certification n’est pas un test d’intrusion, une revue de code ou une analyse forensique. Un organisme certificateur peut relever des incohérences manifestes, mais il n’a ni le mandat ni le temps de rechercher toutes les vulnérabilités exploitables. Une injection SQL dans un portail métier, une dépendance compromise ou une erreur de séparation réseau peuvent rester invisibles à un audit de management parfaitement mené.

La certification ne garantit pas non plus :

la confidentialité effective de toutes les données ;
l’intégrité des journaux si leur collecte ou leur conservation n’est pas testée ;
la disponibilité pendant une attaque par rançongiciel, une panne de fournisseur ou une erreur humaine ;
la conformité réglementaire sectorielle complète ;
la compétence technique de chaque sous-traitant ;
la sécurité des composants exclus du périmètre ;
la rapidité réelle de reprise après sinistre.

Une mesure documentée n’est pas une mesure opérante. La sauvegarde est le cas classique : une politique impose des copies chiffrées et des tests de restauration, les rapports existent, puis la restauration d’une base critique échoue parce que la clé de chiffrement a disparu avec le coffre-fort de secrets. La sauvegarde n’est pas le mécanisme de reprise. La restauration testée, avec les identités, les clés, les dépendances réseau et les objectifs de délai, est le mécanisme de reprise.

Les contrôles cryptographiques exigent la même discipline. Détenir une clé dans un HSM (Hardware Security Module) limite l’extraction de cette clé, mais ne limite pas forcément l’usage abusif d’une session autorisée. La cryptographie appliquée doit définir les rôles, les autorisations d’usage, la rotation et la journalisation. Un module matériel n’a jamais corrigé une délégation d’accès absurde. Il se contente de la rendre plus chère.

Surface d’attaque du SMSI et des preuves d’audit

Le SMSI crée lui-même des actifs sensibles : registre des risques, rapports d’audit, cartographies, inventaires, comptes rendus d’incident, matrices d’accès et preuves de conformité. Ces documents révèlent souvent les chemins d’administration, les faiblesses connues et les mesures compensatoires. Les stocker dans un espace documentaire largement accessible transforme l’audit en service de renseignement interne.

Les attaques les plus fréquentes visent moins la norme que ses angles morts :

Réduction abusive du périmètre : exclure une dépendance critique pour préserver un périmètre auditable. Contre-mesure : exiger une cartographie des flux, des identités et des responsabilités aux frontières du périmètre.
Falsification ou recyclage de preuves : présenter une revue d’accès ancienne, un rapport de restauration non représentatif ou une capture d’écran non traçable. Contre-mesure : horodatage, conservation des données sources, journaux immuables et échantillonnage croisé entre preuves et systèmes.
Ingénierie sociale autour de l’audit : exploiter les calendriers, listes de contacts ou rapports d’écart pour obtenir un accès. Contre-mesure : classification des éléments d’audit, partage au besoin d’en connaître et validation hors bande des demandes sensibles.
Conformité par politique : déployer des documents sans mécanisme de contrôle technique. Contre-mesure : associer chaque risque majeur à une métrique, une alerte ou un test de restauration, de révocation, de bascule ou de détection.
Dérive après audit : modifier l’architecture, ajouter un fournisseur ou ouvrir un flux réseau sans réévaluer le risque. Contre-mesure : déclencher une revue de risque sur chaque changement significatif et relier le processus de changement au registre des risques.

L’audit ne doit pas devenir un événement annuel isolé. Il faut traiter les écarts comme des signaux de conception : cause racine, mesure corrective, responsable, date cible, preuve de clôture et contrôle de non-récurrence. Fermer un ticket parce qu’une date approche ne corrige rien, sauf l’apparence du tableau de bord.

Vérifier la fraîcheur des preuves ISO 27001

Un inventaire de preuves peut détecter les contrôles dont la démonstration devient obsolète. L’exemple suivant vérifie, à partir d’un fichier CSV, que chaque preuve possède un propriétaire et qu’elle n’a pas dépassé sa fréquence de revue. Il ne prouve pas la conformité ISO 27001 : il élimine seulement une forme très commune de fiction documentaire.

# Fichier preuves.csv attendu :
# controle;proprietaire;derniere_revue;frequence_jours
# A.5.15;[email protected];2026-08-15;90
# A.8.13;[email protected];2026-05-01;30

awk -F ';' -v today="$(date +%s)" '
NR == 1 { next } # Ignorer l en-tête
{
  split($3, d, "-")
  reviewed = mktime(d[1] " " d[2] " " d[3] " 00 00 00")
  age = int((today - reviewed) / 86400)

  if ($2 == "" || $3 == "" || $4 == "") {
    print "ERREUR preuve incomplète pour le contrôle " $1
    failed = 1
  } else if (age > $4) {
    print "EXPIREE " $1 ": " age " jours, seuil " $4 " jours"
    failed = 1
  }
}
END { exit failed }
' preuves.csv

Cette vérification doit s’exécuter sous un compte de lecture, sur une source versionnée ou journalisée. Le fichier lui-même devient une preuve sensible : contrôler les droits d’écriture, conserver l’historique et sauvegarder le dépôt. Une preuve modifiable sans trace ne mérite pas davantage de confiance qu’un mot de passe écrit sur un post-it, mais avec une police plus corporate.

Exploitation continue, rotation et reprise

Le certificat reste conditionné au maintien du SMSI. Les audits de surveillance vérifient que les exigences continuent d’être appliquées entre deux cycles de certification. La cadence doit donc être pilotée comme une capacité opérationnelle, pas comme une campagne de préparation d’audit.

Les conditions minimales d’exploitation sont les suivantes :

maintenir un registre des risques daté, avec propriétaires et décisions d’acceptation explicites ;
réviser la déclaration d’applicabilité lors des changements d’architecture, d’externalisation ou d’incident majeur ;
protéger les preuves d’audit par chiffrement, contrôle d’accès et rétention définie ;
tester les restaurations sur des jeux représentatifs, y compris les secrets, certificats et comptes d’administration ;
faire tourner les secrets d’intégration, les clés de chiffrement et les certificats selon une politique qui prévoit la révocation et le retour arrière ;
superviser les contrôles critiques : échecs de sauvegarde, comptes à privilèges, expiration de certificats, désactivation de journaux et modifications de configuration ;
réaliser des audits internes par des personnes suffisamment indépendantes de l’activité contrôlée.

La rotation d’une clé ou d’un certificat ne répare pas les données déjà exposées. Elle limite la fenêtre d’exploitation future et doit être accompagnée d’une investigation sur les usages antérieurs. De même, désactiver un compte ne révoque pas toujours les sessions déjà établies ni les jetons émis avant la désactivation. Les mécanismes d’identité doivent définir les durées de session, la révocation et les contrôles de session côté application, pas seulement l’état du compte dans l’annuaire.

🐝 Ce qui arrive si on s’en passe

Sans cette distinction entre ce qu’un certificat atteste et ce qu’il couvre, le document remplace l’analyse : un certificat fourni par un prestataire devient l’unique élément de confiance, et les clauses contractuelles utiles ne sont jamais négociées. Aucun droit d’audit, aucun délai de notification d’incident, aucune obligation de restitution des journaux ni de preuve de restauration ne sont exigés, puisque la conformité semble déjà démontrée. Lors d’un incident chez ce prestataire, rien ne permet d’établir si le composant concerné entrait dans le périmètre certifié, qui en portait la responsabilité, ni quelles mesures étaient réellement appliquées. La chaîne de sous-traitance reste inconnue : un service certifié peut dépendre d’un tiers non couvert, dont les accès d’administration échappent à toute revue. La confiance se reporte alors sur un intitulé, pas sur une capacité vérifiable.

🦫 Explication de la marmotte 🍫

Une certification vérifie qu’une organisation a mis en place une méthode suivie pour protéger ses informations. Cette méthode commence par définir ce qui est couvert : des services, des lieux, des équipes et des outils. Ce périmètre doit être écrit, car une règle ne protège pas automatiquement ce qui se trouve en dehors.

Ensuite, l’organisation recense les problèmes possibles : vol de données, panne, erreur humaine, accès non autorisé ou fournisseur défaillant. Pour chaque problème, elle décide soit de réduire le danger, soit de l’accepter, soit de le transférer. Elle doit pouvoir montrer qui est responsable, quelles mesures existent et comment leur fonctionnement est vérifié.

Un auditeur extérieur examine des documents, interroge des personnes et contrôle des exemples. S’il constate que la méthode respecte les exigences de la norme, il peut recommander la certification. Il ne vérifie pas chaque ordinateur, chaque programme ni chaque accès. Il peut donc ne pas voir une faille technique, une fraude bien cachée ou une panne future.

Après la certification, le travail continue. Les accès doivent être revus, les sauvegardes restaurées pour vérifier qu’elles marchent, les incidents analysés et les changements de système réévalués. Si les preuves sont fausses, si les contrôles ne sont plus appliqués ou si le périmètre change sans mise à jour, la certification ne protège rien par elle-même.

Pages voisines

La citent

Que garantit réellement une certification ISO 27001

Elle cite

: les deux pages se citent l’une l’autre.

Que garantit réellement une certification ISO 27001

Que garantit réellement une certification ISO 27001

Certification ISO 27001 : la garantie réelle, et sa frontière

Périmètre certifié et déclaration d’applicabilité

Ce que l’audit ISO 27001 ne détecte pas à coup sûr

Surface d’attaque du SMSI et des preuves d’audit

Vérifier la fraîcheur des preuves ISO 27001

Exploitation continue, rotation et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines