Contrôles de l'Annexe A ISO 27001 : Guide complet des 93 contrôles

L’Annexe A est l’endroit où ISO 27001 devient concret. Tandis que le corps principal de la norme (Clauses 4-10) définit ce que votre Système de Management de la Sécurité de l’Information doit faire — établir le périmètre, mener une évaluation des risques, mettre en œuvre une revue de direction — l’Annexe A fournit un ensemble de référence de 93 contrôles de sécurité de l’information organisés en quatre thèmes. Ces contrôles sont les éléments constitutifs de votre mise en œuvre sécuritaire, et la sélection de ceux à appliquer (et de ceux à exclure) est l’une des décisions les plus conséquentes de votre parcours ISO 27001.

La révision 2022 d’ISO 27001 a restructuré l’Annexe A de manière significative. La version précédente (2013) organisait 114 contrôles en 14 domaines. La version 2022 les consolide en 93 contrôles répartis en quatre catégories thématiques, ajoute 11 contrôles entièrement nouveaux et introduit un système d’attributs de contrôle permettant une catégorisation plus flexible. Si vous travaillez avec une documentation plus ancienne ou des consultants faisant référence à la structure en 14 domaines, la restructuration 2022 est le changement le plus important à comprendre.

Ce guide couvre chaque thème de l’Annexe A, explique chaque catégorie de contrôles, met en lumière les 11 nouveaux contrôles et fournit des conseils pratiques aux entreprises SaaS mettant en œuvre ces contrôles dans le cadre de leur ISMS.

Qu’est-ce que l’Annexe A et comment est-elle liée à ISO 27001 ?

L’Annexe A est une annexe normative — ce qui signifie qu’elle n’est pas un guide optionnel mais une partie obligatoire de la norme. Cependant, vous n’êtes pas tenu de mettre en œuvre chaque contrôle de l’Annexe A. Vous êtes tenu de considérer chaque contrôle de l’Annexe A et de documenter votre décision d’inclusion ou d’exclusion dans la Déclaration d’applicabilité (SoA).

La relation entre l’évaluation des risques et l’Annexe A

Le processus fonctionne comme suit :

1. Menez votre évaluation des risques — identifiez les menaces, les vulnérabilités et les risques pour la sécurité de l’information dans le périmètre de votre ISMS.
2. Développez un plan de traitement des risques — pour chaque risque au-dessus de votre seuil d’acceptation, décidez comment le traiter (atténuer, transférer, éviter, accepter).
3. Sélectionnez les contrôles de l’Annexe A — pour les risques que vous atténuez, identifiez quels contrôles de l’Annexe A mettent en œuvre le traitement. Vous pouvez également mettre en œuvre des contrôles non présents dans l’Annexe A si nécessaire, mais l’Annexe A sert de référence de base.
4. Documentez dans le SoA — listez les 93 contrôles de l’Annexe A, indiquez si chacun est inclus ou exclu, fournissez la justification de la décision et notez l’état de mise en œuvre.

Cela signifie que votre sélection de contrôles est guidée par les risques, et non arbitraire. Vous ne mettez pas en œuvre A.7.4 (Surveillance de la sécurité physique) parce que cela semble être une bonne idée — vous le mettez en œuvre parce que votre évaluation des risques a identifié l’intrusion physique comme une menace pertinente pour vos actifs informationnels, ou vous l’excluez parce que votre entreprise SaaS fonctionne entièrement à partir d’une infrastructure cloud sans centres de données physiques à surveiller.

Annexe A vs. ISO 27002

L’Annexe A liste les contrôles. ISO 27002 est la norme complémentaire qui fournit des directives détaillées de mise en œuvre pour chaque contrôle. Considérez l’Annexe A comme la table des matières et ISO 27002 comme le manuel. Vous n’avez pas besoin d’acheter ou de vous certifier contre ISO 27002, mais c’est une référence inestimable lors de la mise en œuvre des contrôles.

La restructuration 2022 : de 14 domaines à 4 thèmes

La version 2013 d’ISO 27001 organisait l’Annexe A en 14 domaines de contrôle (A.5 à A.18). La révision 2022 les réorganise en quatre thèmes de haut niveau :

Thème	Contrôles	Domaine d’application
A.5 Organisationnel	37 contrôles	Gouvernance, politiques, rôles, gestion des fournisseurs, conformité légale
A.6 Personnes	8 contrôles	Vérifications, sensibilisation, conditions d’emploi, travail à distance
A.7 Physique	14 contrôles	Zones sécurisées, protection des équipements, accès physique
A.8 Technologique	34 contrôles	Contrôle d’accès, cryptographie, opérations, développement, gestion des vulnérabilités

Ce qui a changé

Consolidation : De nombreux contrôles de la version 2013 ont été fusionnés. Par exemple, la norme de 2013 avait des contrôles séparés pour la « politique de sécurité de l’information » et la « revue de la politique de sécurité de l’information » — en 2022, ceux-ci sont combinés dans A.5.1.

Réorganisation : Les contrôles ont été déplacés pour s’adapter à la structure en quatre thèmes. Les politiques de contrôle d’accès, auparavant dans leur propre domaine (A.9), sont désormais réparties entre les thèmes Organisationnel (A.5.15) et Technologique (A.8.3) selon que le contrôle est une activité de gouvernance ou une mise en œuvre technique.

11 nouveaux contrôles : La version 2022 introduit des contrôles qui n’existaient pas en 2013, reflétant l’évolution du paysage des menaces et des pratiques technologiques.

Attributs de contrôle : Chaque contrôle dispose désormais de cinq attributs (type de contrôle, propriété de sécurité de l’information, concept de cybersécurité, capacité opérationnelle, domaine de sécurité) qui permettent une catégorisation multidimensionnelle au-delà des quatre thèmes.

Calendrier de transition

Les organisations certifiées selon ISO 27001:2013 doivent effectuer la transition vers la version 2022. Le délai de transition est passé pour la plupart des organismes de certification, ce qui signifie que toutes les nouvelles certifications et audits de surveillance se font désormais contre la version 2022. Si vous poursuivez une certification pour la première fois, vous vous certifierez contre ISO 27001:2022.

A.5 Contrôles organisationnels (37 contrôles)

Les contrôles organisationnels couvrent la gouvernance, la gestion et les fonctions de sécurité au niveau de l’entreprise. Ce sont les contrôles qui définissent comment votre organisation gère la sécurité de l’information en tant que fonction métier, pas seulement une discipline technique.

Politiques et gouvernance (A.5.1 - A.5.6)

A.5.1 — Politiques de sécurité de l’information. Une politique de sécurité de l’information et des politiques spécifiques doivent être définies, approuvées par la direction, publiées, communiquées et revues. Pour les entreprises SaaS, cela signifie une politique ISMS de haut niveau plus des politiques spécifiques pour le contrôle d’accès, la classification des données, la réponse aux incidents, la gestion des changements et d’autres sujets pertinents. Consultez notre guide des politiques pour la liste complète.

A.5.2 — Rôles et responsabilités en matière de sécurité de l’information. Les rôles et responsabilités doivent être définis et attribués. Cela inclut la propriété de l’ISMS (généralement le RSSI ou le Responsable de la sécurité), la propriété des risques (attribuée par risque dans le registre) et les responsabilités opérationnelles de sécurité (qui applique les correctifs aux serveurs, qui examine les accès, qui gère les incidents).

A.5.3 — Séparation des tâches. Les tâches et domaines de responsabilité conflictuels doivent être séparés. En termes SaaS : la personne qui écrit le code ne devrait pas être la seule personne qui l’approuve pour le déploiement en production. La personne qui provisionne les accès ne devrait pas être la même qui approuve les demandes d’accès.

A.5.4 — Responsabilités de la direction. La direction doit exiger des employés et prestataires qu’ils appliquent la sécurité de l’information conformément aux politiques établies. Cela signifie que les responsabilités de sécurité figurent dans les descriptions de poste, que les évaluations de performance tiennent compte de la conformité sécuritaire et que la direction soutient activement l’ISMS au lieu de le traiter comme un problème de l’équipe sécurité.

A.5.5 — Contact avec les autorités. Maintenir le contact avec les autorités compétentes (régulateurs de la protection des données, forces de l’ordre, régulateurs sectoriels). Pour les entreprises SaaS opérant à l’international, cela signifie savoir quelles autorités contacter en cas de violation de données dans différentes juridictions.

A.5.6 — Contact avec des groupes d’intérêt spéciaux. Maintenir le contact avec des groupes d’intérêt spéciaux et des forums de sécurité. Cela inclut les ISAC (Centres de partage et d’analyse de l’information), les groupes de sécurité sectoriels, les listes d’avis de sécurité des fournisseurs et les communautés pertinentes pour votre pile technologique.

Gestion de l’information (A.5.7 - A.5.14)

A.5.7 — Renseignement sur les menaces. Collecter et analyser les informations sur les menaces pesant sur l’organisation. Pour les entreprises SaaS, cela signifie surveiller les bases de données CVE pour les vulnérabilités dans votre pile technologique, s’abonner à des flux de renseignements sur les menaces, suivre les rapports de violations du secteur et surveiller les mentions de votre organisation dans les communications des acteurs de la menace.

A.5.8 — Sécurité de l’information dans la gestion de projet. Intégrer la sécurité de l’information dans la gestion de projet. Chaque nouvelle fonctionnalité, changement de système ou intégration de fournisseur doit inclure des considérations de sécurité. Ce n’est pas une porte de sécurité séparée mais une partie intégrée de la manière dont les projets sont planifiés et exécutés.

A.5.9 — Inventaire de l’information et des autres actifs associés. Maintenir un inventaire des actifs informationnels et de leurs propriétaires. Pour les entreprises SaaS, cela inclut les bases de données de production, les dépôts de code, les comptes cloud, les outils SaaS internes et les données qu’ils contiennent.

A.5.10 — Utilisation acceptable de l’information et des autres actifs associés. Définir les règles d’utilisation acceptable des actifs informationnels et les communiquer à tous les utilisateurs. Cela se manifeste généralement par une politique d’utilisation acceptable couvrant les appareils de l’entreprise, les ressources cloud, les données clients et les systèmes internes.

A.5.11 — Restitution des actifs. S’assurer que le personnel restitue les actifs à la fin de l’emploi ou du contrat. Pour les entreprises SaaS, les « actifs » incluent les appareils physiques (ordinateurs portables, téléphones) et les accès logiques (désactivation des comptes, révocation des clés API, suppression des clés SSH).

A.5.12 — Classification de l’information. Classifier l’information selon les besoins de l’organisation, en tenant compte de la confidentialité, de l’intégrité et de la disponibilité. Un schéma à trois niveaux (Confidentiel, Interne, Public) fonctionne pour la plupart des entreprises SaaS.

A.5.13 — Étiquetage de l’information. Mettre en œuvre des procédures d’étiquetage alignées sur le schéma de classification. En pratique, cela signifie marquer les documents, les e-mails et les stockages de données avec leur niveau de classification. Pour les entreprises SaaS, l’étiquetage automatisé (par exemple, taguer les champs de base de données comme « données personnelles clients ») est plus pratique que l’étiquetage manuel des documents.

A.5.14 — Transfert de l’information. Établir des règles et procédures pour le transfert d’information au sein de l’organisation et vers l’extérieur. Cela couvre le chiffrement des e-mails, le partage sécurisé de fichiers, l’authentification API pour les transferts de données et les politiques de transfert de données à des tiers.

Contrôle d’accès et identité (A.5.15 - A.5.18)

A.5.15 — Contrôle d’accès. Établir et mettre en œuvre des règles pour contrôler l’accès physique et logique à l’information. C’est le contrôle au niveau de la politique — votre politique de contrôle d’accès définit les principes (moindre privilège, besoin d’en connaître, accès basé sur les rôles) que les contrôles techniques mettent en œuvre. Consultez notre guide du contrôle d’accès pour des directives détaillées de mise en œuvre.

A.5.16 — Gestion des identités. Gérer le cycle de vie complet des identités — provisionnement, modification, déprovisionnement. Pour les entreprises SaaS utilisant des fournisseurs d’identité centralisés (Okta, Azure AD, Google Workspace), cela signifie un provisionnement automatisé via SCIM, des attributions de groupes basées sur les rôles et un déprovisionnement rapide lorsque les employés partent ou changent de rôle.

A.5.17 — Informations d’authentification. Contrôler l’attribution et la gestion des informations d’authentification (mots de passe, jetons, certificats, dispositifs MFA). Appliquer des politiques de mots de passe forts, exiger le MFA pour tous les systèmes et gérer les identifiants des comptes de service via des outils de gestion des secrets plutôt que des tableurs partagés.

A.5.18 — Droits d’accès. Provisionner, revoir, modifier et supprimer les droits d’accès conformément à la politique de contrôle d’accès. Les revues trimestrielles des accès sont la pratique standard — comparer l’accès réel à l’accès autorisé et supprimer les écarts.

Gestion des fournisseurs (A.5.19 - A.5.23)

A.5.19 — Sécurité de l’information dans les relations fournisseurs. Établir des processus pour gérer les risques de sécurité liés à l’utilisation de produits et services de fournisseurs. Pour les entreprises SaaS, chaque fournisseur qui touche les données clients, accède aux systèmes de production ou fournit une infrastructure critique est un fournisseur dont la posture de sécurité affecte la vôtre. Consultez notre guide de gestion des fournisseurs pour une couverture complète.

A.5.20 — Traitement de la sécurité de l’information dans les accords fournisseurs. Inclure les exigences de sécurité pertinentes dans les accords avec les fournisseurs. Cela signifie des accords de traitement des données, des SLA de sécurité, des obligations de notification de violation, des droits d’audit et des dispositions de restitution/suppression des données.

A.5.21 — Gestion de la sécurité de l’information dans la chaîne d’approvisionnement TIC. Gérer les risques de sécurité dans la chaîne d’approvisionnement TIC, y compris les dépendances logicielles, les chaînes de fournisseurs de services cloud et l’approvisionnement en matériel. Pour les entreprises SaaS, cela s’étend aux dépendances open source, aux outils SaaS utilisés dans le développement et les opérations, et aux propres chaînes d’approvisionnement des fournisseurs.

A.5.22 — Surveillance, revue et gestion des changements des services fournisseurs. Surveiller, revoir et gérer en continu les changements dans les pratiques de sécurité des fournisseurs. Revues annuelles des fournisseurs, surveillance continue de la posture de sécurité des fournisseurs et réévaluation déclenchée par des incidents ou changements de service du fournisseur.

A.5.23 — Sécurité de l’information pour l’utilisation des services cloud. Gérer l’acquisition, l’utilisation, la gestion et la sortie des services cloud en tenant compte des exigences de sécurité de l’information. Ceci est particulièrement pertinent pour les entreprises SaaS — il couvre votre utilisation d’AWS, GCP, Azure, ainsi que les outils SaaS de votre pile.

Incidents et continuité (A.5.24 - A.5.30)

A.5.24 — Planification et préparation de la gestion des incidents de sécurité de l’information. Planifier et se préparer à la gestion des incidents de sécurité de l’information. Développer des manuels de réponse aux incidents, définir les niveaux de gravité, établir des protocoles de communication et attribuer des rôles de réponse aux incidents.

A.5.25 — Évaluation et décision sur les événements de sécurité de l’information. Évaluer les événements et décider s’ils constituent des incidents de sécurité de l’information. Définir des critères clairs pour ce qui constitue un événement de sécurité par rapport à un incident, et établir des procédures d’escalade.

A.5.26 — Réponse aux incidents de sécurité de l’information. Répondre aux incidents conformément aux procédures documentées. Cela inclut le confinement, l’éradication, la reprise et la communication — en suivant les manuels développés dans le cadre d’A.5.24.

A.5.27 — Apprentissage des incidents de sécurité de l’information. Utiliser les connaissances acquises lors des incidents pour renforcer les contrôles. Des revues post-incident (post-mortems sans blâme) qui produisent des améliorations concrètes et alimentent le processus d’évaluation des risques.

A.5.28 — Collecte de preuves. Établir des procédures pour l’identification, la collecte, l’acquisition et la préservation des preuves. Préparation à l’investigation numérique — s’assurer que les journaux sont conservés, que les preuves sont traitées avec des procédures de chaîne de possession et que les systèmes sont configurés pour soutenir l’investigation.

A.5.29 — Sécurité de l’information pendant une perturbation. Maintenir la sécurité de l’information à un niveau approprié pendant une perturbation. Lorsque les systèmes sont en panne et que vous êtes en mode crise, les contrôles de sécurité s’appliquent toujours — la réponse aux incidents ne doit pas contourner les contrôles d’accès, et la reprise après sinistre ne doit pas exposer les données par des solutions de contournement temporaires.

A.5.30 — Préparation des TIC pour la continuité d’activité. Planifier, mettre en œuvre, maintenir et tester la préparation des TIC pour assurer la continuité d’activité. Pour les entreprises SaaS, cela signifie tester la reprise après sinistre, les procédures de basculement, la vérification de la restauration des sauvegardes et documenter les objectifs de temps de reprise (RTO) et les objectifs de point de reprise (RPO).

Conformité et juridique (A.5.31 - A.5.37)

A.5.31 — Exigences légales, statutaires, réglementaires et contractuelles. Identifier et documenter les exigences légales, réglementaires et contractuelles applicables. Pour les entreprises SaaS, cela inclut généralement le RGPD (si vous servez des clients de l’UE), les réglementations sectorielles, les obligations contractuelles des clients et les exigences de localisation des données.

A.5.32 — Droits de propriété intellectuelle. Protéger les droits de propriété intellectuelle, y compris la conformité des licences logicielles. Assurer la conformité des licences open source, les licences de logiciels propriétaires et la protection de votre propre PI (code source, algorithmes, analyses clients).

A.5.33 — Protection des enregistrements. Protéger les enregistrements contre la perte, la destruction, la falsification, l’accès non autorisé et la diffusion non autorisée. Cela couvre à la fois les enregistrements métier et les preuves de fonctionnement de l’ISMS (journaux d’audit, registres des risques, comptes rendus de réunions, approbations de politiques).

A.5.34 — Protection de la vie privée et des données personnelles. Assurer la protection de la vie privée et des données à caractère personnel conformément aux lois et réglementations applicables. Pour les entreprises SaaS traitant des données clients contenant des données personnelles, ce contrôle fait le lien entre ISO 27001 et les exigences de protection des données comme le RGPD.

A.5.35 — Revue indépendante de la sécurité de l’information. Mener des revues indépendantes de l’ISMS à des intervalles planifiés ou lors de changements significatifs. C’est votre processus d’audit interne et de revue de direction.

A.5.36 — Conformité aux politiques, règles et normes de sécurité de l’information. Examiner régulièrement la conformité aux politiques et normes de sécurité de l’information de l’organisation. S’assurer que les politiques que vous avez rédigées sont effectivement suivies — par la surveillance, l’audit et la revue de direction.

A.5.37 — Procédures opérationnelles documentées. Documenter les procédures opérationnelles pour les installations de traitement de l’information et les mettre à disposition du personnel qui en a besoin. Manuels opérationnels, procédures opérationnelles standard et documentation opérationnelle des systèmes dans le périmètre de l’ISMS.

A.6 Contrôles liés aux personnes (8 contrôles)

Les contrôles liés aux personnes traitent de l’élément humain de la sécurité de l’information — de l’embauche jusqu’au départ, en passant par l’emploi.

A.6.1 — Vérification des antécédents. Mener des vérifications d’antécédents sur les candidats avant l’emploi. Le niveau de vérification doit être proportionné au rôle — les ingénieurs ayant accès en production aux données clients justifient des vérifications plus approfondies que les membres de l’équipe marketing.

A.6.2 — Conditions d’emploi. Les contrats de travail doivent stipuler les responsabilités en matière de sécurité de l’information de l’employé et de l’organisation. Inclure des clauses de confidentialité, des obligations d’utilisation acceptable et les conséquences des violations de la politique.

A.6.3 — Sensibilisation, éducation et formation à la sécurité de l’information. Tous les employés doivent recevoir une formation de sensibilisation à la sécurité appropriée, et le personnel ayant des rôles de sécurité spécifiques doit recevoir une formation spécifique au rôle. Formation annuelle de sensibilisation à la sécurité pour tout le personnel, complétée par une formation ciblée pour les ingénieurs (codage sécurisé), les administrateurs (sécurité cloud) et les managers (escalade des incidents).

A.6.4 — Processus disciplinaire. Établir un processus disciplinaire formel pour les employés qui commettent des violations de la politique de sécurité de l’information. Le processus doit être communiqué à tous les employés afin qu’ils comprennent les conséquences de la non-conformité.

A.6.5 — Responsabilités après la fin ou le changement d’emploi. Définir les responsabilités en matière de sécurité de l’information qui restent valables après la fin de l’emploi. Les accords de confidentialité qui survivent à l’emploi, la restitution des actifs et l’exigence de ne pas conserver d’informations de l’entreprise.

A.6.6 — Accords de confidentialité ou de non-divulgation. Identifier et documenter les exigences de confidentialité et de non-divulgation. Accords de confidentialité pour les employés, les prestataires et les tiers qui accèdent à des informations sensibles.

A.6.7 — Travail à distance. Mettre en œuvre des mesures de sécurité pour le travail à distance. Pour les entreprises SaaS (où le travail à distance est souvent la norme), cela couvre les exigences VPN, la sécurité des terminaux, les recommandations de sécurité du réseau domestique et les politiques de travail depuis des lieux publics.

A.6.8 — Signalement des événements de sécurité de l’information. Fournir un mécanisme permettant au personnel de signaler les événements de sécurité observés ou suspectés. Cela signifie des canaux de signalement clairs (un canal Slack, une adresse e-mail, un système de tickets), une formation sur ce qu’il faut signaler et une culture qui ne punit pas les signaleurs.

A.7 Contrôles physiques (14 contrôles)

Les contrôles physiques couvrent la sécurité des environnements physiques, des équipements et des services publics. Pour les entreprises SaaS qui opèrent entièrement dans le cloud sans centres de données physiques, plusieurs de ces contrôles sont candidats à l’exclusion dans le SoA — mais l’exclusion doit être justifiée, et certains contrôles physiques s’appliquent même aux organisations cloud-native.

A.7.1 — Périmètres de sécurité physique. Définir des périmètres de sécurité autour des zones contenant de l’information et des installations de traitement de l’information. Pour les entreprises SaaS avec des bureaux, cela s’applique à l’environnement de bureau — en particulier les zones où un travail sensible est effectué (zone de l’équipe sécurité, salles serveurs si elles existent).

A.7.2 — Accès physique. Les zones sécurisées doivent être protégées par des contrôles d’entrée appropriés. Accès par badge, gestion des visiteurs et accès restreint aux zones sensibles.

A.7.3 — Sécurisation des bureaux, salles et installations. Concevoir et mettre en œuvre la sécurité physique pour les bureaux, salles et installations. Cela inclut la sécurité des salles serveurs (le cas échéant), les politiques de bureau propre et le stockage sécurisé des documents physiques.

A.7.4 — Surveillance de la sécurité physique. Surveiller en continu les locaux contre les accès physiques non autorisés. Vidéosurveillance, systèmes de détection d’intrusion, agents de sécurité. Pour les entreprises SaaS entièrement distantes, ce contrôle peut être exclu s’il n’y a pas de locaux physiques à surveiller.

A.7.5 — Protection contre les menaces physiques et environnementales. Concevoir et mettre en œuvre une protection contre les menaces physiques et environnementales (incendie, inondation, tremblement de terre, panne de courant). Même les entreprises cloud-native doivent considérer la sécurité physique de leurs bureaux et les contrôles environnementaux maintenus par leurs fournisseurs cloud.

A.7.6 — Travail dans les zones sécurisées. Définir et mettre en œuvre des mesures de sécurité pour le travail dans les zones sécurisées. Restrictions sur les appareils électroniques dans les zones sécurisées, exigences de supervision et journalisation des accès.

A.7.7 — Bureau propre et écran verrouillé. Définir des règles de bureau propre et d’écran verrouillé. Verrouiller les écrans quand on s’éloigne du poste de travail, ne pas laisser de documents sensibles sur les bureaux et sécuriser les supports physiques dans un stockage verrouillé.

A.7.8 — Emplacement et protection des équipements. Positionner et protéger les équipements pour réduire les risques liés aux menaces environnementales et aux accès non autorisés. Pour les entreprises SaaS, cela s’applique principalement aux postes de travail des employés et à tout équipement réseau sur site.

A.7.9 — Sécurité des actifs hors des locaux. Protéger les actifs emportés hors des locaux. Chiffrement des ordinateurs portables, capacité d’effacement à distance, exigences VPN et politiques pour emporter des appareils en conférences, chez des clients ou à domicile.

A.7.10 — Supports de stockage. Gérer les supports de stockage tout au long de leur cycle de vie — acquisition, utilisation, transport et élimination. Cela inclut les disques durs, les périphériques USB et les supports de sauvegarde. Pour les entreprises SaaS, la gestion du cycle de vie du stockage cloud (chiffrement, contrôle d’accès, suppression sécurisée) est l’équivalent moderne.

A.7.11 — Services généraux. Protéger les installations de traitement de l’information contre les pannes de courant et autres perturbations des services généraux. Pour les entreprises SaaS cloud-native, votre fournisseur cloud gère cela pour l’infrastructure de production — mais considérez les onduleurs et l’alimentation de secours pour votre infrastructure réseau de bureau.

A.7.12 — Sécurité du câblage. Protéger le câblage transportant de l’énergie et des données contre l’interception, les interférences ou les dommages. Principalement pertinent pour les entreprises avec une infrastructure sur site ou un réseau de bureau.

A.7.13 — Maintenance des équipements. Maintenir correctement les équipements pour assurer leur disponibilité et intégrité continues. Pour les entreprises SaaS, cela s’applique aux appareils des employés (correctifs, renouvellement du matériel) et à tout équipement sur site.

A.7.14 — Mise au rebut ou réutilisation sécurisée des équipements. Effacer ou détruire de manière sécurisée les données sur les équipements avant leur mise au rebut ou réutilisation. Lors du décommissionnement des ordinateurs portables des employés, s’assurer que les disques durs sont effacés ou détruits de manière sécurisée. Lors du décommissionnement des ressources cloud, s’assurer que les données sont supprimées et le stockage libéré.

A.8 Contrôles technologiques (34 contrôles)

Les contrôles technologiques sont les mécanismes de sécurité technique qui protègent les systèmes d’information. Pour les entreprises SaaS, c’est généralement la section la plus vaste et la plus pertinente.

Terminaux et accès (A.8.1 - A.8.5)

A.8.1 — Terminaux utilisateur. Protéger l’information stockée, traitée ou accessible via les terminaux utilisateur. Cela signifie un logiciel de détection et réponse aux terminaux (EDR), le chiffrement de disque, les mises à jour automatiques de l’OS, les politiques de verrouillage d’écran et la capacité d’effacement à distance pour les appareils de l’entreprise. Pour les environnements BYOD, mettre en œuvre la gestion des appareils mobiles (MDM) ou des contrôles équivalents.

A.8.2 — Droits d’accès privilégié. Restreindre et gérer l’attribution et l’utilisation des droits d’accès privilégié. Séparer les comptes administrateur des comptes d’utilisation quotidienne, mettre en œuvre l’élévation de privilèges juste-à-temps, surveiller les sessions privilégiées et mener des revues régulières des accès privilégiés.

A.8.3 — Restriction d’accès à l’information. Restreindre l’accès à l’information conformément à la politique de contrôle d’accès. C’est la mise en œuvre technique de la politique définie dans A.5.15 — contrôle d’accès basé sur les rôles, contrôle d’accès basé sur les attributs, autorisation API et restrictions d’accès aux données basées sur la classification et le besoin d’en connaître.

A.8.4 — Accès au code source. Gérer l’accès au code source, aux outils de développement et aux bibliothèques logicielles. Pour les entreprises SaaS, cela signifie les contrôles d’accès aux dépôts (permissions GitHub/GitLab), les règles de protection de branche, la signature du code et la restriction de l’accès aux systèmes de construction et de déploiement.

A.8.5 — Authentification sécurisée. Mettre en œuvre des technologies et procédures d’authentification sécurisées. Authentification multi-facteurs pour tous les utilisateurs, intégration SSO, politiques de mots de passe forts (ou mieux, authentification sans mot de passe) et gestion sécurisée des sessions.

Configuration et gestion des vulnérabilités (A.8.6 - A.8.10)

A.8.6 — Gestion de la capacité. Surveiller et ajuster l’utilisation des ressources pour répondre aux exigences de capacité actuelles et futures. Configurations de mise à l’échelle automatique, tableaux de bord de surveillance de la capacité, alertes sur les seuils d’épuisement des ressources et planification de la capacité pour la croissance.

A.8.7 — Protection contre les logiciels malveillants. Mettre en œuvre une protection contre les logiciels malveillants combinée à la sensibilisation des utilisateurs. EDR/antivirus sur les terminaux, filtrage des e-mails, filtrage web et formation des utilisateurs à reconnaître l’hameçonnage et les contenus malveillants.

A.8.8 — Gestion des vulnérabilités techniques. Obtenir des informations sur les vulnérabilités techniques, évaluer l’exposition et prendre les mesures appropriées. Analyse des vulnérabilités, analyse des dépendances (outils SCA), surveillance des CVE pour votre pile technologique, processus de gestion des correctifs et SLA définis pour la remédiation des vulnérabilités selon la gravité.

A.8.9 — Gestion de la configuration. Établir, documenter, mettre en œuvre, surveiller et revoir les configurations du matériel, des logiciels, des services et des réseaux. Infrastructure-as-code, référentiels de configuration, détection de dérive et modèles d’infrastructure immuable. C’est l’un des 11 nouveaux contrôles de 2022 et il est particulièrement pertinent pour les entreprises SaaS gérant une infrastructure cloud.

A.8.10 — Suppression de l’information. Supprimer l’information lorsqu’elle n’est plus nécessaire. Politiques de conservation des données avec application automatisée, suppression sécurisée des données clients à la fin du contrat et purge des stockages de données temporaires. Autre nouveau contrôle de 2022.

Protection des données (A.8.11 - A.8.14)

A.8.11 — Masquage des données. Masquer les données conformément à la politique de contrôle d’accès et aux exigences métier. Les données de production ne doivent pas être utilisées dans les environnements de développement ou de test sans masquage. Les données personnelles des clients doivent être masquées dans les journaux, les analyses et les outils de support lorsque les données complètes ne sont pas nécessaires. C’est un nouveau contrôle de 2022.

A.8.12 — Prévention des fuites de données. Appliquer des mesures de prévention des fuites de données aux systèmes, réseaux et terminaux. Outils DLP sur les terminaux et la messagerie, restrictions de copie de données vers un stockage externe, surveillance des exports massifs de données et limitation du débit des API pour prévenir l’extraction de données. Autre nouveau contrôle de 2022.

A.8.13 — Sauvegarde de l’information. Maintenir des copies de sauvegarde testées de l’information, des logiciels et des configurations système. Sauvegardes automatisées avec des RPO définis, chiffrement des sauvegardes, stockage hors site et — surtout — tests réguliers de restauration. Une sauvegarde qui n’a jamais été testée n’est pas une sauvegarde.

A.8.14 — Redondance des installations de traitement de l’information. Mettre en œuvre la redondance des installations de traitement de l’information suffisante pour répondre aux exigences de disponibilité. Déploiements multi-AZ, réplication de base de données, répartition de charge et mécanismes de basculement.

Journalisation et surveillance (A.8.15 - A.8.16)

A.8.15 — Journalisation. Produire, stocker, protéger et analyser les journaux qui enregistrent les activités, les exceptions, les défaillances et d’autres événements pertinents. Journalisation centralisée (ELK, Splunk, Datadog), politiques de conservation des journaux, stockage de journaux inviolable et sources de journaux définies (journaux applicatifs, journaux d’accès, journaux d’infrastructure, journaux d’événements de sécurité).

A.8.16 — Activités de surveillance. Surveiller les réseaux, systèmes et applications pour détecter les comportements anormaux et prendre les mesures appropriées. SIEM ou plateformes de surveillance qui corrèlent les événements, alertent sur les anomalies et permettent l’investigation. C’est un nouveau contrôle de 2022, reflétant l’importance de la surveillance continue.

Sécurité des opérations (A.8.17 - A.8.22)

A.8.17 — Synchronisation des horloges. Synchroniser les horloges des systèmes de traitement de l’information avec une source de temps approuvée. Configuration NTP sur tous les systèmes. Cela semble trivial mais est essentiel pour la corrélation des journaux lors des investigations d’incidents.

A.8.18 — Utilisation de programmes utilitaires privilégiés. Restreindre et contrôler l’utilisation de programmes utilitaires capables de contourner les contrôles systèmes et applicatifs. Limiter l’accès aux outils d’administration de base de données, aux utilitaires de gestion système et aux outils de débogage en production.

A.8.19 — Installation de logiciels sur les systèmes opérationnels. Mettre en œuvre des procédures pour contrôler l’installation de logiciels sur les systèmes opérationnels. Restreindre l’installation de logiciels sur les appareils des employés, contrôler ce qui peut être déployé en production et maintenir des listes de logiciels approuvés.

A.8.20 — Sécurité des réseaux. Gérer et contrôler les réseaux pour protéger l’information dans les systèmes et applications. Segmentation réseau, règles de pare-feu, configuration VPC, groupes de sécurité et listes de contrôle d’accès réseau dans les environnements cloud.

A.8.21 — Sécurité des services réseau. Identifier, mettre en œuvre et surveiller les mécanismes de sécurité, les niveaux de service et les exigences de gestion des services réseau. Cela couvre à la fois les services réseau internes et les services réseau tiers (FAI, CDN, fournisseurs DNS).

A.8.22 — Séparation des réseaux. Séparer les groupes de services d’information, d’utilisateurs et de systèmes d’information sur les réseaux. Environnements de production, de pré-production et de développement sur des réseaux/VPC séparés. Réseaux destinés aux clients et réseaux de gestion interne séparés. Serveurs de base de données non directement accessibles depuis Internet.

Sécurité web et applicative (A.8.23 - A.8.24)

A.8.23 — Filtrage web. Filtrer l’accès aux sites web externes pour réduire l’exposition aux contenus malveillants. Filtrage DNS, filtrage web par proxy ou filtrage d’URL au niveau des terminaux pour bloquer l’accès aux sites malveillants connus, aux pages d’hameçonnage et aux contenus inappropriés. C’est un nouveau contrôle de 2022.

A.8.24 — Utilisation de la cryptographie. Définir et mettre en œuvre des règles pour l’utilisation efficace de la cryptographie, y compris la gestion des clés. TLS 1.2+ pour toutes les données en transit, AES-256 pour les données au repos, gestion appropriée des clés (rotation, stockage en HSM ou gestionnaire de secrets) et une politique cryptographique définissant les algorithmes approuvés.

Sécurité du développement (A.8.25 - A.8.34)

A.8.25 — Cycle de développement sécurisé. Établir et appliquer des règles pour le développement sécurisé des logiciels et systèmes. Normes de codage sécurisé, exigences de sécurité dans les user stories, modélisation des menaces pendant la conception, tests de sécurité dans le CI/CD et revue de sécurité pour les déploiements en production.

A.8.26 — Exigences de sécurité des applications. Identifier, spécifier et approuver les exigences de sécurité de l’information pour le développement ou l’acquisition d’applications. Définir les exigences de sécurité (authentification, autorisation, validation des entrées, chiffrement) dans le cadre du processus de conception de l’application.

A.8.27 — Architecture système sécurisée et principes d’ingénierie. Établir, documenter, maintenir et appliquer des principes d’ingénierie de systèmes sécurisés. Défense en profondeur, moindre privilège, sécurité par défaut, validation des entrées, configurations sécurisées par défaut. Documenter ces principes et s’assurer qu’ils sont suivis dans les décisions architecturales.

A.8.28 — Codage sécurisé. Appliquer les principes de codage sécurisé au développement logiciel. Sensibilisation au Top 10 OWASP, validation des entrées, requêtes paramétrées, encodage de sortie, gestion sécurisée des sessions et manipulation sécurisée des secrets dans le code. C’est un nouveau contrôle de 2022.

A.8.29 — Tests de sécurité en développement et acceptance. Définir et mettre en œuvre des processus de tests de sécurité dans le cycle de développement. SAST (analyse statique), DAST (analyse dynamique), analyse des dépendances, tests d’intrusion et critères d’acceptance de sécurité pour les mises en production.

A.8.30 — Développement externalisé. Diriger, surveiller et revoir les activités liées au développement externalisé de systèmes. Lorsque vous utilisez des prestataires ou des équipes de développement externalisées, assurez-vous qu’ils suivent vos pratiques de développement sécurisé, que leur code est revu et que leur accès est contrôlé.

A.8.31 — Séparation des environnements de développement, de test et opérationnels. Séparer les environnements de développement, de test et opérationnels pour réduire les risques d’accès ou de changements non autorisés à l’environnement opérationnel. Comptes AWS ou projets GCP distincts pour le développement, la pré-production et la production. Aucun identifiant de production dans les environnements de développement. Aucune donnée client dans les environnements hors production.

A.8.32 — Gestion des changements. Contrôler les changements apportés aux installations de traitement de l’information et aux systèmes d’information. Gestion formelle des changements pour les systèmes de production — demandes de changement, évaluation des risques, approbation, tests, déploiement et procédures de retour en arrière.

A.8.33 — Informations de test. Protéger les informations de test de manière appropriée. Les données de test doivent être anonymisées ou synthétiques — ne jamais utiliser de vraies données clients dans les environnements de test. Lorsque les données de test doivent ressembler aux données de production, utiliser le masquage des données (A.8.11).

A.8.34 — Protection des systèmes d’information pendant les tests d’audit. Planifier et convenir des tests d’audit impliquant des systèmes opérationnels pour minimiser l’impact métier. Lorsque des tests d’intrusion ou des analyses de vulnérabilités ciblent les systèmes de production, les planifier pour minimiser les perturbations et s’assurer que des procédures de retour en arrière sont en place.

Les 11 nouveaux contrôles d’ISO 27001:2022

La révision 2022 a introduit 11 contrôles qui n’existaient pas dans la version 2013. Ceux-ci reflètent l’évolution du paysage des menaces et des pratiques technologiques modernes :

Contrôle	Thème	Description	Pertinence SaaS
A.5.7	Organisationnel	Renseignement sur les menaces	Élevée — essentiel pour comprendre les menaces pesant sur votre pile
A.5.23	Organisationnel	Sécurité des services cloud	Critique — concerne directement l’infrastructure SaaS
A.5.30	Organisationnel	Préparation des TIC pour la continuité d’activité	Élevée — PRA/PCA pour les services cloud
A.7.4	Physique	Surveillance de la sécurité physique	Faible pour le SaaS cloud-native ; peut être exclu
A.8.9	Technologique	Gestion de la configuration	Critique — IaC et gestion de la configuration cloud
A.8.10	Technologique	Suppression de l’information	Élevée — gestion du cycle de vie des données
A.8.11	Technologique	Masquage des données	Élevée — protection des données dans les environnements hors production
A.8.12	Technologique	Prévention des fuites de données	Moyenne-Élevée — DLP pour les terminaux et les API
A.8.16	Technologique	Activités de surveillance	Critique — surveillance continue de la sécurité
A.8.23	Technologique	Filtrage web	Moyenne — protection des terminaux
A.8.28	Technologique	Codage sécurisé	Critique — fondamental pour le développement SaaS

Ces nouveaux contrôles sont souvent un point focal lors des audits car les auditeurs veulent vérifier que les organisations les ont traités — en particulier lors de la transition depuis un ISMS basé sur 2013.

Attributs des contrôles

ISO 27001:2022 introduit cinq attributs pour chaque contrôle, permettant une catégorisation multidimensionnelle :

Type de contrôle

• Préventif — empêche la survenue d’un incident de sécurité
• Détectif — détecte la survenue d’un incident de sécurité
• Correctif — corrige l’impact d’un incident de sécurité après sa survenue

Propriétés de sécurité de l’information

Ce que le contrôle protège dans la triade CIA :

• Confidentialité
• Intégrité
• Disponibilité

Concepts de cybersécurité (alignement NIST CSF)

• Identifier — comprendre l’environnement et les risques
• Protéger — mettre en œuvre des mesures de sauvegarde
• Détecter — identifier les événements de sécurité
• Répondre — agir sur les événements détectés
• Récupérer — restaurer les capacités

Capacités opérationnelles

Regroupent les contrôles par fonction opérationnelle :

• Gouvernance, Gestion des actifs, Protection de l’information, Sécurité des ressources humaines, Sécurité physique, Sécurité des systèmes et réseaux, Sécurité des applications, Configuration sécurisée, Gestion des identités et des accès, Gestion des menaces et des vulnérabilités, Continuité, Sécurité des relations fournisseurs, Conformité juridique, Gestion des événements de sécurité de l’information, Assurance de la sécurité de l’information

Domaines de sécurité

• Gouvernance et écosystème
• Protection
• Défense
• Résilience

Ces attributs sont utiles pour associer les contrôles à d’autres cadres (NIST CSF, CIS Controls), générer différentes vues de votre environnement de contrôle (par exemple, montrer tous les contrôles détectifs, montrer tous les contrôles protégeant la confidentialité) et démontrer aux auditeurs que votre sélection de contrôles est réfléchie et multidimensionnelle.

Exclusions typiques pour le SaaS

Chaque contrôle de l’Annexe A n’est pas pertinent pour chaque entreprise SaaS. La Déclaration d’applicabilité documente vos décisions d’inclusion et d’exclusion avec justification. Les exclusions courantes pour les entreprises SaaS cloud-native incluent :

Contrôles physiques souvent exclus

A.7.1-A.7.6 (Périmètres physiques, accès, bureaux, surveillance, environnement, zones sécurisées) — Si votre organisation est entièrement distante sans bureau physique, ou si votre bureau ne contient pas d’installations de traitement de l’information (tout le traitement se fait dans le cloud), certains de ces contrôles peuvent être exclus. Cependant, si les employés travaillent depuis un bureau avec des postes de travail d’entreprise, un sous-ensemble peut toujours s’appliquer.

A.7.8 (Emplacement et protection des équipements) — Si vous n’avez pas de serveurs sur site ou d’équipements réseau au-delà de l’équipement de bureau standard.

A.7.11 (Services généraux) — Si toute l’infrastructure de production est dans le cloud et que votre bureau n’héberge pas d’équipements de traitement de l’information critiques.

A.7.12 (Sécurité du câblage) — Si vous n’avez pas de centre de données sur site ou d’infrastructure réseau spécialisée.

Contrôles rarement exclus pour le SaaS

Pratiquement aucune entreprise SaaS ne peut justifier l’exclusion de :

• A.5.1 (Politiques) — chaque ISMS a besoin de politiques
• A.5.15-A.5.18 (Contrôle d’accès) — chaque SaaS a des accès à gérer
• A.5.24-A.5.27 (Gestion des incidents) — les incidents arrivent à toute organisation
• A.8.5 (Authentification sécurisée) — l’authentification est fondamentale
• A.8.9 (Gestion de la configuration) — la configuration cloud est toujours pertinente
• A.8.15-A.8.16 (Journalisation et surveillance) — chaque système de production a besoin de journalisation
• A.8.25 (Cycle de développement sécurisé) — chaque SaaS développe des logiciels

Exigences de justification

L’exclusion n’est pas un raccourci. Pour chaque contrôle exclu, votre SoA doit indiquer :

• Le contrôle exclu (numéro de référence et titre)
• La justification — pourquoi le risque que le contrôle traite n’est pas applicable à votre organisation
• La confirmation que l’exclusion ne compromet pas la sécurité de l’information

« Nous n’avons pas de serveurs sur site, par conséquent A.7.12 (Sécurité du câblage) est exclu car il n’y a pas de câblage transportant des données ou de l’énergie à protéger dans le périmètre de l’ISMS » est une justification valide. « Non applicable » sans explication ne l’est pas.

Association des contrôles au plan de traitement des risques

Le plan de traitement des risques et les contrôles de l’Annexe A doivent être explicitement connectés. Cette association est l’épine dorsale de votre ISMS et la principale chose que les auditeurs vérifient.

Du risque au contrôle

Pour chaque risque dans votre plan de traitement :

1. Identifiez les actions de traitement — quelles mesures spécifiques traitent le risque
2. Associez chaque action à un ou plusieurs contrôles de l’Annexe A — quelle référence de contrôle s’applique
3. Documentez l’association à la fois dans le plan de traitement des risques et dans le SoA
4. Mettez en œuvre le contrôle — déployez la mesure technique ou organisationnelle
5. Collectez les preuves — démontrez que le contrôle est opérationnel

Du contrôle au risque

Pour chaque contrôle de l’Annexe A dans votre SoA :

1. Identifiez le(s) risque(s) qu’il traite — remontez au registre des risques
2. Documentez la référence du risque dans la justification du SoA
3. Vérifiez la couverture — assurez-vous qu’il n’y a pas de lacunes où des risques existent sans contrôles correspondants

Validation de la couverture

Examinez votre association pour la complétude :

• Chaque risque noté au-dessus de votre seuil d’acceptation doit être associé à au moins un contrôle de l’Annexe A (ou être formellement accepté)
• Chaque contrôle de l’Annexe A inclus doit être associé à au moins un risque (ou une exigence légale/réglementaire/contractuelle)
• Aucun contrôle orphelin — contrôles mis en œuvre sans justification claire
• Aucun risque orphelin — risques au-dessus du seuil sans traitement correspondant

Ce référencement croisé est ce qui transforme un exercice de checklist en un système intégré de gestion des risques. Les auditeurs testent spécifiquement cette traçabilité, et les lacunes sont une source fréquente de constats de non-conformité.

Comment GRCTrail vous aide

GRCTrail offre aux équipes SaaS une plateforme structurée pour gérer les contrôles de l’Annexe A, de la sélection à la mise en œuvre et à la surveillance continue.

• Catalogue interactif des contrôles de l’Annexe A avec des directives de mise en œuvre spécifiques au SaaS pour chacun des 93 contrôles, afin que votre équipe sache exactement ce que chaque contrôle signifie dans un contexte cloud-native plutôt que d’interpréter le langage ISO générique
• Génération automatisée du SoA qui s’appuie sur votre évaluation des risques pour associer les risques aux contrôles, justifier les inclusions et exclusions, et maintenir la traçabilité — le document que les auditeurs examinent le plus longtemps
• Suivi de la mise en œuvre des contrôles avec collecte de preuves reliant chaque contrôle de l’Annexe A à son état de mise en œuvre, son propriétaire assigné et les preuves à l’appui, garantissant que rien ne passe entre les mailles du filet entre l’évaluation des risques et l’audit

Démarrer avec GRCTrail →

Guides connexes

• Qu’est-ce qu’ISO 27001 ? Un guide pour les entreprises SaaS
• Évaluation des risques ISO 27001 : Processus, méthodologie et exemples
• Déclaration d’applicabilité ISO 27001 : Comment la créer
• Guide du contrôle d’accès ISO 27001
• Guide des politiques ISO 27001
• Checklist de certification ISO 27001
• Exigences ISO 27001 : Comprendre les Clauses 4-10