La partie coûteuse d’ISO 27001 n’est pas la certification. C’est la deuxième année.
Le projet a un budget, une échéance et de l’attention. Puis le certificat arrive, l’équipe projet se disperse, et douze mois plus tard quelqu’un s’aperçoit que l’audit de surveillance est dans six semaines et que personne n’a rien collecté depuis le précédent. S’ensuit une course : captures d’écran, exports de tableurs, validations relancées, et une semaine de temps de cadres passée à prouver que des choses vraies toute l’année l’étaient effectivement.
Cette course n’est pas un problème de discipline. C’est un problème de conception. Le système a été construit pour être audité une fois.
Le schéma qui la provoque
La plupart des documentations de SMSI décrivent les contrôles en termes de comportement humain. « Les droits d’accès sont revus trimestriellement. » « Les changements sont approuvés avant déploiement. » « Les sauvegardes sont testées annuellement. »
Chacune de ces phrases est la promesse que quelqu’un fera quelque chose et trouvera ensuite le moyen de le prouver. La preuve est fabriquée au moment de l’audit à partir de systèmes à qui on n’a jamais demandé de la conserver : capture d’un ticket, export CSV, fil d’e-mails. C’est authentique, et c’est énormément coûteux par contrôle.
L’alternative consiste à énoncer le contrôle sous forme d’une vérification qu’une machine effectue et enregistre.
Reformuler les contrôles en vérifications
Prenons-en trois, courants.
Revue des accès. Au lieu de « les droits d’accès sont revus trimestriellement », exécutez une tâche planifiée qui exporte les appartenances aux groupes et les attributions de rôles à privilèges, ouvre un ticket par responsable, et enregistre la réponse. La preuve, c’est la sortie de la tâche et les tickets clos, horodatés, produits que quelqu’un pense à l’audit ou non.
Approbation des changements. Au lieu d’un comité de changement et de ses comptes rendus, exigez l’approbation dans la pull request, protégez la branche pour qu’elle ne puisse être fusionnée sans elle, et générez depuis la chaîne un enregistrement de déploiement reliant commit, approbateur, résultat des tests et horodatage. L’échantillon de dix changements demandé par l’auditeur devient une requête, pas une recherche.
Test de restauration. Au lieu d’un exercice annuel consigné dans un document, planifiez une restauration automatisée dans un environnement isolé, vérifiez les données restaurées, et publiez le temps de reprise mesuré. Votre RTO devient un nombre observé plutôt qu’un nombre espéré.
Dans chaque cas, le contrôle n’est pas devenu plus faible. Il est devenu continu, et il s’est mis à produire sa propre trace.
À quoi cela ressemble en pratique
La mise en œuvre est moins exotique que le nom ne le suggère.
Une cartographie contrôles / vérifications. Un tableau : référence du contrôle, ce qui le prouve, d’où vient cette preuve, à quelle fréquence, qui en est responsable. Le construire honnêtement est le vrai travail, et il révèle généralement qu’un tiers de vos contrôles est déjà prouvé automatiquement sans que personne ne l’ait remarqué.
Le policy as code dans la chaîne de livraison. Une infrastructure qui enfreint une règle fait échouer la pull request. Chiffrement au repos, exposition réseau, journalisation activée, étiquetage de propriété : ce sont des points décidables, et les décider avant déploiement est à la fois moins coûteux et mieux prouvé que de les détecter après.
Une supervision continue de la posture. Un outillage de posture cloud qui restitue au regard de votre référentiel de contrôles plutôt que du référentiel par défaut de l’éditeur. La sortie n’est pas « 142 constats » ; c’est « le contrôle A.8.9 est satisfait sur 47 comptes sur 48, la dérogation étant documentée et datée ».
Un magasin de preuves avec conservation. Un endroit où les artefacts atterrissent automatiquement, horodatés, conservés pendant la durée qu’exige la norme. Un stockage objet versionné suffit ; il n’est pas nécessaire que ce soit un produit.
Un traitement des dérogations intégré au système. Tout environnement réel comporte des dérogations. Un référentiel sans processus de dérogation produit soit des preuves malhonnêtes, soit de la paralysie. Rendez les dérogations explicites : qui a approuvé, pourquoi, jusqu’à quand, et quelle mesure compense.
Ce que cela ne couvre pas
Être honnête sur les limites compte, car une automatisation survendue est la façon dont cette approche devient une déception.
Environ soixante à soixante-dix pour cent des contrôles de l’annexe A dans une organisation native du cloud peuvent être prouvés automatiquement. Le reste est humain et le restera : due diligence fournisseurs, revue de direction, sensibilisation, sécurité physique, vérifications RH, retours d’expérience après incident. Ceux-là ont besoin d’un calendrier, d’un responsable et d’un document.
L’objectif n’est pas d’éliminer la preuve manuelle. C’est de cesser de dépenser votre effort manuel, rare, sur les soixante pour cent qu’une machine aurait pu enregistrer, afin qu’il reste du temps pour les quarante pour cent qui exigent réellement du jugement.
Le second bénéfice : tous les autres référentiels
Si nous poussons cette approche plus fort qu’ISO 27001 seule ne le justifierait, c’est pour la réutilisation.
Une entreprise disposant d’un certificat ISO 27001, d’un rapport SOC 2, d’obligations NIS2 et d’un registre RGPD répond à quatre jeux de questions qui se recouvrent à environ soixante-dix pour cent. Contrôle d’accès, gestion des changements, journalisation, sauvegarde, gestion des fournisseurs et réponse à incident figurent dans les quatre, avec des mots différents.
Si la preuve est produite par une vérification plutôt que par une personne, ajouter le deuxième référentiel coûte la cartographie et presque rien d’autre. Le même test de restauration prouve l’annexe A.8.13 d’ISO 27001, les critères de disponibilité SOC 2, la mesure de continuité NIS2 et votre obligation de test de résilience DORA. Produit une fois, classé une fois, cité quatre fois.
C’est là que se trouve l’effet cumulatif, et c’est pourquoi nous traitons le référentiel de contrôles comme un artefact d’ingénierie plutôt que comme un document.
Par où commencer si vous avez déjà le certificat
N’attaquez pas tout le référentiel. Prenez les dix contrôles qui vous ont coûté le plus de temps de collecte au dernier audit — votre équipe les nommera sans hésiter — et convertissez ceux-là. Mesurez le temps gagné. Utilisez la mesure pour financer les dix suivants.
Un premier passage de deux à trois semaines convertit généralement les pires cas et réduit la préparation d’audit de plusieurs semaines à quelques jours. C’est un chantier assez petit pour être mené entre deux audits, ce qui est précisément le moment où il doit l’être : personne ne reconstruit sa chaîne de preuves six semaines avant un audit de surveillance.
Le certificat au mur est une affirmation sur votre façon de fonctionner. La conformité as code est ce qui rend cette affirmation continuellement vraie, à un coût que vous pouvez continuer à payer.