Annexe A 2022 : contrôles utiles

Le catalogue n'est pas la finalité

L'Annexe A d'ISO/IEC 27001:2022 rassemble 93 contrôles répartis en quatre thèmes. Beaucoup d'organismes abordent ce catalogue comme une liste à cocher : parcourir les 93 lignes, cocher « en place » ou « non applicable », et considérer le travail terminé. Cette lecture rate l'intention de la norme et produit systématiquement des Déclarations d'Applicabilité fragiles, détectées comme telles dès le premier audit un peu approfondi.

L'Annexe A n'est pas une exigence en soi : c'est une boîte à outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire de référence, construite pour couvrir la quasi-totalité des scénarios de risque rencontrés par une organisation traitant de l'information. La véritable exigence normative se trouve en clause 6.1.3 : chaque contrôle retenu doit répondre à un risque identifié dans l'appréciation des risques, et chaque contrôle exclu doit l'être pour une raison documentée — pas parce qu'il est absent d'une checklist standard trouvée en ligne.

Un contrôle de l'Annexe A jamais relié à un risque du registre, ou un risque du registre jamais relié à un contrôle, constitue une rupture de traçabilité — la non-conformité la plus fréquemment relevée lors des audits de certification portant sur le périmètre Annexe A.

Ce chapitre détaille les quatre thèmes, la mécanique de correspondance avec l'ancienne version 2013, les cinq attributs qui permettent de filtrer le catalogue autrement que par thème, et une méthode de sélection qui évite l'écueil de la checklist.

Les quatre thèmes, contrôle par contrôle

La révision 2022 remplace les 14 domaines de 2013 par quatre thèmes plus larges, chacun identifiable par son préfixe.

Le thème organisationnel (A.5) est de loin le plus fourni : il concentre à la fois les contrôles de gouvernance historiquement dispersés dans les anciens domaines A.5, A.6, A.8, A.9, A.15, A.16, A.17 et A.18 de la version 2013. C'est aussi celui qui recouvre le plus directement les clauses 4 à 10 elles-mêmes — plusieurs contrôles A.5 formalisent en Annexe A des exigences déjà posées en clause, par exemple A.5.1 (politiques de sécurité) qui fait écho à la clause 5.2.

Le thème personnes (A.6) reste le plus restreint mais souvent sous-estimé : la majorité des incidents constatés en exploitation trouvent leur origine dans un facteur humain — erreur, contournement, ingénierie sociale — sans que le contrôle technique correspondant ait été défaillant.

Le thème physique (A.7) perd du terrain dans les organisations qui migrent l'essentiel de leur infrastructure vers le cloud, mais reste pertinent tant que subsistent des bureaux, du matériel en propre ou des postes de travail physiques.

Le thème technologique (A.8), le plus volumineux après l'organisationnel, couvre l'ensemble du cycle de vie technique : des terminaux utilisateurs à la journalisation, en passant par la cryptographie et le développement sécurisé.

Une société de conseil de 40 salariés, entièrement en télétravail, sans bureau physique loué en propre, a justifié dans sa SoA l'exclusion de la quasi-totalité des contrôles A.7 relatifs aux périmètres de sécurité physique, tout en conservant A.7.9 (sécurité des équipements hors des locaux) et A.7.10 (supports de stockage), les seuls réellement pertinents pour des postes utilisés en dehors de tout site sous sa responsabilité.

Les onze contrôles nouveaux de la révision 2022

Onze contrôles n'existaient sous aucune forme dans la version 2013. Ils répondent à des sujets qui ont pris une importance opérationnelle majeure au cours de la décennie écoulée, en particulier autour du cloud et de la donnée.

Ces onze ajouts ne sont pas de simples reformulations de contrôles existants : ils couvrent des lacunes réelles de la version 2013. A.5.23, par exemple, comble un vide qui obligeait auparavant les organismes hébergés en cloud à rattacher artificiellement leurs exigences fournisseur cloud à des contrôles pensés pour de l'infogérance classique. A.8.28 (codage sécurisé) formalise ce que beaucoup d'équipes de développement appliquaient déjà de façon informelle, sans référence normative explicite à citer en audit.

Si votre organisme s'appuie fortement sur des prestataires cloud, commencez la lecture de l'Annexe A par A.5.23 plutôt que par A.5.1. C'est souvent le contrôle qui structure le plus directement le contrat, les clauses de réversibilité et les exigences de journalisation à exiger du fournisseur — un point d'entrée plus concret que les politiques génériques.

La table de correspondance 2013 → 2022 : comment lire une fusion

Le passage de 114 contrôles en 2013 à 93 en 2022 ne s'est pas fait par suppression pure : la plupart des contrôles disparus ont été fusionnés dans un contrôle plus large, pas retirés du référentiel. Comprendre le mécanisme de fusion évite un contresens fréquent : croire qu'un ancien contrôle a été abandonné alors qu'il est simplement absorbé ailleurs.

Trois mécanismes de transformation coexistent :

• Fusion pure — plusieurs contrôles proches de 2013 deviennent un seul contrôle 2022. Les six contrôles de gestion des accès utilisateurs de l'ancien domaine A.9.2 (enregistrement, provisionnement, droits privilégiés, information secrète d'authentification, revue, retrait) se retrouvent regroupés en un nombre réduit de contrôles A.5.15 à A.5.18.
• Renumérotation simple — un contrôle change de code et parfois d'intitulé sans changement de fond notable. C'est le cas le plus fréquent et le moins risqué à traiter.
• Éclatement partiel — un ancien contrôle générique se scinde pour donner naissance à un contrôle nouveau plus spécifique. La surveillance, auparavant traitée uniquement sous l'angle de la journalisation (ancien A.12.4), se scinde en 2022 entre A.8.15 (journalisation) et le nouveau A.8.16 (surveillance des activités), qui porte spécifiquement sur l'analyse et la réaction aux événements journalisés.

Ne traitez jamais la table de correspondance comme un simple exercice de recopiage de numéros. Un organisme qui se contente de remplacer les anciens codes par les nouveaux dans sa SoA, sans revérifier que le contrôle fusionné couvre bien l'intégralité du périmètre des contrôles d'origine, laisse potentiellement des angles morts non traités — en particulier sur les fusions larges comme celle des accès utilisateurs, où six contrôles distincts deviennent quatre.

La table de correspondance officielle est publiée par l'ISO et par la plupart des organismes de certification. Elle n'est pas exigée nommément par la norme, mais elle reste, en pratique, la pièce la plus efficace pour démontrer à un auditeur qu'aucune couverture n'a été perdue dans la transition — un point que les auditeurs vérifient systématiquement pour les organismes en cours de bascule.

Les cinq attributs normalisés : filtrer autrement que par thème

Chaque contrôle de l'Annexe A 2022 porte cinq attributs normalisés, publiés dans le tableau de synthèse de la norme : type de contrôle (préventif, détectif, correctif), propriétés de sécurité de l'information (confidentialité, intégrité, disponibilité), concepts de cybersécurité (identifier, protéger, détecter, répondre, récupérer — repris du référentiel NIST CSF), capacités opérationnelles (gouvernance, gestion des actifs, continuité, sécurité physique...) et domaines de sécurité (gouvernance et écosystème, protection, défense, résilience).

Ces attributs permettent des vues transversales que la seule classification par thème ne permet pas. Un responsable sécurité qui veut vérifier la couverture de la fonction « détection » de son SMSI ne va pas chercher un thème dédié — il n'existe pas — mais filtrer l'ensemble des 93 contrôles sur l'attribut « concept de cybersécurité = détecter ». Cette vue traverse les quatre thèmes et regroupe, par exemple, A.5.7 (threat intelligence), A.8.15 (journalisation), A.8.16 (surveillance des activités) et A.7.4 (surveillance physique).

Les attributs ne remplacent pas la sélection fondée sur le risque : ils facilitent la vérification de couverture après coup. Un SMSI dont tous les contrôles retenus se classent en « préventif » et aucun en « détectif » ou « correctif » signale un déséquilibre à interroger, indépendamment du nombre total de contrôles cochés dans la SoA.

Sélection pragmatique : la méthode qui évite la checklist

La sélection de contrôles ne part jamais du catalogue : elle part du registre de risques. La méthode qui fonctionne en pratique applique trois filtres successifs à chaque risque du registre dépassant le seuil d'acceptation, avant de considérer un contrôle comme retenu dans la SoA.

Le premier filtre, le risque, est le seul réellement exigé par la norme : c'est lui qui rattache un contrôle à un scénario du registre. Le deuxième filtre, l'obligation, capture les contrôles imposés indépendamment du niveau de risque perçu en interne — un client grand compte qui exige contractuellement le chiffrementchiffrementCybersécuritéTransformation d'une donnée lisible en une forme inintelligible à l'aide d'une clé. Le destinataire disposant de la clé peut retrouver le message original. C'est le socle de la confidentialité sur Internet.Voir dans le glossaire au repos, une réglementation sectorielle qui impose la journalisation d'accès pendant une durée minimale. Le troisième filtre, la faisabilité, ne sert pas à écarter un contrôle nécessaire mais à décider s'il est mis en œuvre immédiatement ou planifié dans le plan de traitement des risques, avec une échéance : il justifie un report documenté, jamais une exclusion. « Nous n'avons pas les ressources cette année » est un motif valide pour inscrire un contrôle au plan de traitement avec une échéance à dix-huit mois ; ce n'est jamais un motif d'exclusion de la SoA, qui doit rester réservée aux contrôles sans risque correspondant dans le périmètre.

Les pièges de l'approche checklist

Quatre erreurs reviennent avec régularité chez les organismes qui traitent l'Annexe A comme une liste à cocher plutôt que comme un outil de sélection.

• Cocher « en place » sans preuve vérifiable. Un contrôle marqué en place doit être démontrable par une preuve datée — extrait de configuration, capture d'écran, procédure signée. Une case cochée sans artefact associé est traitée par l'auditeur comme un contrôle non mis en œuvre.
• Copier une SoA type trouvée en ligne ou chez un pair du secteur. Un modèle générique reproduit sans lien avec le registre de risques propre à l'organisme se détecte facilement : les justifications sont formulées de façon interchangeable d'un contrôle à l'autre, sans référence à un scénario précis.
• Traiter chaque contrôle isolément. Plusieurs contrôles se renforcent mutuellement — A.8.9 (gestion de configuration) et A.8.32 (gestion du changement) n'ont de sens que combinés : le premier fixe l'état de référence, le second encadre les écarts à cet état. Les évaluer séparément masque les dépendances.
• Considérer que 93 contrôles cochés « applicable » vaut mieux qu'un sous-ensemble ciblé. Un excès d'inclusion dilue les ressources sur des contrôles peu pertinents et complique la démonstration de maîtrise sur les contrôles réellement critiques. La norme récompense la pertinence de la sélection, pas son exhaustivité brute.

Checklist de sortie

• Chaque contrôle retenu dans la SoA référence au moins un risque du registre
• Chaque exclusion porte une justification écrite fondée sur l'absence de risque, jamais sur le coût
• La table de correspondance 2013 → 2022 a été vérifiée pour les fusions larges (accès, journalisation, développement)
• Les onze contrôles nouveaux ont été explicitement évalués, pas seulement ajoutés par défaut
• Les attributs normalisés ont servi à vérifier l'équilibre préventif/détectif/correctif du dispositif
• Chaque contrôle marqué « en place » dispose d'une preuve datée et vérifiable
• Les contrôles reportés figurent au plan de traitement avec échéance et responsable