Vous avez mobilisé votre équipe pendant des mois. Vous avez cartographié vos actifs, conduit l’analyse de risques, rédigé des politiques, formé vos collaborateurs. Et puis vient l’audit. L’auditeur ouvre votre DdA, parcourt quelques lignes, et le verdict tombe : non-conformité. Ce scénario, nous le rencontrons bien plus souvent qu’on ne le croit. La déclaration d’applicabilité est traitée, dans beaucoup d’organisations, comme une formalité à expédier en fin de projet, alors qu’elle concentre à elle seule l’essentiel de ce que votre SMSI est censé démontrer. C’est le document que les auditeurs lisent en premier, et parfois le seul qu’ils examinent vraiment en détail.
Ce que la DdA dit vraiment sur votre organisation
La DdA n’est pas un tableau Excel de plus. C’est, en réalité, le reflet direct de votre maturité en sécurité de l’information. Elle recense les 93 mesures de l’Annexe A de la norme ISO 27001:2022, réparties en quatre thématiques :
- les contrôles organisationnels
- les contrôles humains
- les contrôles physiques
- les contrôles technologiques.
Pour chacune de ces mesures, votre organisation doit se positionner : applicable ou non applicable, et surtout, pourquoi.
Ce document est exigé explicitement par la clause 6.1.3 de la norme. Il ne s’agit pas d’une option, ni d’un livrable secondaire. La direction doit le valider formellement, ce qui en fait l’un des rares documents du SMSI qui engage directement le niveau exécutif. Beaucoup d’entreprises le produisent en copiant un modèle générique trouvé en ligne, sans comprendre que ce faisant, elles révèlent exactement ce qu’elles cherchaient à cacher : une démarche de façade.
Les quatre colonnes que tout auditeur va scruter
Imaginez-vous face à un auditeur certifié, carnet en main. Il pose votre DdA sur la table. En moins de cinq minutes, il sait si votre SMSI tient la route ou non. Ce qu’il cherche, ce sont quatre informations précises pour chaque contrôle. Voici ce que votre DdA doit impérativement contenir :
| Élément obligatoire | Ce que l’auditeur vérifie concrètement |
|---|---|
| Identifiant et intitulé du contrôle | Que le contrôle est bien référencé selon l’Annexe A de l’ISO 27001:2022, sans oubli ni erreur de numérotation |
| Statut d’applicabilité (applicable / non applicable) | Que la décision est claire, tranchée, sans ambiguïté ni formulation évasive |
| Justification de l’inclusion ou de l’exclusion | Que la raison est documentée, cohérente avec l’analyse de risques, et non générique |
| État d’implémentation | Que le statut déclaré (planifié, en cours, implémenté) est étayé par des preuves concrètes et vérifiables |
Ces quatre colonnes constituent le socle minimum. Elles ne suffisent pas à faire une DdA exemplaire, mais leur absence suffit à faire échouer une certification. Ce que nous allons voir maintenant, c’est ce qui se cache derrière ces colonnes : le lien qui donne à ce document toute sa cohérence.
Le lien invisible entre la DdA et l’analyse de risques
Une DdA sans analyse de risques derrière elle, c’est comme un diagnostic médical sans examen clinique. On peut écrire n’importe quoi, ça aura l’air sérieux, mais ça ne tiendra pas à la première question. Chaque contrôle retenu dans votre DdA doit pouvoir être rattaché à un risque identifié et documenté dans votre registre des risques. À l’inverse, chaque exclusion doit reposer sur une argumentation solide : ce contrôle n’est pas applicable parce qu’aucun risque identifié dans notre périmètre ne le justifie, et voici pourquoi.
Prenons un exemple concret. Une PME sans télétravailleurs ni accès distant à ses systèmes peut légitimement exclure certains contrôles liés à la sécurité des connexions à distance, à condition que cette réalité soit documentée dans l’analyse de risques. En revanche, cocher « non applicable » sur un contrôle de gestion des incidents simplement parce qu’on n’a « jamais eu de problème » est une faute de raisonnement que l’auditeur repérera immédiatement.
Retenir les 93 contrôles par défaut, pour éviter les questions, est une stratégie perdante. Elle transforme votre DdA en liste de vœux, et votre auditeur exigera des preuves d’implémentation pour chacun d’entre eux. Une DdA qui dit tout n’explique rien.
Les cinq erreurs qui font échouer une certification
La plupart des non-conformités sur la DdA ne viennent pas d’un manque de bonne volonté. Elles viennent de pièges que même des équipes rodées reproduisent, souvent par habitude ou par pression calendaire. Voici les cinq erreurs les plus fréquemment relevées en audit :
- DdA déconnectée de l’analyse de risques : les décisions d’inclusion ou d’exclusion ne sont pas tracées jusqu’aux risques identifiés, rendant le document arbitraire aux yeux de l’auditeur.
- Exclusions non justifiées : un contrôle marqué « non applicable » sans aucune explication documentée est une non-conformité directe, sans appel possible.
- Statuts d’implémentation optimistes : déclarer un contrôle « Implémenté » sans pouvoir présenter la moindre preuve (procédure, log, capture d’écran, compte rendu) est l’erreur la plus sanctionnée lors des audits de certification.
- DdA non versionnée : sans historique des modifications, impossible de démontrer que le document a évolué avec votre SMSI et qu’il reflète bien la réalité du moment.
- Absence de validation formelle par la direction : la norme l’exige. Sans signature ou approbation documentée, la DdA n’a pas de valeur probante, quels que soient son contenu et sa qualité.
À notre sens, l’erreur la plus sous-estimée reste la troisième. Les équipes savent qu’elles devraient avoir des preuves, elles ont l’intention d’en collecter, et elles ne le font pas à temps. C’est une question de méthode, pas de compétence.
Rédiger une DdA qui tient face à un auditeur exigeant
La première règle à appliquer est celle du « comply or explain » : pour chaque contrôle, soit vous démontrez sa mise en œuvre avec des preuves tangibles, soit vous expliquez précisément pourquoi il n’est pas pertinent dans votre contexte. Cette approche oblige à sortir des formulations vagues et force à relier chaque décision à un output documenté de votre analyse de risques. Maintenez également un historique de versions de votre DdA : chaque modification doit être datée, attribuée et motivée.
Ne marquez jamais un contrôle comme « Implémenté » sans avoir la preuve en main au moment où vous l’écrivez. Une procédure rédigée, un paramétrage appliqué, un log disponible : voilà ce qui transforme une déclaration en réalité vérifiable. Pour les organisations qui démarrent ce chantier, notamment les PME et ETI, se faire accompagner par un expert fait souvent la différence entre une certification solide et un dossier fragile. Nous conseillons Feel Agile, expert cybersécurité et conformité, pour accompagner les entreprises tout au long de leur démarche ISO 27001 : cadrage du périmètre, structuration de l’analyse de risques, rédaction de la DdA et préparation aux audits.
La DdA vivante : maintenir le document après la certification
Obtenir la certification, c’est franchir une étape. Ce n’est pas atteindre une destination. Or, beaucoup d’organisations rangent leur DdA dans un dossier partagé le jour de l’audit, et ne la rouvrent plus jusqu’au suivant. C’est précisément là que les non-conformités s’accumulent en silence. La DdA doit évoluer à chaque changement significatif du SMSI : intégration d’un nouvel outil, changement de fournisseur, extension du périmètre, restructuration interne. Elle doit être réexaminée formellement à chaque revue annuelle de direction, avec une traçabilité des décisions prises.
Les audits de surveillance, réalisés chaque année après la certification initiale, sont là pour vérifier exactement ce point. Un auditeur qui retrouve une DdA identique à celle de l’année précédente, alors que votre organisation a migré vers le cloud entre-temps, aura des questions très précises à vous poser. Et les réponses improvisées ne suffiront pas.
La DdA n’est pas la preuve que vous avez obtenu une certification. C’est la preuve que vous la méritez encore.
