ISO 27001 Annexe A : rendre les 93 mesures opérationnelles

L'Annexe A offre aux équipes sécurité un référentiel utile. Sa valeur opérationnelle tient à la capacité de montrer pourquoi une mesure s'applique, comment elle est mise en œuvre et quelles preuves l'étayent dans votre environnement. Un registre affichant 93 indicateurs au vert ne suffit pas si personne ne peut expliquer quels systèmes ces indicateurs couvrent.

Pour un DSI ou un CTO, le défi pratique consiste à traduire l'intention des mesures en travaux d'ingénierie et d'exploitation sans transformer le système de management de la sécurité de l'information en bureaucratie parallèle. Les revues d'accès doivent s'appuyer sur les données réelles d'habilitation. Les plans de reprise doivent refléter les dépendances entre services. Les évaluations des fournisseurs doivent porter sur les services que l'entreprise consomme réellement.

Ce guide explique comment sélectionner les mesures, répartir les responsabilités, définir les mises en œuvre et tester les affirmations qui en résultent. Les fréquences de revue et les exemples de mise en œuvre ci-dessous sont des recommandations pratiques, et non des intervalles universels prescrits par la norme.

Comprendre ce que fait l'Annexe A, et ce qu'elle ne fait pas

L'ISO/IEC 27001:2022 contient 93 mesures en Annexe A, réparties en quatre thèmes. Les articles 4 à 10 contiennent les exigences du système de management : contexte de l'organisation, leadership, planification, support, fonctionnement, évaluation des performances et amélioration. L'Annexe A appuie la sélection des mesures ; elle ne remplace ni ces exigences ni votre appréciation des risques.

Cette distinction compte lors de la mise en œuvre. Une configuration de sauvegarde peut contribuer à une mesure retenue, mais elle n'établit pas que vous avez défini le périmètre du SMSI, apprécié les risques, réalisé un audit interne ou mené la revue de direction. Il s'agit d'activités distinctes, avec des preuves distinctes.

La sélection des mesures repose sur les risques. Déterminez les mesures nécessaires au traitement de vos risques, puis comparez-les à l'Annexe A pour vérifier qu'aucune mesure nécessaire n'a été omise. Des mesures supplémentaires extérieures à l'Annexe A peuvent être nécessaires. À l'inverse, une exclusion justifiée est possible ; aucune règle n'impose à chaque organisation d'exclure quelque chose ni de mettre en œuvre exactement la même sélection.

L'ISO/IEC 27002:2022 fournit des recommandations de mise en œuvre pour les mesures. Ses attributs aident à les organiser par type de mesure, propriété de sécurité de l'information, concept de cybersécurité, capacité opérationnelle et domaine de sécurité. Ce sont des aides au filtrage utiles, et non des listes de contrôle de certification supplémentaires. Consultez les normes sous licence pour le libellé faisant autorité.

Utiliser les quatre thèmes pour trouver les bons responsables

Les thèmes fournissent une structure de navigation, et non quatre chantiers indépendants. Un processus de départ, par exemple, relie les responsabilités liées à l'emploi, l'administration des identités, la restitution des équipements et l'accès aux applications.

Mesures organisationnelles : relier la gouvernance aux décisions opérationnelles

Ces mesures couvrent les politiques, les responsabilités, la séparation des tâches, les actifs, la classification et le traitement de l'information, la gouvernance des accès, les fournisseurs, les incidents, la continuité, les obligations légales et les activités de revue.

Commencez par identifier où les décisions sont prises. Qui approuve un nouveau service cloud ? Qui attribue une classification à une information ? Qui décide si un événement signalé est un incident ? Une politique devrait rendre ces décisions reproductibles et attribuer l'autorité, plutôt que de simplement exprimer un soutien à la sécurité.

La sécurité des fournisseurs nécessite une chaîne de preuves propre à chaque service : la finalité métier du service, les informations qu'il traite, les risques évalués, les responsabilités contractuelles et la revue continue. Le rapport d'assurance d'un fournisseur peut appuyer cette évaluation, mais son périmètre, sa période et les responsabilités qu'il laisse au client doivent correspondre à votre usage.

De même, la gestion des incidents nécessite plus qu'une liste de contacts d'urgence. Définissez les voies de signalement, les critères d'évaluation, l'autorité de réponse, le traitement des preuves et les activités de retour d'expérience. Consignez les exercices ou les réponses réelles, y compris les actions de suivi et leurs responsables.

Mesures liées aux personnes : faire des événements RH des déclencheurs fiables

Les huit mesures liées aux personnes portent sur la sélection des candidats, les conditions d'emploi, la sensibilisation et la formation, le processus disciplinaire, les responsabilités après un changement d'emploi, la confidentialité, le travail à distance et le signalement des événements.

Intégrez-les aux processus RH existants. Une arrivée nécessite des engagements, des accès et des instructions appropriés. Une mobilité interne nécessite une réévaluation des habilitations, et pas simplement leur cumul. Un départ nécessite la suppression des accès, la restitution des actifs et une clarté sur les obligations de confidentialité qui subsistent.

La responsabilité est souvent partagée entre plusieurs équipes. Les RH peuvent initier un départ, les administrateurs des identités désactivent le compte central, les responsables d'applications suppriment les accès gérés localement et un manager confirme l'achèvement. Confier l'ensemble du processus à la sécurité masque ces dépendances.

Les preuves utiles comprennent les enregistrements de processus approuvés, le suivi des formations réalisées et en retard, les conditions acceptées et un échantillon de changements de situation professionnelle. Restreignez l'accès aux preuves RH sensibles ; un relecteur des mesures n'a pas automatiquement besoin des dossiers complets du personnel.

Mesures physiques : documenter votre périmètre et celui du fournisseur

Les mesures physiques portent sur les locaux, les accès, la surveillance, les menaces environnementales, les zones sécurisées, les bureaux et écrans, les équipements, les supports, les services généraux, le câblage, la maintenance et la mise au rebut.

Une organisation « cloud-first » doit tout de même prendre en compte la sécurité physique. Une partie de la mise en œuvre peut être assurée par un fournisseur cloud, tandis que l'accès aux bureaux et les appareils des salariés restent de sa propre responsabilité. Consignez ce partage au lieu d'exclure automatiquement l'ensemble du thème.

Pour vos propres sites, identifiez qui peut entrer, comment les accès évoluent, où se trouvent les équipements sensibles et comment les visiteurs sont pris en charge. Pour les appareils utilisés à distance, définissez des modalités de stockage, de transport, de réparation et de mise au rebut adaptées à leurs risques.

Les preuves peuvent inclure des enregistrements d'autorisation d'accès, des procédures d'accueil des visiteurs, des inventaires d'équipements et des enregistrements de mise au rebut. Les preuves des fournisseurs doivent expliquer les installations et services couverts ; elles ne doivent pas être considérées comme une preuve de vos mesures relatives aux bureaux ou aux ordinateurs portables.

Mesures technologiques : définir la couverture avant de choisir les outils

Le thème technologique couvre les terminaux, les accès à privilèges, l'authentification, l'accès au code source, la capacité, les logiciels malveillants, les vulnérabilités, les configurations, le traitement des données, les sauvegardes, la résilience, la journalisation, la surveillance, les réseaux, la cryptographie, le développement et la gestion des changements.

Commencez par la couverture des systèmes. Une politique d'identité est incomplète si les accès de production, les comptes de service ou une application gérée séparément échappent à sa mise en œuvre. Une plateforme de journalisation est incomplète si des événements critiques ne l'atteignent jamais ou si personne ne réagit aux alertes.

Pour le développement logiciel, reliez les exigences et les décisions de conception à la revue de code, aux tests de sécurité, à la séparation des environnements, au traitement des données de test et à l'approbation des mises en production. La modélisation des menaces peut aider à identifier les exigences de sécurité avant la mise en œuvre. La profondeur des tests doit suivre les risques et les obligations ; l'ISO 27001 n'impose pas de calendrier universel de tests d'intrusion.

Pour la cryptographie, distinguez les données au repos des données en transit et documentez la responsabilité des clés, leur accès, leur récupération, leur rotation et leur révocation. « Chiffrement activé » laisse sans réponse des questions de mise en œuvre importantes.

Ce qui a changé en 2022, et où chercher les lacunes

L'édition 2013 comptait 114 mesures réparties en 14 domaines. L'édition 2022 les a réorganisées en 93 mesures réparties en quatre thèmes, dont 11 nouvelles. Un nombre plus faible ne signifie pas moins de travail de sécurité : le regroupement peut placer plusieurs responsabilités opérationnelles sous une seule référence.

Lors de la mise à jour d'un ancien registre, préservez les mises en œuvre et les preuves sous-jacentes plutôt que de simplement remplacer les identifiants. Vérifiez si le nouveau regroupement modifie la couverture, les responsabilités ou les tests nécessaires pour étayer votre statut.

La date limite de transition pour les certifications accréditées ISO/IEC 27001:2013 était le 31 octobre 2025. Ces certificats ne sont plus valides ; la seule mise à jour d'un registre des mesures n'établit pas une certification selon l'édition 2022.

Les éléments suivants sont des points de départ pratiques pour les 11 nouvelles mesures, et non une reproduction de leur texte faisant autorité.

Évitez de considérer ces mesures comme onze achats de produits automatiques. Par exemple, le renseignement sur les menaces nécessite de l'analyse et de l'action, et pas seulement un flux auquel on s'abonne. La suppression des données exige de comprendre les copies, les sauvegardes et les obligations de conservation, et pas seulement un bouton de suppression. La surveillance nécessite une voie de réponse opérationnelle.

Consigner séparément l'applicabilité et la mise en œuvre

Votre déclaration d'applicabilité (DdA, ou SoA en anglais) doit identifier les mesures nécessaires, expliquer leur inclusion, indiquer si elles sont mises en œuvre et justifier les exclusions de mesures de l'Annexe A. Ces exigences relèvent des dispositions de l'ISO/IEC 27001 relatives au traitement des risques.

Utiliser les 93 références comme index de revue est un moyen pratique de rendre la comparaison vérifiable. Incluez aussi toute mesure supplémentaire nécessaire. La DdA n'est ni le registre des risques, ni le plan de traitement, ni le référentiel de preuves, même si elle doit renvoyer à chacun d'eux lorsque c'est pertinent.

Pour chaque mesure applicable, consignez :

• Les risques ou obligations justifiant l'inclusion.
• Les systèmes, sites, informations et processus concernés.
• La mise en œuvre réelle et le responsable.
• Les preuves à l'appui et leur période de revue.
• Les dépendances, exceptions et travaux inachevés.
• La prochaine date de revue ou l'événement déclencheur.

Gardez l'applicabilité indépendante de l'état d'avancement. « Applicable, partiellement mise en œuvre » est un enregistrement honnête et utile. « Non applicable car nous n'avons pas acheté d'outil » n'est pas une justification d'applicabilité.

Une exclusion doit décrire les faits de périmètre qui rendent la mesure inutile et rester cohérente avec l'appréciation des risques. « Nous ne développons pas de logiciel » mérite d'être examiné si un prestataire développe votre portail client. L'externalisation modifie le chemin de mise en œuvre et de preuve ; elle ne supprime pas automatiquement le risque.

Pour les mises en œuvre réparties, consignez le partage. Une mesure de protection physique peut dépendre d'installations d'hébergement exploitées par un fournisseur, d'un contrôle d'accès aux bureaux géré par l'entreprise et de la manière dont les salariés traitent leurs appareils. Un seul responsable peut rester garant de l'affirmation d'ensemble tandis que différentes équipes réalisent les activités.

Une description de mise en œuvre utile est suffisamment précise pour être testée : « Les administrateurs de production reçoivent un accès nominatif et approuvé via le service d'identité ; les accès d'urgence sont journalisés et examinés séparément. » « Les accès sont gérés de manière sécurisée » ne peut guider ni un ingénieur ni un relecteur.

Tester l'affirmation derrière le statut

Une politique décrit le comportement attendu. Elle peut démontrer la conception et l'approbation, mais ne peut à elle seule démontrer le fonctionnement. Construisez une chaîne de preuves allant de l'exigence au mécanisme mis en œuvre, puis à un résultat observé.

Pour la gestion des accès, comparez les règles approuvées aux habilitations réelles des utilisateurs et aux enregistrements de départ. Incluez les identités à privilèges, les comptes non humains et les applications hors de la gestion centralisée des identités lorsque c'est pertinent. Consignez la population, l'échantillon et les exceptions plutôt que de présenter une seule capture d'écran commode.

Pour les sauvegardes, examinez la configuration et un résultat de restauration. Une tâche de sauvegarde réussie prouve moins qu'une restauration réussie d'informations exploitables. Vérifiez les autorisations, les dépendances et les objectifs de reprise ; une base de données restaurée sans ses clés de chiffrement peut ne pas rétablir le service.

Pour la sécurité des fournisseurs, reliez l'évaluation au service concerné et aux responsabilités contractuelles. Vérifiez si les preuves couvrent le service que vous utilisez et si les responsabilités identifiées côté client sont mises en œuvre.

Un enregistrement de test pratique doit contenir le résultat attendu, la méthode, le périmètre, la date des preuves, le relecteur, le résultat et la décision de suivi. Distinguez :

• Conception : le mécanisme proposé traite le risque identifié.
• Mise en œuvre : le mécanisme existe sur l'ensemble du périmètre déclaré.
• Fonctionnement : les enregistrements montrent qu'il a fonctionné pendant la période concernée.
• Efficacité : les tests indiquent qu'il atteint le résultat visé.

Les preuves peuvent inclure des configurations, des exports, des tickets, des contrats, des entretiens et des observations physiques. Choisissez des preuves qui étayent l'affirmation réelle. Un export de configuration peut montrer les paramètres actuels ; des tickets historiques peuvent montrer si les exceptions ont été traitées dans la durée.

Préservez la provenance : système source, date de collecte, période couverte et tout filtrage appliqué. Protégez les preuves contenant des secrets ou des informations personnelles par des restrictions d'accès et une occultation appropriée. La collecte de preuves ne doit pas créer un nouveau référentiel non maîtrisé de données sensibles.

Exemple concret : rendre un processus de départ vérifiable

Prenons à titre d'illustration une entreprise SaaS de 45 salariés, avec un seul bureau, un hébergement cloud, une gestion centralisée des identités et deux applications à comptes locaux. Il s'agit d'hypothèses d'exemple, et non de résultats de clients de Secani.

Le risque est la persistance d'un accès aux informations des clients ou de l'entreprise après un départ. Les mesures pertinentes comprennent les responsabilités en cas de changement d'emploi, la gestion des identités, les droits d'accès et la restitution des actifs. L'authentification technique et les restrictions d'accès soutiennent également la mise en œuvre.

L'entreprise enregistre la mesure comme applicable. Les RH sont responsables du déclenchement du départ ; l'informatique des actions sur les identités et les appareils ; chaque responsable d'application de la suppression des comptes locaux. Le manager du salarié confirme la date de départ requise. Le responsable sécurité examine le processus et les exceptions non résolues.

La mise en œuvre comprend un ticket de départ autorisé, la désactivation planifiée du compte central, la révocation des sessions lorsque c'est possible, la suppression des comptes locaux, la restitution des actifs et la vérification des identifiants que la personne contrôlait. Les secrets partagés sont changés si nécessaire ; les comptes personnels ne sont pas réattribués à la légère à un successeur.

Le dossier de preuves relie la procédure approuvée, le ticket de départ, les enregistrements d'actions sur les comptes, les confirmations des applications locales et l'enregistrement des équipements. Chaque élément étaye une partie définie de l'affirmation.

Lors d'une revue donnée à titre d'illustration, l'équipe examine quatre départs. Les comptes centraux ont été désactivés comme prévu, mais une application locale a conservé l'accès pendant deux jours. La mesure n'est pas déclarée pleinement efficace sur la seule base des preuves de la gestion centralisée des identités.

Le responsable de l'application supprime le compte, évalue si un accès a eu lieu et consigne le résultat. L'équipe ajoute l'application à la liste de contrôle des départs et prévoit une étape de rapprochement. L'action de traitement reçoit un responsable et une échéance ; un test ultérieur vérifie que le processus révisé fonctionne.

Cet exemple montre pourquoi les preuves doivent suivre les dépendances. Quatre systèmes indiquant « terminé » n'établissent pas l'achèvement si un cinquième système n'a jamais été inclus.

Maintenir les mesures opérationnelles entre les revues

Les mesures évoluent lorsque les systèmes, les fournisseurs, les personnes et les exigences métier changent. Définissez des déclencheurs de revue pour les mises en production importantes, les nouveaux services, les changements de locaux, les incidents et les obligations révisées, en complément des revues programmées.

Adoptez une fréquence adaptée à la volatilité et au risque. Les exceptions d'accès à privilèges peuvent nécessiter une revue rapide, tandis qu'une politique stable peut suivre un cycle plus long complété par des déclencheurs liés aux changements. Ce sont des choix de management, et non des fréquences universelles de l'Annexe A.

Suivez un petit nombre d'indicateurs utiles : corrections en retard, systèmes non couverts, exceptions de preuves non résolues et tests de mesures en échec. Séparez-les des décomptes de documents. Une vaste bibliothèque de preuves peut encore laisser un environnement de production critique non testé.

L'audit interne fournit une évaluation distincte du SMSI ; les revues courantes des responsables de mesures ne le remplacent pas. La revue de direction nécessite de même des décisions de la direction sur la performance, les changements, les ressources et l'amélioration, et pas seulement un tableur des mesures complété. La certification est réalisée par un organisme de certification indépendant, et non par l'ISO ou un éditeur de logiciels.

Les erreurs courantes consistent à tout confier à la sécurité, à copier les exclusions d'une autre organisation, à s'appuyer sur des certificats de fournisseurs sans en vérifier le périmètre et à clore des constats dès qu'une politique change plutôt qu'une fois le processus révisé testé.

Commencer par un service et une chaîne de preuves complète

Choisissez un service représentatif et retracez ses systèmes, prestataires, informations et responsables opérationnels. Sélectionnez un petit ensemble de mesures liées, telles que les accès, la gestion des changements, la journalisation et la reprise, et rendez chaque mise en œuvre vérifiable avant d'étendre le registre.

Secani soutient ce processus en modélisant les systèmes et leurs dépendances, en reliant les preuves aux exigences, aux mesures et aux décisions, et en suivant les lacunes sous forme de tâches. Désignez un responsable et un relecteur, rattachez les enregistrements existants et conservez les commentaires et approbations de revue. Traitez les correspondances ou résumés assistés par l'IA comme des brouillons : validez les sources et gardez l'approbation humaine explicite. Structurer la préparation à l'audit explique le modèle de preuves sous-jacent.

Le premier livrable doit être une chaîne cohérente allant du risque à la mesure, à la mise en œuvre, aux preuves, au résultat de test et à la décision de suivi. Cette chaîne peut ensuite être reproduite sur le reste du périmètre sans inventer un nouveau processus pour chaque référence de l'Annexe A.

Questions pratiques

Un même enregistrement peut-il étayer plusieurs mesures ?

Oui. Un ticket de départ peut étayer plusieurs mesures liées. Expliquez quelle affirmation il étaye pour chacune ; partager une preuve ne rend pas les mesures identiques.

Chaque mesure doit-elle avoir sa propre politique ?

Non. Organisez les politiques et procédures autour de processus opérationnels compréhensibles. Un même document peut traiter plusieurs mesures, à condition que les responsabilités et la mise en œuvre restent claires.

D'où doit provenir la liste des mesures faisant autorité ?

Utilisez la norme ISO/IEC 27001 sous licence pour le libellé de l'Annexe A et l'ISO/IEC 27002 pour les recommandations de mise en œuvre. Les synthèses opérationnelles sont des aides à la navigation utiles, pas des substituts aux normes.