Qu’est-ce que le Statement of Applicability ?
Le Statement of Applicability (SoA) — en français déclaration d’applicabilité — est un document central d’ISO 27001. Il liste tous les contrôles de l’Annexe A et indique pour chaque contrôle :
- S’il est applicable ou non
- La justification de la décision
- Le statut d’implémentation
L’essentiel : Le SoA n’est pas une checklist à cocher. C’est un document stratégique qui montre que l’organisation a fait des choix conscients et basés sur les risques concernant sa démarche sécurité.
Pourquoi le SoA est-il important ?
Le SoA remplit plusieurs fonctions :
- Exigence de certification — Obligatoire selon la clause 6.1.3 d’ISO 27001
- Communication — Montre aux parties prenantes quels contrôles vous avez implémentés
- Référence — Point de départ pour l’audit interne et le suivi des contrôles
- Traçabilité — Relie l’évaluation des risques aux actions concrètes
- Transparence — Documente les choix conscients et les priorités
Sans SoA :
- Aucune certification ISO 27001 possible
- Difficile de démontrer une démarche sécurité systématique
- Risque de choix de contrôles arbitraires
Structure de l’Annexe A d’ISO 27001:2022
Les 93 contrôles sont organisés en quatre thèmes :
| Thème | Nombre de contrôles | Focus |
|---|---|---|
| A.5 Organisationnels | 37 | Politiques, rôles, fournisseurs |
| A.6 Relatifs au personnel | 8 | Embauche, formation, départ |
| A.7 Physiques | 14 | Locaux, équipements, environnement |
| A.8 Techniques | 34 | Systèmes, réseaux, chiffrement |
Processus SoA étape par étape
- Réaliser d'abord l'évaluation des risques Le SoA se base sur votre évaluation des risques. Identifiez les risques existants, les actifs à protéger et les menaces pertinentes. Sans évaluation des risques, le SoA devient arbitraire.
- Lister tous les contrôles de l'Annexe A Créez un tableau avec les 93 contrôles. Incluez le numéro de contrôle, le nom et la description. Ceci formera la base de votre SoA.
- Évaluer l'applicabilité Pour chaque contrôle : Est-il pertinent pour votre activité et votre profil de risque ? Répondez oui ou non. Gardez à l'esprit que "non applicable" nécessite une justification solide.
- Justifier chaque décision Que le contrôle soit applicable ou non — documentez pourquoi. Reliez à l'évaluation des risques. "Implémenté pour gérer le risque X" ou "Non applicable car nous n'avons pas Y".
- Documenter le statut d'implémentation Pour les contrôles applicables : Est-il implémenté ? Partiellement ? Planifié ? Indiquez le statut et l'éventuelle échéance.
- Lier à la documentation Reliez chaque contrôle à la politique, procédure ou implémentation technique pertinente. Cela facilite l'audit.
- Réviser et approuver Le SoA doit être approuvé par la direction. Cela montre l'appropriation et la responsabilité des choix de sécurité.
Exemple de structure SoA
| Contrôle | Description | Applicable | Justification | Statut | Documentation |
|---|---|---|---|---|---|
| A.5.1 | Policies for information security | Oui | Gouvernance fondamentale requise | Implémenté | POL-001 |
| A.5.9 | Inventory of information assets | Oui | Risque : Actifs non identifiés | Implémenté | PROC-012 |
| A.7.3 | Securing offices and facilities | Oui | Bureaux physiques existants | Implémenté | POL-015 |
| A.7.4 | Physical security monitoring | Non | Géré par le propriétaire, contrat existant | Non applicable | CONT-023 |
| A.8.20 | Networks security | Oui | Infrastructure critique | Partiel | PROJ-007 |
Justifications valides et invalides
• Le risque n'existe pas (ex. pas de serveur physique = pas de sécurité serveur physique)
• Géré par un autre contrôle
• Externalisé vers un fournisseur avec contrat
• L'activité n'a pas le processus pertinent (ex. pas de développement système)
• "Nous n'avons pas les moyens"
• "Nous n'avons pas le temps"
• "C'est trop compliqué"
• "Personne ne l'a demandé"
• Aucune justification
Contrôles couramment exclus
Contrôles souvent (légitimement) exclus :
| Contrôle | Justification courante |
|---|---|
| A.5.23 Information security for cloud services | Pas d’utilisation cloud |
| A.7.4 Physical security monitoring | Géré par le propriétaire |
| A.8.25 Secure development life cycle | Pas de développement propre |
| A.8.26 Application security requirements | Pas de développement propre |
| A.8.28 Secure coding | Pas de développement propre |
| A.8.31 Separation of development environments | Pas de développement propre |
Important : Même si vous ne développez pas en interne, vous pouvez utiliser des logiciels nécessitant une configuration sécurisée. Réfléchissez attentivement.
Perspective de l’auditeur
Ce que vérifie l’auditeur :
- Exhaustivité — Tous les 93 contrôles doivent être inclus
- Cohérence — Les justifications doivent être logiques et cohérentes
- Lien avec les risques — Les décisions doivent être reliées à l’évaluation des risques
- Implémentation — Les contrôles applicables doivent effectivement exister
- Documentation — Les références doivent mener aux bons documents
- Actualité — Le SoA doit être à jour
Écarts courants :
- Contrôles manquants
- Justifications insuffisantes
- Contrôles applicables non implémentés
- SoA obsolète ne reflétant pas la situation actuelle
SoA et exigences NIS2
Le SoA peut être étendu pour couvrir les exigences NIS2 qui vont au-delà d’ISO 27001 :
| Exigence NIS2 | Contrôles ISO 27001 pertinents | Notation SoA |
|---|---|---|
| Signalement d’incidents 24h | A.5.24-A.5.28 | Procédure étendue pour contraintes temporelles |
| Sécurité de la chaîne d’approvisionnement | A.5.19-A.5.22 | Due diligence renforcée |
| Continuité d’activité | A.5.29-A.5.30 | Fréquence de test selon NIS2 |
| Formation de la direction | A.6.3 | Contenu spécifique pour direction |
Maintenance du SoA
- Révision annuelle Passez en revue l'ensemble du SoA au minimum annuellement. Le statut des contrôles est-il exact ? L'activité a-t-elle changé ? Y a-t-il de nouveaux risques ?
- Mise à jour lors de changements Nouvelle activité, nouveaux systèmes, changements organisationnels — tous peuvent affecter le SoA. Mettez à jour de manière proactive.
- Relier à l'audit interne L'audit interne doit vérifier que le SoA reflète la réalité. Les écarts conduisent à une mise à jour.
- Contrôle de version Suivez les modifications. Qui a changé quoi et pourquoi ? Conservez l'historique.
Checklist pour le SoA
Avant l’audit de certification :
- Tous les 93 contrôles de l’Annexe A listés
- Applicabilité indiquée pour chaque contrôle
- Justification documentée pour chaque décision
- Les exclusions ont des raisons valides
- Statut d’implémentation mis à jour
- Références aux politiques/procédures présentes
- Lien avec l’évaluation des risques clair
- Approuvé par la direction
- Contrôle de version en place
- Date de dernière mise à jour indiquée
Comment Securapilot peut vous aider
Securapilot simplifie la gestion du SoA :
- Structure pré-construite — Tous les 93 contrôles prédéfinis
- Modèles de justification — Exemples et guidance
- Suivi du statut — Voir le progrès d’implémentation
- Liaison documentaire — Lier aux politiques et procédures
- Historique des versions — Traçabilité complète des changements
- Rapports d’audit — Exporter pour audit externe
Réservez une démo et voyez comment nous simplifions votre travail sur le SoA.
Questions fréquentes
Tous les 93 contrôles doivent-ils figurer dans le SoA ?
Oui, tous les 93 contrôles de l'Annexe A doivent être listés dans le SoA. Pour chaque contrôle, vous devez indiquer s'il est applicable ou non, et justifier la décision.
Puis-je exclure des contrôles ?
Oui, mais chaque exclusion doit être justifiée. Les raisons valides incluent l'absence du risque (ex. pas de travail mobile) ou la gestion par un autre contrôle. 'Nous n'avons pas les moyens' n'est pas une justification valide.
À quelle fréquence le SoA doit-il être mis à jour ?
Le SoA doit être un document vivant, mis à jour lors de changements dans l'activité, les risques ou l'implémentation des contrôles. Il devrait être révisé au minimum annuellement.
Que vérifie l'auditeur dans le SoA ?
L'auditeur contrôle : 1) Que tous les contrôles sont listés, 2) Que les justifications sont raisonnables, 3) Que les contrôles applicables sont effectivement implémentés, 4) Le lien avec l'évaluation des risques.
