Téléchargez le template de Déclaration d'Applicabilité (SoA) ISO 27001:2022. 93 contrôles avec colonnes applicabilité, justification et preuves.
TL;DR — En résumé
La Déclaration d'Applicabilité (SoA) constitue l'exigence documentaire centrale de la clause 6.1.3 d) de l'ISO 27001:2022, couvrant les 93 contrôles de l'Annexe A répartis en quatre thèmes (organisationnels, personnes, physiques, technologiques). Ce template gratuit propose un format tabulaire paysage avec colonnes applicabilité, justification et preuves associées, document systématiquement vérifié en priorité lors des audits de certification. Un retour d'expérience terrain souligne l'importance d'un pre-audit interne six semaines avant l'audit officiel, illustré par un écart réel sur le contrôle A.12.4 concernant la centralisation des logs administrateur. La ressource s'accompagne de conseils pour documenter rigoureusement toute exclusion de contrôle, point systématiquement challengé par les auditeurs.
La Déclaration d'Applicabilité (Statement of Applicability, ou SoA) est le document central de tout SMSI certifié ISO 27001 : c'est lui que l'auditeur ouvre en premier pour vérifier la cohérence entre votre analyse de risques et les mesures réellement déployées. Souvent recherché sous le terme « template soa declaration applicabilite », ce modèle couvre les 93 contrôles de l'Annexe A 2022 (organisationnels, humains, physiques et technologiques) avec, pour chacun, les colonnes essentielles : applicabilité (O/N), justification d'inclusion ou d'exclusion, statut d'implémentation (O/N/Partiel) et document ou preuve associé. Le format paysage est optimisé pour une lecture confortable à l'écran comme à l'impression, et la structure se remplit directement à partir de votre traitement du risque. Vous disposez ainsi d'une base prête à l'emploi pour préparer votre audit de certification ou de surveillance.
En bref
- Pourquoi la SoA est-elle obligatoire ?
- Structure du template
- Ressources complémentaires
Pourquoi la SoA est-elle obligatoire ?
- Exigence clause 6.1.3 d) de la norme ISO 27001
- Document vérifié en priorité par les auditeurs de certification
- Lien entre l'analyse de risques et les contrôles implémentés
- Preuve de la couverture sécuritaire de l'organisation
Structure du template
Le document est organisé en 4 sections correspondant aux thèmes de l'Annexe A :
Retour terrain
Lors d'un accompagnement ISO 27001 pour un hébergeur de données de santé, l'audit de certification a identifié un écart sur le contrôle A.12.4 (journalisation) : les logs d'accès administrateur n'étaient pas centralisés et certains étaient stockés localement sur les serveurs eux-mêmes — effaçables par un admin compromis. La correction a pris 3 semaines ; l'audit de certification avait été planifié 2 semaines après. Leçon : toujours faire un pre-audit interne complet 6 semaines avant la date officielle.
- A.5 — 37 contrôles organisationnels
- A.6 — 8 contrôles liés aux personnes
- A.7 — 14 contrôles physiques
- A.8 — 34 contrôles technologiques
Conseil d'expert : Ne déclarez jamais un contrôle « Non Applicable » sans justification solide. Les auditeurs challengeront systématiquement les exclusions. Documentez pourquoi le risque associé n'existe pas dans votre contexte.
Besoin d'aide pour votre SoA ?
Nous vous accompagnons dans la rédaction d'une SoA auditable et justifiée.
Découvrir la prestation ISO 27001Ressources complémentaires
Besoin d'un accompagnement pour votre certification ISO 27001 ?
Gap analysis, documentation, mise en œuvre, préparation audit Stage 1 et Stage 2. Diagnostic initial offert.
Comment renseigner votre Déclaration d'Applicabilité ISO 27001
La Déclaration d'Applicabilité (SoA) est le document qui démontre à l'organisme de certification que vous avez analysé chacun des 93 contrôles de l'Annexe A, décidé de leur applicabilité et justifié vos choix. Ce n'est pas un formulaire à remplir mécaniquement — c'est le reflet de votre analyse de risques et de votre stratégie de traitement.
Le processus de renseignement doit suivre une logique stricte : commencer par l'analyse de risques, identifier les risques résiduels, sélectionner les contrôles nécessaires au traitement de ces risques, puis vérifier si des contrôles supplémentaires sont requis par des exigences légales ou contractuelles. Ce n'est qu'après cette analyse que vous pouvez valablement renseigner chaque ligne de la SoA.
Les 4 colonnes essentielles de la SoA
Ce template SoA structure les 93 contrôles autour de 4 colonnes fondamentales. Comprendre la logique de chaque colonne est indispensable pour produire un document recevable en audit de certification :
- Applicabilité (O/N) : un contrôle est applicable s'il peut contribuer à traiter un risque identifié ou si une exigence légale, réglementaire ou contractuelle l'impose. Un contrôle non applicable doit être justifié — "non pertinent pour notre activité" n'est pas une justification suffisante.
- Justification d'inclusion ou d'exclusion : pour les contrôles inclus, référencez le ou les risques traités et/ou les exigences légales concernées. Pour les exclusions, documentez précisément pourquoi le contrôle n'est pas pertinent pour votre contexte.
- Statut d'implémentation (O/N/Partiel) : reflète l'état réel de mise en œuvre au moment de l'audit. "Partiel" doit être accompagné d'un plan d'action avec date de clôture.
- Document ou preuve associé : référencez le document qui atteste de la mise en œuvre (procédure, politique, rapport, log, contrat). Sans preuve documentaire, le contrôle sera considéré comme non implémenté.
Les 11 nouveaux contrôles ISO 27001:2022 à ne pas négliger
La version 2022 de l'Annexe A introduit 11 nouveaux contrôles qui n'existaient pas dans la version 2013. Ces contrôles sont systématiquement examinés en audit de certification car ils représentent les nouvelles exigences. Votre SoA doit explicitement statuer sur chacun d'eux :
- 5.7 — Threat intelligence : collecte et analyse d'informations sur les menaces pertinentes pour votre organisation.
- 5.23 — Sécurité des services cloud : gestion de la sécurité des services cloud utilisés (particulièrement pertinent si vous avez des prestataires SaaS critiques).
- 5.30 — Préparation ICT pour la continuité d'activité : planification de la continuité des systèmes d'information en cas d'incident majeur.
- 7.4 — Surveillance de la sécurité physique : dispositifs de surveillance des locaux sensibles.
- 8.9 — Gestion de la configuration : politiques de gestion des configurations des systèmes.
- 8.10 — Effacement de l'information : procédures de suppression sécurisée des données.
- 8.11 — Masquage des données : techniques de pseudonymisation et d'anonymisation.
- 8.12 — Prévention des fuites de données (DLP) : contrôles techniques contre l'exfiltration de données.
- 8.16 — Activités de surveillance : détection des comportements anormaux sur les réseaux et systèmes.
- 8.23 — Filtrage web : contrôle des accès aux ressources web externes.
- 8.28 — Codage sécurisé : principes de développement sécurisé applicables aux logiciels développés en interne.
Erreurs fréquentes dans la rédaction d'une SoA
La SoA est l'un des documents les plus fréquemment mis en cause lors des audits de certification. Voici les erreurs qui conduisent le plus souvent à des non-conformités majeures :
- Exclure des contrôles sans justification formelle : exclure un contrôle sans documenter la raison est une non-conformité majeure. L'auditeur interprétera une exclusion non justifiée comme une omission délibérée.
- Déconnecter la SoA de l'analyse de risques : si les contrôles inclus dans la SoA ne correspondent pas aux risques identifiés dans le registre des risques, le SMSI est incohérent. La traçabilité risques → contrôles doit être vérifiable.
- Indiquer "Oui" à tous les contrôles : une organisation qui prétend avoir implémenté intégralement les 93 contrôles sans être en mesure de le prouver génère immédiatement de la méfiance. Soyez honnête sur le statut "Partiel" — c'est plus crédible et plus utile.
- Ne pas mettre à jour la SoA après les changements : la SoA est un document vivant. Tout changement significatif du contexte (nouveau service cloud, nouvelle activité, nouveau prestataire critique) doit déclencher une revue des contrôles concernés.
- Ignorer les exigences contractuelles et légales : certains contrôles peuvent être rendus obligatoires par des contrats clients, des réglementations sectorielles (RGPD, NIS 2, PCI-DSS) ou des engagements certifiés. Ces sources d'exigences doivent figurer dans la colonne de justification.
Intégration de la SoA dans le système documentaire ISO 27001
La SoA n'existe pas en silo. Elle est le pivot du système documentaire ISO 27001 et doit être cohérente avec plusieurs autres documents clés :
- L'analyse de risques : les contrôles sélectionnés dans la SoA doivent couvrir les risques identifiés comme devant être traités (après application du critère d'acceptation des risques).
- Le plan de traitement des risques (PTR) : le PTR liste les actions à mener pour implémenter les contrôles. Son avancement doit être reflété dans la colonne "statut d'implémentation" de la SoA.
- La politique de sécurité (PSSI) : les contrôles organisationnels de la SoA doivent trouver leur traduction dans les politiques et procédures documentées.
- Les résultats d'audit interne : les non-conformités identifiées en audit interne sur des contrôles "conformes" dans la SoA révèlent un problème de sincérité du document.
Foire aux questions — Déclaration d'Applicabilité ISO 27001
La SoA doit-elle être approuvée par la direction ?
Oui. La SoA est une décision stratégique sur les contrôles de sécurité que l'organisation choisit d'implémenter. Elle doit être approuvée par le management et cette approbation doit être documentée (signature, date, version). C'est une exigence implicite de la clause 6.1.3 qui précise que les contrôles sélectionnés doivent être comparés à ceux de l'Annexe A.
Peut-on exclure des contrôles de l'Annexe A 2022 ?
Oui, un contrôle peut être exclu s'il n'est pas applicable au contexte de l'organisation et qu'aucune exigence légale, réglementaire ou contractuelle ne l'impose. L'exclusion doit être justifiée dans la SoA. En pratique, le contrôle 7.4 (surveillance physique) est parfois exclu pour les organisations 100 % en télétravail, ou le 8.28 (codage sécurisé) pour les organisations qui n'ont pas d'activité de développement logiciel.
Quelle est la différence entre la SoA et le plan de traitement des risques ?
La SoA recense tous les contrôles de l'Annexe A et leur statut. Le plan de traitement des risques (PTR) est focalisé sur les actions à mener pour réduire les risques identifiés. Un contrôle peut figurer dans la SoA (applicable, non encore implémenté) et dans le PTR (action planifiée). Ces deux documents se complètent et doivent être cohérents.
Mise en œuvre pratique : étapes et livrables
La conformité réglementaire génère une documentation substantielle qui doit être maintenue à jour et accessible lors des audits. Une organisation structurée de ces livrables simplifie considérablement les exercices de conformité et réduit le temps consacré à leur préparation.
Livrables documentaires essentiels
Quel que soit le référentiel de conformité concerné, les livrables fondamentaux incluent : un registre des traitements (obligatoire RGPD, utile pour tout SMSI) maintenu par le DPO ou le RSSI ; une politique de sécurité de l'information (PSI ou PSSI) approuvée par la direction et diffusée à tous les collaborateurs ; des procédures opérationnelles documentées pour les processus critiques (gestion des incidents, accès privilégiés, sauvegardes) ; un plan de continuité d'activité (PCA) testé annuellement ; et des rapports d'audit internes et de revue de direction formalisés. Ces documents constituent le «squelette» du SMSI et sont systématiquement vérifiés lors des audits de certification.
Gouvernance et responsabilités
La conformité réglementaire est un effort collectif qui ne peut pas reposer uniquement sur le RSSI ou le DPO. Une gouvernance efficace définit clairement les rôles : le COMEX assume la responsabilité globale de la conformité (risque financier et réputationnel) ; les DSI et RSSI mettent en œuvre les mesures techniques ; les métiers identifient les données et processus critiques à protéger ; et les DPO/compliance officers assurent la cohérence réglementaire. Les comités de sécurité trimestriels, impliquant toutes ces parties prenantes, garantissent l'alignement entre les exigences réglementaires et les capacités opérationnelles de l'organisation. Le suivi des actions de remédiation dans un outil de GRC (Governance, Risk & Compliance) formalise ce processus et facilite la production des preuves d'audit.
Sanction et contrôle : ce que les autorités vérifient
Comprendre les priorités de contrôle des autorités de régulation permet aux organisations de concentrer leurs efforts sur les domaines qui font l'objet d'une surveillance accrue. Les autorités de supervision (CNIL, ANSSI, ACP pour le secteur bancaire, HAS pour le secteur santé) publient régulièrement leurs priorités de contrôle.
Priorités de contrôle 2025-2026
Les domaines prioritaires identifiés par les autorités françaises pour 2025-2026 : la sécurité des données de santé (contrôles HDS en forte augmentation suite aux incidents hospitaliers) ; l'IA et le traitement des données personnelles (CNIL a annoncé 300 mises en demeure liées à l'IA en 2025) ; les sous-traitants et tiers (vérification des DPA et des audits de sécurité des fournisseurs) ; et la notification des violations de données dans les délais légaux (72h RGPD, 24h NIS 2 pour les entités essentielles). Les organisations qui documentent proactivement leur conformité dans ces domaines réduisent significativement leur exposition aux sanctions et bénéficient généralement d'une procédure d'audit moins contraignante.
Programme de préparation aux audits
Un programme structuré de préparation aux audits réduit le stress et améliore les résultats. Douze mois avant un audit de certification : gap analysis interne pour identifier les non-conformités. Six mois avant : corrections des écarts majeurs et préparation de la documentation. Trois mois avant : audit blanc interne conduit par un consultant externe indépendant. Un mois avant : formation des équipes sur les procédures et livrables à présenter. Cette approche systématique, validée par des centaines d'organisations certifiées ISO 27001, transforme l'audit de certification d'une épreuve redoutée en une validation formelle d'un travail déjà accompli.
Bonnes pratiques et recommandations complémentaires
Au-delà des techniques et outils présentés dans cet article, plusieurs principes transverses guident les professionnels de la cybersécurité dans leur approche quotidienne. La défense en profondeur (defense-in-depth) reste le principe fondateur : aucune mesure de sécurité unique n'est suffisante, et la multiplication des couches de protection — même imparfaites individuellement — crée une résilience globale supérieure à la somme de ses parties.
Veille et mise à jour continue
La cybersécurité est un domaine où l'obsolescence est rapide. Une technique ou un outil efficace en 2024 peut être contourné en 2026. Les équipes sécurité maintiennent leur efficacité en s'appuyant sur des sources de veille fiables : bulletins CERT-FR et ANSSI, advisories des éditeurs (Microsoft MSRC, Google Project Zero, Cisco Talos), recherches académiques (USENIX Security, IEEE S&P, CCS), et publications de la communauté (threat intel reports des grands éditeurs, articles de blog de chercheurs reconnus).
Documentation et partage de connaissances
La capitalisation des connaissances est un enjeu organisationnel critique dans les équipes de sécurité. Les runbooks d'investigation, les post-mortems d'incidents, les procédures de réponse documentées, et les bases de connaissance internes permettent de maintenir la cohérence des pratiques indépendamment des rotations d'équipe et de réduire le temps de résolution des incidents récurrents. L'utilisation d'un wiki sécurisé (Confluence, Notion avec contrôles d'accès stricts) pour centraliser ces connaissances est une pratique adoptée par la majorité des équipes SOC matures. La documentation proactive, rédigée juste après les incidents pendant que les détails sont frais, est systématiquement plus précise et utile que la documentation rédigée après coup.
Points d'attention avancés pour les auditeurs et RSSI
Au-delà de la conformité de surface, les auditeurs expérimentés et les RSSI cherchent à évaluer la robustesse réelle du dispositif de sécurité. Ce niveau d'analyse requiert de dépasser la vérification documentaire pour s'intéresser à l'efficacité opérationnelle des contrôles.
Pièges courants dans les audits de conformité
Plusieurs patterns d'échec reviennent régulièrement lors des audits de renouvellement. La conformité sur papier sans effectivité opérationnelle : des politiques formalisées mais non appliquées, des procédures documentées mais inconnues des équipes, des contrôles déclarés actifs mais non supervisés. La dérive post-certification : les organisations qui traitent la certification comme une fin en soi plutôt que comme un jalons d'un processus continu connaissent systématiquement une dégradation de leur posture sécurité entre deux audits. La gestion insuffisante des tiers : plus de 60% des violations impliquent un fournisseur ou un prestataire, mais les contrats de sous-traitance et les audits tiers sont souvent les parents pauvres des programmes de conformité. Adresser ces trois points avant l'audit réduit significativement le risque de non-conformité majeure.
Métriques de maturité à présenter en audit
Les auditeurs modernes s'intéressent aux indicateurs de fonctionnement réel du SMSI plutôt qu'à la simple existence des documents. Préparer : statistiques de gestion des incidents sur 12 mois (nombre, délai de traitement, taux de récidive) démontrant une amélioration continue ; résultats des exercices de continuité avec les actions correctives entreprises ; données de sensibilisation (taux de participation aux formations, taux d'échec aux simulations de phishing) ; et résultats des audits internes avec suivi des actions de remédiation. Ces métriques transforment l'audit en démonstration de la maturité de l'organisation plutôt qu'en exercice de conformité documentaire, et constituent la meilleure défense contre les questions inattendues des auditeurs sur l'efficacité opérationnelle des contrôles.
Checklist de mise en œuvre et points de contrôle
La mise en pratique des recommandations de cet article nécessite une approche structurée. Cette checklist synthétise les points de contrôle essentiels pour évaluer l'état d'avancement de votre déploiement et identifier les actions prioritaires.
Phase de préparation et d'inventaire
Avant toute action technique, constituer un inventaire précis est indispensable. Les éléments à recenser : cartographie exhaustive des actifs concernés (systèmes, applications, flux de données) avec leur criticité métier associée ; identification des propriétaires techniques et fonctionnels pour chaque actif ; évaluation du niveau de maturité actuel à partir des référentiels reconnus (CIS Controls, ISO 27001, NIST CSF) ; et documentation des dépendances entre composants pour anticiper les impacts des modifications. Un inventaire incomplet génère des angles morts qui deviennent des vecteurs d'attaque exploitables par des acteurs malveillants disposant d'informations accessibles publiquement (OSINT, Shodan, LinkedIn).
Phase de déploiement et validation
Le déploiement progressif réduit les risques d'interruption de service et facilite la détection des régressions. Adopter un modèle de déploiement par vagues (wave deployment) : d'abord les environnements de développement et de test pour valider les configurations, ensuite les systèmes non-critiques en production, enfin les systèmes critiques lors de fenêtres de maintenance planifiées. Chaque vague s'accompagne d'une validation fonctionnelle complète et d'une période d'observation des métriques de performance et de sécurité. Un plan de retour arrière documenté et testé est obligatoire avant toute opération sur un système critique. Les critères de succès doivent être définis avant le déploiement, non après — un taux de faux positifs inférieur à 5% pour les alertes de sécurité, une disponibilité maintenue au niveau SLA contractuel, et l'absence d'incidents de sécurité liés aux modifications.
Phase de supervision et d'amélioration continue
La mise en place d'indicateurs de suivi permet de mesurer l'efficacité des mesures déployées et de justifier leur maintien auprès de la direction. Tableau de bord mensuel recommandé : nombre d'alertes générées par catégorie (critique, majeur, mineur) avec tendance sur 6 mois ; taux de couverture des actifs critiques par les contrôles de sécurité ; délai moyen de remédiation des vulnérabilités par sévérité CVSS ; et résultats des tests de régression mensuels sur les règles de détection. Ce tableau de bord, présenté en comité de sécurité, constitue la base d'un dialogue constructif entre les équipes techniques et le management sur les priorités d'investissement en cybersécurité.
Sources et références
- ANSSI — Référentiel de sécurité
- NIST SP 800-53 — Contrôles de sécurité
- ISO/IEC 27001:2022 — Norme de sécurité de l'information
Pour aller plus loin : Mise en œuvre pratique
La conformité réglementaire nécessite une approche structurée et documentée. Ces ressources complémentaires permettent d'approfondir les points techniques et juridiques abordés dans cet article.
Outils d'auto-évaluation
- ANSSI — Outil d'évaluation cybersécurité — Le Diagnostic de Cybersécurité de l'ANSSI permet d'évaluer le niveau de maturité de votre organisation sur 5 domaines clés. Gratuit et disponible sur diagnostic.ssi.gouv.fr.
- ENISA — Outil d'auto-évaluation NIS2 — Questionnaire structuré pour identifier les exigences applicables à votre secteur et votre taille d'organisation.
- Logiciels GRC — Des solutions comme Vanta, Drata ou TrustCloud automatisent la collecte de preuves de conformité et accélèrent les processus d'audit.
Documentation à produire en priorité
- Politique de Sécurité du Système d'Information (PSSI) — document fondateur
- Registre des activités de traitement (RGPD, article 30)
- Analyse d'impact relative à la protection des données (AIPD/DPIA)
- Plan de continuité d'activité (PCA) et plan de reprise d'activité (PRA)
- Procédure de gestion des incidents de sécurité (notification ANSSI/CNIL)
Accompagnement et conseil
La mise en conformité implique souvent une assistance externe pour les organisations ne disposant pas d'expertise interne. Les RSSI externalisés ou les consultants spécialisés en conformité peuvent accélérer significativement le processus, notamment pour la préparation aux audits de certification ISO 27001 ou pour la mise en conformité NIS 2 avec un délai contraint.
| Thème Annexe A 2022 | Nb de contrôles | Exemple de contrôle | Justification type (inclusion) | Preuve attendue par l'auditeur |
|---|---|---|---|---|
| A.5 — Organisationnel | 37 | A.5.1 Politiques de sécurité de l'information | Exigence de la norme + traitement du risque R-01 | PSSI validée et diffusée, preuve de revue annuelle |
| A.6 — Personnes | 8 | A.6.3 Sensibilisation et formation | Risque d'erreur humaine / phishing identifié | Plan de formation, taux de complétion, campagnes de test |
| A.7 — Physique | 14 | A.7.2 Contrôle d'accès physique | Locaux hébergeant des actifs classifiés | Registre des badges, journal des visiteurs |
| A.8 — Technologique | 34 | A.8.16 Surveillance des activités | Détection des incidents exigée par le SMSI | Configuration SIEM, règles d'alerte, revue des logs |
| Total Annexe A | 93 | Toutes catégories confondues | Chaque ligne doit porter une justification explicite | SoA versionnée, datée et approuvée par la direction |
| Exclusion documentée | Variable | A.8.30 Développement externalisé | Aucun développement confié à un tiers dans le périmètre | Note de périmètre + validation RSSI (non-conformité si absente) |
| Statut d'implémentation | O / N / Partiel | Colonne transverse du template | « Partiel » doit renvoyer à un plan d'action daté | Plan de traitement du risque avec échéances et responsables |
Conclusion
La conformité réglementaire n'est pas une destination mais un état à maintenir. Chaque évolution du SI, chaque nouveau fournisseur peut modifier le périmètre. Documentation, audits réguliers et formation des équipes en sont les piliers.
Votre organisation est-elle soumise à NIS 2, ISO 27001 ou DORA ?
Évaluer votre conformité NIS 2 ou contactez-nous directement.
Télécharger cet article en PDF
Format A4 optimisé pour l'impression et la lecture hors ligne
À propos de l'auteur
Ayi NEDJIMI
Auditeur Senior Cybersécurité & Consultant IA
Expert Judiciaire — Cour d'Appel de Paris
Habilitation Confidentiel Défense
ayi@ayinedjimi-consultants.fr
Ayi NEDJIMI est un vétéran de la cybersécurité avec plus de 25 ans d'expérience sur des missions critiques. Ancien développeur Microsoft à Redmond sur le module GINA (Windows NT4) et co-auteur de la version française du guide de sécurité Windows NT4 pour la NSA.
À la tête d'Ayi NEDJIMI Consultants, il réalise des audits Lead Auditor ISO 42001 et ISO 27001, des pentests d'infrastructures critiques, du forensics et des missions de conformité NIS2 / AI Act.
Conférencier international (Europe & US), il a formé plus de 10 000 professionnels.
Domaines d'expertise
Ressources & Outils de l'auteur
Testez vos connaissances
Mini-quiz de certification lié à cet article — propulsé par CertifExpress
Articles connexes
Mise en conformité NIS 2 et ISO 27001
Accompagnement sur mesure pour les PME et ETI soumises à NIS 2 ou engagées dans une démarche ISO 27001. Gap analysis, plan d'action, audit interne.
Commentaires
Aucun commentaire pour le moment. Soyez le premier à commenter !
Laisser un commentaire