Le Statement of Applicability (SoA) est, selon la clause 6.1.3 d) de l'ISO/IEC 27001:2022, un document obligatoire et le lien central entre le traitement des risques et les contrôles mis en œuvre. Il répertorie les 93 contrôles de l'Annexe A, documente pour chaque contrôle son applicabilité, la justification de sa sélection ou de son exclusion, et son statut de mise en œuvre. Sans SoA, il n'y a pas de certification – et un SoA mal structuré est en Stage 1 la cause la plus fréquente d'un report de l'audit Stage 2.

Cet article traite :

• Les exigences normatives relatives au SoA issues de la clause 6.1.3 d)
• Les colonnes recommandées et leurs exigences de contenu
• Le lien entre le plan de traitement des risques et le SoA
• La correspondance du traitement sur les quatre thèmes A.5 (organisationnel), A.6 (relatif aux personnes), A.7 (physique), A.8 (technologique)
• Les constats d'audit fréquents et comment les éviter
• Un modèle de SoA éprouvé comme point de départ

Ce guide s'adresse aux responsables SMSI, aux RSSI et aux consultants qui construisent ou révisent le SoA. Nous présentons l'interprétation de la norme telle que les auditeurs suisses et européens lisent le document, ainsi que des exemples concrets de formulations pour les justifications.

La clause 6.1.3 d) de l'ISO 27001:2022 exige explicitement un Statement of Applicability contenant les éléments suivants :

1. les contrôles nécessaires (conformément au plan de traitement des risques),
2. la justification de leur inclusion,
3. s'ils sont mis en œuvre ou non,
4. la justification de l'exclusion des contrôles de l'Annexe A.

L'Annexe A de l'ISO 27001:2022 contient 93 contrôles en quatre groupes : A.5 Contrôles organisationnels (37 contrôles), A.6 Contrôles relatifs aux personnes (8 contrôles), A.7 Contrôles physiques (14 contrôles), A.8 Contrôles technologiques (34 contrôles). Chacun de ces 93 contrôles doit être adressé dans le SoA – soit comme applicable avec description de la mise en œuvre, soit comme exclu avec une justification substantielle.

Précision importante : un contrôle ne peut être déclaré non applicable que s'il ne traite aucun risque pour l'organisation. Quiconque exclut A.8.24 (Cryptographie) avec la justification « nous n'utilisons pas de cryptographie » doit expliquer comment tous les flux de données (TLS, chiffrement de base de données, sauvegarde, authentification) se passent de cryptographie. En règle générale, ce n'est pas plausible et cela conduit à une non-conformité mineure. Une justification sérieuse ressemble plutôt à : « Le contrôle A.7.13 (Maintenance des équipements) n'est pas applicable car tous les équipements informatiques sont entièrement loués et entretenus par le fournisseur de poste de travail cloud – la responsabilité incombe contractuellement au fournisseur. »

La norme n'impose aucune forme de tableau spécifique, mais une structure de SoA éprouvée en pratique comprend les colonnes suivantes :

1. ID du contrôle (p. ex. A.5.7, A.8.24)
2. Intitulé du contrôle (selon l'Annexe A)
3. Applicable ? (Oui / Non)
4. Justification de la sélection / de l'exclusion (explication substantielle, pas un simple n/a)
5. Statut de mise en œuvre (mis en œuvre / partiellement mis en œuvre / planifié ; avec date cible pour les éléments planifiés)
6. Responsable / Owner (fonction ou personne)
7. Description de la mise en œuvre (référence à la politique, à la procédure, à la mesure technique)
8. Preuve de vérification (ID de document, journal, résultat d'audit)
9. Risques associés (IDs du registre des risques)
10. Dernière révision (date, auditeur)
11. Remarques / commentaires (p. ex. mesures compensatoires, amélioration planifiée)

Optionnel mais recommandé pour les secteurs réglementés : colonnes supplémentaires pour les références réglementaires (p. ex. Circulaire FINMA 2023/1, NIS2 art. 21, LPD art. 8 / OLPD art. 3, BAIT). Cela simplifie les audits de surveillance ultérieurs ou les audits clients portant sur des normes réglementaires spécifiques.

Évitez un SoA composé de seulement trois colonnes (Applicable – Oui/Non – Référence à la politique). Il est certes conforme au minimum normatif, mais il n'est pas utile pour les audits externes, les audits clients et les recertifications – et génère des questions répétées lors des audits de surveillance.

Le SoA n'est pas autonome ; il doit refléter la logique du plan de traitement des risques. La clause 6.1.3 exige que les contrôles sélectionnés adressent les risques identifiés – le SoA en est la preuve.

Approche recommandée :

1. Créer le registre des risques : chaque entrée de risque reçoit un ID (R-001, R-002, ...), une description, une probabilité d'occurrence, une importance du préjudice et un propriétaire du risque.
2. Choisir le traitement des risques : pour chaque risque, une des quatre options issues de l'ISO/IEC 27005 : modification du risque (appliquer des contrôles), partage du risque (assurance, externalisation), acceptation du risque (documentée formellement), évitement du risque (arrêter l'activité).
3. Attribuer les contrôles : en cas de modification du risque – quels contrôles de l'Annexe A (et lesquels en complément, éventuellement hors Annexe A) adressent le risque ?
4. Mettre à jour le SoA : chaque sélection de contrôle est référencée dans le SoA dans la colonne Risques associés avec les IDs R.
5. Documenter les risques acceptés : si un risque est accepté, cela doit être approuvé par écrit par le propriétaire du risque (clause 6.1.3 f)).

Erreur fréquente : le SoA liste tous les contrôles comme applicables sans que les IDs de risque soient renseignés. L'auditeur externe pose alors la question : « Quel risque A.5.34 (Protection de la vie privée et des données personnelles) adresse-t-il concrètement dans votre organisation ? » Quiconque ne peut pas répondre n'a pas apporté la preuve du lien – non-conformité mineure à la clause 6.1.3.

La version 2022 a réduit l'Annexe A de 14 domaines (A.5–A.18 dans la version 2013) à quatre thèmes. Cela aide à regrouper les contrôles par responsabilité et à répartir la maintenance du SoA sur les propriétaires appropriés.

A.5 Contrôles organisationnels (37 contrôles) – Owner : responsable SMSI, direction, service juridique :

Politiques, rôles, gestion des fournisseurs, gestion des incidents, continuité, conformité. Exemples : A.5.1 (Politiques de sécurité de l'information), A.5.7 (Threat intelligence – NOUVEAU), A.5.23 (Sécurité de l'information pour l'utilisation des services cloud – NOUVEAU), A.5.30 (Préparation des TIC à la continuité d'activité – NOUVEAU).

A.6 Contrôles relatifs aux personnes (8 contrôles) – Owner : RH, responsable SMSI :

Vérification des antécédents, conditions d'emploi, sensibilisation, procédures disciplinaires, télétravail (NOUVEAU sous A.6.7). Le plus compact des quatre thèmes ; souvent sous-estimé lors de l'audit car le propriétaire RH n'est pas représenté dans le programme d'audit.

A.7 Contrôles physiques (14 contrôles) – Owner : gestion des installations, exploitation informatique :

Protection du périmètre, contrôle d'accès, politique bureau propre et écran propre, zones fournisseurs, maintenance. Pour les entreprises 100 % cloud, de nombreux contrôles A.7 sont à réduire au site de bureau ou au contrat avec le fournisseur cloud.

A.8 Contrôles technologiques (34 contrôles) – Owner : exploitation informatique, ingénierie, SecOps :

Sécurité des endpoints, gestion des accès, cryptographie, journalisation, réseau, sécurité applicative, sauvegarde. Comprend les nouveaux contrôles A.8.9 (Gestion de la configuration), A.8.10 (Suppression de l'information), A.8.11 (Masquage des données), A.8.12 (Prévention des fuites de données), A.8.16 (Activités de surveillance), A.8.22 (Filtrage web), A.8.23 (Codage sécurisé), A.8.28 (Codage sécurisé complémentaire), A.8.29 (Tests de sécurité dans le développement et l'acceptation).

Nous recommandons d'organiser le SoA par onglets correspondant aux quatre thèmes (p. ex. quatre onglets dans un Excel) et d'assigner un propriétaire par onglet. Cela accélère la révision annuelle du SoA.

Dans la pratique des audits, des faiblesses récurrentes apparaissent sur le SoA. Les sept constats suivants sont ceux que nous observons le plus souvent – avec la recommandation pour les éviter.

• Justifications génériques : formules vagues telles que « bonne pratique » ou « standard du secteur » sans lien concret avec les risques. Recommandation : référencer les IDs R du registre des risques.
• Exclusion sans justification : A.7.X est marqué comme non applicable avec la mention n/a. Recommandation : expliquer la substance (p. ex. externalisation complète du poste de travail cloud à Microsoft 365 avec contrat de sous-traitance documenté).
• SoA et mise en œuvre divergent : statut « mis en œuvre » mais l'auditeur ne trouve aucune preuve technique. Recommandation : renseigner la colonne de preuve de vérification avec l'ID du document.
• SoA obsolète : dernière mise à jour il y a 18 mois. Recommandation : révision obligatoire au minimum annuelle, déclenchée par la revue de direction ou lors de changements significatifs.
• SoA et plan de traitement des risques incohérents : des risques avec traitement « Modification » font référence à des contrôles marqués comme exclus dans le SoA. Recommandation : vérification croisée à chaque mise à jour des deux documents.
• Propriétaire absent : sans propriétaire clair par contrôle, le statut de mise en œuvre ne peut pas être confirmé sans question préalable. Recommandation : utiliser une fonction (et non une personne) comme propriétaire – cela résiste aux changements de personnel.
• Absence de preuve de vérification : description de mise en œuvre sans référence à une pièce justificative. Recommandation : pour chaque contrôle mis en œuvre, au moins une pièce justificative vérifiable (lien vers la politique, capture de configuration, rapport d'audit).

Une non-conformité majeure à l'obligation du SoA (p. ex. absence totale ou omission de plusieurs contrôles de l'Annexe A) bloque la certification. Des non-conformités mineures systématiques risquent d'être escaladées en majeure lors de l'audit de surveillance.

Nous recommandons de maintenir le SoA sous forme d'Excel structuré ou comme vue base de données depuis une plateforme SMSI – pas comme document Word. Le format tableau permet le filtrage, le tri et les rapports automatisés lors des audits.

Exemple de ligne pour A.5.7 (Threat intelligence) dans une PME B2B SaaS typique :

• ID du contrôle : A.5.7
• Intitulé du contrôle : Threat intelligence
• Applicable : Oui
• Justification : Plusieurs risques adressent des menaces externes (R-007 attaques de phishing, R-012 compromission de la chaîne d'approvisionnement) ; une évaluation régulière du paysage des menaces est nécessaire.
• Statut : Mis en œuvre
• Owner : RSSI
• Mise en œuvre : Abonnement aux bulletins BACS-CSIRT, briefing mensuel sur les menaces depuis une source commerciale (Recorded Future), atelier de modélisation des menaces trimestriel, intégration dans la revue de direction trimestrielle.
• Preuve de vérification : Doc-ID POL-027 (Politique de Threat Intelligence), preuves de formation T1–T4, confirmation d'abonnement BACS.
• Risques associés : R-007, R-012, R-024
• Dernière révision : 15.04.2026 par M. Grob (SIDD)
• Commentaire : La source Recorded Future expire en 2027 – évaluer une alternative d'ici T3/2026.

Une telle ligne permet à l'auditeur externe de comprendre en 30 secondes que le contrôle est effectivement appliqué, par qui, avec quelle preuve et avec quelle perspective. C'est le standard auquel nous nous conformons – pas la variante minimaliste Oui / référence à la politique.

SIDD réalise des SoA clés en main pour les entreprises suisses et les maintient sur le cycle de certification de trois ans. Dans le cadre de notre mandat de mise en œuvre SMSI / ISO 27001, nous construisons le registre des risques, dérivons le plan de traitement des risques et créons un SoA qui tient pleinement compte des 93 contrôles de l'Annexe A. Nous fournissons un modèle de SoA éprouvé et l'adaptons à votre contexte sectoriel (FinTech, MedTech, industrie, secteur public, B2B SaaS).

Pour la maintenance continue, nous recommandons la plateforme Priverion : elle relie le registre des risques, le SoA, le catalogue de mesures et la piste d'audit dans un seul modèle de données, de sorte que les incohérences sont automatiquement détectées et visualisées via le tableau de bord. En présence d'un SMSI existant, nous examinons votre SoA actuel par rapport aux constats d'audit typiques et livrons en une mission de 5 jours un plan d'amélioration priorisé. Pour un mandat RSSI externe qui porte durablement la responsabilité du SoA, combinez notre offre CISO / RSSI.

Envoyez-nous votre SoA actuel (ou une description de l'état des lieux) via le formulaire de contact – nous fournissons une première évaluation dans les 48 heures. Pour un mandat formel, demandez une offre.