La Déclaration d Applicabilité (Statement of Applicability ou SOA) est le document le plus scruté lors d un audit de certification ISO 27001. Elle établit la correspondance entre les risques identifiés, les contrôles retenus de l Annexe A et leur état d implémentation. Aucun autre document du SMSI ne concentre autant d informations critiques : c est à la fois la carte d identité de votre posture de sécurité et la feuille de route de vos améliorations. Ce guide expert détaille la méthodologie de rédaction d une SOA conforme, les erreurs à éviter et les bonnes pratiques issues de nos accompagnements terrain. Nous expliquons comment articuler la SOA avec l analyse de risques, le plan de traitement et les preuves d implémentation pour présenter un dossier solide à l auditeur.
En bref
- La SOA est le document n 1 vérifié par l auditeur ISO 27001
- Elle couvre les 93 contrôles de l Annexe A avec statut et justification
- Chaque exclusion doit être justifiée et validée par la direction
- La SOA est un document vivant révisé après chaque analyse de risques
Qu est-ce que la SOA et pourquoi est-elle centrale
Définition
La Déclaration d Applicabilité (SOA) est un document exigé par la clause 6.1.3d de l ISO 27001 qui liste l ensemble des contrôles de l Annexe A, indique pour chacun s il est applicable ou non, justifie les exclusions et décrit l état d implémentation des contrôles retenus. C est le pont entre l analyse de risques et la mise en oeuvre opérationnelle du SMSI.
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 |
Conseil d expert
Ajoutez une colonne "source de l exigence" pour indiquer si le contrôle est retenu en raison de l analyse de risques, d une exigence réglementaire (RGPD, NIS 2) ou d une exigence contractuelle (client, assureur). Cela facilite les revues et les mises à jour.
Méthodologie de rédaction en 6 étapes
- Partir de l analyse de risques : les contrôles retenus doivent répondre aux risques identifiés dans le registre des risques ISO 27005
- Parcourir les 93 contrôles : évaluer l applicabilité de chaque contrôle au regard du périmètre et du contexte
- Justifier chaque décision : documenter pourquoi un contrôle est retenu ou exclu
- Évaluer l état d implémentation : utiliser une échelle à 4 niveaux (non implémenté, partiel, substantiel, complet)
- Identifier les preuves : associer à chaque contrôle implémenté les documents et enregistrements probants
- 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é |
Erreur fatale
Ne jamais exclure un contrôle sans justification documentée. L auditeur vérifiera chaque exclusion et demandera les preuves que le risque associé est effectivement couvert par d autres moyens ou qu il est en dessous du seuil d acceptation validé par la direction.
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
- 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
- Pas de justification des exclusions : chaque "Non applicable" doit être argumenté avec le risque résiduel
- État d implémentation optimiste : ne marquez un contrôle comme "Implémenté" que si vous avez les preuves documentaires
- SOA non versionnée : le document doit porter un numéro de version et un historique des modifications
- 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 |
À retenir
La SOA est un document vivant qui doit être mise à jour après chaque analyse de risques, après chaque incident de sécurité majeur et au minimum une fois par an. L auditeur de surveillance vérifiera que les évolutions du SMSI sont bien reflétées dans la SOA. Prévoyez un processus de révision formalisé avec dates et responsables.
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
Besoin d aide pour rédiger votre SOA ?
Nos consultants rédigent votre SOA et l ensemble du socle documentaire ISO 27001
Demander un devis gratuitFAQ — SOA ISO 27001
La SOA doit-elle couvrir les 93 contrôles de l Annexe A ?
Oui, la SOA doit lister les 93 contrôles et indiquer pour chacun s il est applicable ou non. Contrairement à une idée reçue, vous ne pouvez pas simplement ignorer un contrôle : chaque exclusion doit être formellement justifiée et documentée.
Peut-on ajouter des contrôles qui ne sont pas dans l Annexe A ?
Oui, la norme le permet explicitement. Si votre analyse de risques identifie des besoins non couverts par l Annexe A, vous pouvez ajouter des contrôles complémentaires issus d autres référentiels (ISO 27017, ISO 27018, CIS Controls, NIST). Documentez-les dans une section séparée de la SOA.
Qui doit approuver la SOA ?
La SOA doit être approuvée par la direction générale ou le propriétaire du risque désigné. Cette approbation formelle est vérifiée par l auditeur. En pratique, le RSSI la rédige, le comité de pilotage SMSI la valide, et le DG la signe.
Article recommandé
Pour une vue d ensemble du parcours de certification, consultez notre Feuille de Route ISO 27001 : Certification en 12 Étapes qui détaille chaque phase du projet.
Télécharger cet article en PDF
Format A4 optimisé pour l'impression et la lecture hors ligne
À propos de l'auteur
Ayi NEDJIMI
Expert Cybersécurité Offensive & Intelligence Artificielle
Ayi NEDJIMI est consultant senior en cybersécurité offensive et intelligence artificielle, avec plus de 20 ans d'expérience sur des missions à haute criticité. Il dirige Ayi NEDJIMI Consultants, cabinet spécialisé dans le pentest d'infrastructures complexes, l'audit de sécurité et le développement de solutions IA sur mesure.
Ses interventions couvrent l'audit Active Directory et la compromission de domaines, le pentest cloud (AWS, Azure, GCP), la rétro-ingénierie de malwares, le forensics numérique et l'intégration d'IA générative (RAG, agents LLM, fine-tuning). Il accompagne des organisations de toutes tailles — des PME aux grands groupes du CAC 40 — dans leur stratégie de sécurisation.
Contributeur actif à la communauté cybersécurité, il publie régulièrement des analyses techniques, des guides méthodologiques et des outils open source. Ses travaux font référence dans les domaines du pentest AD, de la conformité (NIS2, DORA, RGPD) et de la sécurité des systèmes industriels (OT/ICS).
Ressources & Outils de l'auteur
Articles connexes
Commentaires
Aucun commentaire pour le moment. Soyez le premier à commenter !
Laisser un commentaire