SOA ISO 27001 : Statement of Applicability Complet

Qu est-ce que la SOA et pourquoi est-elle centrale

La SOA remplit plusieurs fonctions essentielles dans le SMSI :

• Fonction de traçabilité : elle lie chaque contrôle aux risques qu il traite et aux objectifs de la PSSI
• Fonction de pilotage : elle donne une vue d ensemble de la maturité du SMSI sur les 93 contrôles
• Fonction d audit : l auditeur l utilise comme base pour planifier ses vérifications
• Fonction de communication : elle démontre aux parties intéressées le niveau de sécurité atteint

Structure d une SOA conforme ISO 27001:2022

Une SOA complète doit contenir les colonnes suivantes pour chaque contrôle :

Colonne	Description	Exemple
Référence	Numéro du contrôle Annexe A	A.5.1
Intitulé du contrôle	Nom officiel du contrôle	Politiques de sécurité de l information
Applicable (O/N)	Le contrôle est-il retenu	Oui
Justification d inclusion	Risque(s) traité(s) par ce contrôle	R-003 : Absence de cadre de gouvernance
Justification d exclusion	Raison si non applicable	N/A (pas de développement interne)
État d implémentation	Niveau de mise en oeuvre	Implémenté / En cours / Planifié
Preuve	Référence documentaire	PSSI v2.1, approuvée le 15/01/2026
Responsable	Propriétaire du contrôle	RSSI
Date de dernière revue	Dernière vérification	15/03/2026

Méthodologie de rédaction en 6 étapes

1. Partir de l analyse de risques : les contrôles retenus doivent répondre aux risques identifiés dans le registre des risques ISO 27005
2. Parcourir les 93 contrôles : évaluer l applicabilité de chaque contrôle au regard du périmètre et du contexte
3. Justifier chaque décision : documenter pourquoi un contrôle est retenu ou exclu
4. Évaluer l état d implémentation : utiliser une échelle à 4 niveaux (non implémenté, partiel, substantiel, complet)
5. Identifier les preuves : associer à chaque contrôle implémenté les documents et enregistrements probants
6. Faire valider par la direction : la SOA doit être approuvée et signée par la direction

Exclusions autorisées et justifications acceptables

Tous les contrôles ne sont pas applicables à tous les organismes. Les justifications d exclusion acceptées par les auditeurs sont :

Motif d exclusion	Exemple	Acceptation
Activité hors périmètre	A.8.28 (codage sécurisé) si pas de développement	Accepté si justifié
Technologie non utilisée	A.8.1 (terminaux) si pas de BYOD ni mobilité	Accepté
Risque transféré	Contrôle couvert par un sous-traitant	Accepté si contrat documenté
Risque jugé négligeable	Risque résiduel sous le seuil d acceptation	Accepté si documenté

Articuler la SOA avec le plan de traitement des risques

La SOA et le Plan de Traitement des Risques (PTR) sont intimement liés. Le PTR définit les actions à entreprendre pour ramener les risques à un niveau acceptable, et la SOA documente les contrôles qui implémentent ces actions :

EXEMPLE D ARTICULATION SOA / PTR :

Risque R-007 : Accès non autorisé aux données RH
 Impact: 4 (Critique) | Vraisemblance: 3 (Probable) | Risque: 12

Plan de traitement :
 Action 1 : Déployer MFA sur l application RH
 -> SOA : A.8.5 (Authentification sécurisée) = Applicable, Implémenté
 Action 2 : Revoir les droits d accès trimestriellement
 -> SOA : A.5.18 (Droits d accès) = Applicable, Implémenté
 Action 3 : Chiffrer la base de données RH
 -> SOA : A.8.24 (Cryptographie) = Applicable, En cours

Risque résiduel après traitement : 4 x 1 = 4 (Modéré - ACCEPTÉ)

Les 4 niveaux de maturité d implémentation

Pour chaque contrôle retenu, évaluez son niveau d implémentation selon cette échelle :

Niveau	État	Description	Scoring
0	Non implémenté	Le contrôle n existe pas ou n est pas documenté	0%
1	Partiel	Le contrôle existe de manière informelle ou incomplète	25%
2	Substantiel	Le contrôle est implémenté et documenté mais pas systématiquement appliqué	75%
3	Complet	Le contrôle est implémenté, documenté, appliqué et révisé régulièrement	100%

Un score global de maturité peut être calculé pour le rapport à la direction :

Score SOA = (Somme des niveaux des contrôles applicables) / (3 x Nombre de contrôles applicables) x 100

L objectif pour la certification est d atteindre un score supérieur à 80% avec aucun contrôle critique à 0.

Erreurs courantes dans la SOA

1. SOA déconnectée de l analyse de risques : les contrôles retenus doivent correspondre aux risques identifiés. Une SOA qui retient tous les contrôles "par défaut" manque de rigueur
2. Pas de justification des exclusions : chaque "Non applicable" doit être argumenté avec le risque résiduel
3. État d implémentation optimiste : ne marquez un contrôle comme "Implémenté" que si vous avez les preuves documentaires
4. SOA non versionnée : le document doit porter un numéro de version et un historique des modifications
5. SOA non validée par la direction : la clause 6.1.3 exige une approbation formelle

Exemple de SOA pour les contrôles critiques

Réf	Contrôle	Applicable	État	Justification
A.5.1	Politiques de sécurité	Oui	Complet	R-001 : Cadre gouvernance sécurité
A.5.9	Inventaire des actifs	Oui	Substantiel	R-002 : Actifs non identifiés
A.5.23	Sécurité cloud	Oui	En cours	R-015 : Services cloud non maîtrisés
A.6.3	Sensibilisation	Oui	Complet	R-008 : Erreur humaine phishing
A.8.5	Authentification sécurisée	Oui	Complet	R-007 : Accès non autorisé
A.8.7	Anti-malware	Oui	Complet	R-010 : Infection malware
A.8.15	Journalisation	Oui	Substantiel	R-012 : Absence de traçabilité
A.8.28	Codage sécurisé	Non	N/A	Pas de développement interne

Méthodologie de Rédaction du SOA ISO 27001 : Du Traitement des Risques aux Contrôles

La rédaction du Statement of Applicability (SOA) ISO 27001 est l'étape qui matérialise la décision de l'organisation sur les contrôles de sécurité à mettre en oeuvre en réponse à l'évaluation des risques. Cette décision ne peut être raisonnablement prise sans une analyse de risques préalable rigoureuse conforme à ISO 27005, qui identifie les actifs critiques, les vulnérabilités, les menaces et les risques associés avec leur niveau de criticité. Le SOA doit ensuite tracer explicitement le lien entre chaque risque identifié et les contrôles de l'Annexe A retenus pour le traiter, justifiant les exclusions de façon documentée et défendable lors de l'audit de certification.

La méthodologie de rédaction du SOA se déroule en quatre phases distinctes :

• Phase 1 - Inventaire des actifs et périmètre SMSI : délimiter précisément le périmètre du Système de Management de la Sécurité de l'Information (SMSI) en identifiant les processus métier couverts, les actifs informationnels concernés (données, logiciels, matériel, personnes, services) et les interfaces avec les systèmes hors périmètre
• Phase 2 - Analyse et traitement des risques : évaluer chaque risque selon une méthodologie formalisée (ISO 27005, EBIOS Risk Manager, ou méthode propriétaire documentée) pour calculer le niveau de risque résiduel après application des contrôles envisagés
• Phase 3 - Sélection des contrôles Annexe A : pour chaque risque significatif (dépassant le seuil d'acceptation défini par la direction), identifier les contrôles de l'Annexe A qui le traitent le plus efficacement, en documentant les raisons de la sélection et les exclusions motivées
• Phase 4 - Rédaction et validation du SOA : formaliser le SOA dans le format requis par la norme, obtenir l'approbation de la direction et la signature du responsable SMSI, puis le soumettre à l'auditeur de certification comme document central du SMSI

La norme ISO 27001:2022 a restructuré l'Annexe A par rapport à la version 2013, réduisant le nombre de contrôles de 114 à 93 tout en ajoutant 11 nouveaux contrôles couvrant les domaines Cloud, Threat Intelligence, Data Masking, et Information Deletion. Cette restructuration en 4 thèmes (Organisational, People, Physical, Technological) simplifie la navigation dans le référentiel mais nécessite une mise à jour du SOA existant pour les organisations déjà certifiées sous la version 2013.

Contrôles ISO 27001:2022 Prioritaires et Leurs Exigences de Mise en Oeuvre

Certains contrôles de l'Annexe A ISO 27001:2022 sont particulièrement déterminants pour les auditeurs de certification et doivent être traités avec une attention particulière dans le SOA, non seulement en termes de sélection mais aussi de niveau de maturité de mise en oeuvre documenté.

• A.5.23 - Information Security for Use of Cloud Services : contrôle nouveau dans ISO 27001:2022 exigeant une politique formelle pour l'utilisation des services cloud, incluant la classification des services autorisés, les critères de sécurité pour leur sélection et les responsabilités de sécurité partagées avec les fournisseurs cloud
• A.5.30 - ICT Readiness for Business Continuity : aligne les plans de continuité informatique avec le Plan de Continuité d'Activité (PCA), en exigeant des tests réguliers des capacités de reprise et la documentation des procédures de restauration testées
• A.6.8 - Information Security Event Reporting : exige un processus formel de signalement des incidents de sécurité, avec des canaux de reporting clairement définis, un délai maximum de signalement et une procédure de traitement documentée
• A.8.8 - Management of Technical Vulnerabilities : impose un processus formalisé de gestion des vulnérabilités incluant la surveillance des bulletins de sécurité, le délai maximum de patching selon la criticité CVE, et la vérification de l'application effective des correctifs
• A.8.25 - Secure Development Life Cycle : nouveau contrôle 2022 exigeant des pratiques de sécurité intégrées dans tout le cycle de développement logiciel, du design initial aux tests de sécurité pré-déploiement

La mise en oeuvre effective des contrôles sélectionnés dans le SOA doit être documentée avec des preuves tangibles : politiques écrites approuvées par la direction, procédures opérationnelles formalisées, formations réalisées (avec listes d'émargement), audits internes conduits et leurs résultats, et indicateurs de performance (KPIs) mesurés régulièrement. L'auditeur de certification ISO 27001 évaluera non seulement la sélection pertinente des contrôles dans le SOA mais surtout les preuves de leur application effective dans l'organisation, constituant la différence entre un SMSI certifiable et un exercice de conformité documentaire sans substance opérationnelle réelle.

La surveillance continue du SMSI après la certification initiale est assurée par les audits de surveillance annuels et le cycle de renouvellement triennal. Les non-conformités mineures et majeures détectées lors de ces audits doivent être traitées dans le processus d'amélioration continue formalisé dans le Plan d'Action d'Amélioration (PAA), avec des délais de correction définis et suivis par le responsable SMSI désigné par la direction de l'organisation.

Gestion des Non-Conformités et Amélioration Continue du SMSI ISO 27001

Le cycle d'amélioration continue PDCA (Plan-Do-Check-Act) est au coeur de la norme ISO 27001 et se manifeste opérationnellement dans le traitement des non-conformités identifiées lors des audits internes, des audits de certification et des incidents de sécurité. Une non-conformité au sens ISO 27001 est toute situation où un contrôle de l'Annexe A sélectionné dans le SOA n'est pas mis en oeuvre conformément à la politique ou procédure documentée de l'organisation, ou n'atteint pas l'objectif de sécurité défini.

Le processus formel de traitement des non-conformités exigé par la clause 10.1 de ISO 27001:2022 comprend plusieurs étapes documentées : identification et description précise de la non-conformité, analyse des causes racines pour comprendre pourquoi le contrôle a échoué (pas seulement le symptôme mais la cause profonde), définition des actions correctives avec responsable désigné et délai de mise en oeuvre, vérification de l'efficacité des actions correctives réalisées, et archivage de la documentation de traitement pour démonstration lors des audits futurs.

• Non-conformités mineures : n'impactent pas l'efficacité globale du SMSI, doivent être traitées dans les 90 jours suivant leur identification, donnent lieu à une observation de l'auditeur sans impact sur le statut de certification
• Non-conformités majeures : mettent en cause l'efficacité d'un contrôle essentiel ou d'un processus fondamental du SMSI, doivent être traitées avant la délivrance ou le maintien du certificat ISO 27001, nécessitent un plan d'action avec preuve de résolution soumis à l'organisme certificateur
• Indicateurs de performance SMSI : définir des métriques objectives et mesurables pour chaque objectif de sécurité (taux de disponibilité, nombre d'incidents, délai de patching, taux de réussite des tests de sauvegarde) pour démontrer l'efficacité du SMSI lors des revues de direction et des audits

La revue de direction formelle, exigée par la clause 9.3 de ISO 27001:2022, doit être conduite au minimum annuellement et couvrir l'état du SMSI, les résultats des audits internes et externes, les incidents de sécurité survenus, la performance des indicateurs définis, les changements internes et externes affectant le SMSI, et les ressources nécessaires pour l'amélioration continue. Cette revue doit aboutir à des décisions documentées sur les améliorations à apporter et les ressources à allouer, approuvées par la direction générale et tracées dans le Plan d'Action d'Amélioration du SMSI.

Préparation à l'Audit de Certification ISO 27001 : Checklist et Documents Requis

La préparation à l'audit de certification ISO 27001 s'effectue en deux phases distinctes : l'audit de Phase 1 (revue documentaire) où l'auditeur évalue la complétude et la cohérence de la documentation du SMSI, et l'audit de Phase 2 (audit de conformité) où l'auditeur vérifie sur site l'application effective des contrôles documentés. La Phase 1 peut être conduite à distance depuis la version 2020 des directives d'audit de l'IAF.

Les documents indispensables à préparer pour l'audit de Phase 1 :

• Périmètre du SMSI documenté avec cartographie des actifs couverts et interfaces avec les systèmes hors périmètre
• Politique de sécurité de l'information approuvée par la direction générale et communiquée à l'ensemble des parties prenantes
• Analyse de risques ISO 27005 avec méthodologie documentée, registre des risques, niveaux de risque calculés et décisions de traitement
• Statement of Applicability (SOA) avec justification de chaque contrôle sélectionné ou exclu et indication du statut de mise en oeuvre
• Objectifs de sécurité avec indicateurs de performance mesurables et suivis régulièrement
• Procédures opérationnelles documentées pour les contrôles sélectionnés dans le SOA
• Rapports d'audits internes conduits dans l'année précédant la certification, avec constatations et actions correctives
• Compte-rendu de revue de direction avec décisions actées et ressources allouées

La conduite d'un audit interne complet couvrant l'ensemble du périmètre SMSI dans les 6 mois précédant l'audit de certification est indispensable pour identifier et corriger les non-conformités avant que l'auditeur externe ne les découvre. Un audit interne efficace conduit par des auditeurs qualifiés (formation ISO 27001 Lead Auditor ou ISO 27001 Internal Auditor) simule fidèlement les conditions de l'audit de certification et permet à l'organisation de se préparer avec confiance à la présentation de son SMSI devant l'organisme certificateur accrédité.

La certification ISO 27001 est une démonstration concrète et vérifiable par des tiers de la maturité du système de management de la sécurité de l'information de l'organisation, valorisée par les clients grands comptes, les partenaires stratégiques et les investisseurs comme preuve d'une gouvernance responsable de la sécurité. Au-delà de l'aspect formel de la certification, la démarche ISO 27001 conduit les organisations à structurer leur approche de la sécurité de façon systématique et à développer une culture de l'amélioration continue qui génère des bénéfices durables bien au-delà du maintien du certificat triennal.

Ressources complémentaires

• ISO 27001:2022 — Guide complet de certification
• Analyse de risques ISO 27005 — Méthodologie
• Checklist Audit ISO 27001 — 93 Contrôles Annexe A
• Feuille de Route ISO 27001 en 12 Étapes
• ISO/IEC 27001:2022 — Norme officielle
• Modèle IA ISO 27001 Expert

FAQ — SOA ISO 27001