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
CONFORMITÉ Template SoA ISO 27001:2022 — Déclaration Applicabilité ÉTAPES / CONTRÔLES 1 Pourquoi la SoA est-elle obligatoire ? 2 Structure du template 3 Ressources complémentaires EXIGENCES CLÉS Déclaration d'Applicabilité… 93 contrôles de l'Annexe A 2022 clause 6.1.3 d) Conseil d'expert : ayinedjimi-consultants.fr

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 27001

Ressources 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.

Découvrir notre méthodologie →

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

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.

Structure du template SoA ISO 27001:2022 — colonnes obligatoires et thèmes de l'Annexe A
Thème Annexe A 2022Nb de contrôlesExemple de contrôleJustification type (inclusion)Preuve attendue par l'auditeur
A.5 — Organisationnel37A.5.1 Politiques de sécurité de l'informationExigence de la norme + traitement du risque R-01PSSI validée et diffusée, preuve de revue annuelle
A.6 — Personnes8A.6.3 Sensibilisation et formationRisque d'erreur humaine / phishing identifiéPlan de formation, taux de complétion, campagnes de test
A.7 — Physique14A.7.2 Contrôle d'accès physiqueLocaux hébergeant des actifs classifiésRegistre des badges, journal des visiteurs
A.8 — Technologique34A.8.16 Surveillance des activitésDétection des incidents exigée par le SMSIConfiguration SIEM, règles d'alerte, revue des logs
Total Annexe A93Toutes catégories confonduesChaque ligne doit porter une justification expliciteSoA versionnée, datée et approuvée par la direction
Exclusion documentéeVariableA.8.30 Développement externaliséAucun développement confié à un tiers dans le périmètreNote de périmètre + validation RSSI (non-conformité si absente)
Statut d'implémentationO / N / PartielColonne 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.