Template SoA : Déclaration d'Applicabilité ISO 27001 (PDF)

La Déclaration d'Applicabilité (Statement of Applicability / SoA) est le document central de tout SMSI certifié ISO 27001. Ce template couvre les 93 contrôles de l'Annexe A 2022 avec pour chacun les colonnes : applicabilité (O/N), justification d'inclusion ou d'exclusion, statut d'implémentation (O/N/Partiel) et document ou preuve associé. Format paysage optimisé pour une lecture tabulaire claire.

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 :

• 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

Ressources complémentaires

• Checklist 93 Contrôles (version case à cocher)
• Modèle PSSI gratuit
• Feuille de route certification

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.