La déclaration d’applicabilité : le document ISO 27001 qu’on bâcle toujours

Dans un projet ISO 27001, la déclaration d’applicabilité est le document qui met le plus de temps à être compris et le moins de temps à être rédigé. C’est généralement l’inverse qu’il faudrait faire.

Ce que dit la norme

La déclaration d’applicabilité — SoA, pour Statement of Applicability — est exigée par la clause 6.1.3 d) d’ISO/IEC 27001:2022. Le texte demande de produire un document qui contient :

• les mesures de sécurité nécessaires et leur justification,
• la confirmation que ces mesures ont été mises en œuvre,
• et la justification de l’exclusion de toute mesure de l’annexe A.

C’est l’une des rares informations documentées nommément citées par la norme. Une politique de sécurité peut prendre des formes variées ; la SoA, non. Un auditeur la demandera.

Depuis la révision de 2022, l’annexe A compte 93 mesures réparties en quatre thèmes : organisationnelles (37), liées aux personnes (8), physiques (14) et technologiques (34). L’ancienne structure en 114 mesures et 14 domaines a disparu. La logique de la SoA, elle, n’a pas changé.

Les trois colonnes qui posent problème

« Applicable : oui / non »

Se remplit vite, et c’est le piège. La question n’est pas « est-ce qu’on le fait », mais « est-ce que c’est pertinent au regard du périmètre et des risques identifiés ».

Une mesure pertinente mais non déployée reste applicable. Elle est simplement en écart, et cet écart doit apparaître dans le plan de traitement. L’exclure parce qu’on ne la fait pas est la faute la plus fréquente, et l’une des plus faciles à détecter en audit.

« Justification »

C’est la colonne qui distingue une SoA sérieuse d’un tableau rempli la veille de l’audit. « Non applicable car non concerné » ne justifie rien.

Une bonne justification tient en une phrase, mais elle renvoie à quelque chose de vérifiable : une décision de périmètre, un risque accepté et tracé, l’absence d’actif concerné. Exemple acceptable pour la mesure 7.4 (surveillance de la sécurité physique) : « Locaux en immeuble multi-occupants ; surveillance physique assurée contractuellement par le bailleur — contrat référencé PS-2024-03. »

« État de mise en œuvre »

Doit refléter la réalité, y compris quand elle est mauvaise. Une SoA affichant 93 mesures en place sur un SMSI de huit mois n’est pas crédible, et l’auditeur ira chercher la preuve précisément là où vous avez surestimé.

Prévoyez au moins trois états : en place, partiellement en place, planifié — avec échéance. Un « partiellement » assumé passe mieux qu’un « oui » démenti par les preuves.

Ce qu’un auditeur y cherche

La cohérence, avant l’exhaustivité. Il croise systématiquement trois documents : votre appréciation des risques (clause 6.1.2), votre SoA (6.1.3 d) et votre plan de traitement (6.1.3 e).

Les ruptures qu’il cherche :

• Un risque significatif identifié, mais aucune mesure correspondante marquée applicable.
• Une mesure déclarée en place, sans preuve associée.
• Une exclusion justifiée par une raison contredite ailleurs — vous excluez le développement sécurisé alors que votre périmètre inclut une application maison.

Ce sont ces incohérences qui produisent des non-conformités, pas le nombre de mesures exclues. Un périmètre restreint et assumé, avec vingt exclusions correctement justifiées, passe mieux qu’un périmètre large et une SoA optimiste.

L’erreur de calendrier

Beaucoup d’organisations rédigent la SoA à la fin, quand tout est en place. C’est trop tard : le document ne sert alors qu’à documenter l’existant, et il arrive systématiquement en retard.

Construite tôt, même très incomplète, elle devient l’outil de pilotage du projet. Elle montre ce qui reste à faire, permet d’arbitrer les priorités avec la direction, et évite de découvrir trois semaines avant l’audit initial qu’une famille entière de mesures n’a jamais été traitée.

Sur nos missions de certification, c’est le premier document que nous mettons en place — avant même que la moitié des mesures existe.

Ce qui change entre la version 2013 et la version 2022

Si vous migrez un SMSI existant, la SoA doit être reconstruite, pas convertie. Les 93 mesures de 2022 ne sont pas une simple renumérotation des 114 précédentes : onze mesures sont nouvelles, et plusieurs anciennes ont été fusionnées.

Les nouveautés qui posent le plus de questions en audit de transition : veille sur les menaces (5.7), sécurité de l’information dans l’usage de services en nuage (5.23), continuité des activités liée aux TIC (5.30), surveillance de la sécurité physique (7.4), gestion de la configuration (8.9), prévention des fuites de données (8.12), activités de surveillance (8.16), filtrage web (8.23), codage sécurisé (8.28).

Si votre SoA de transition affiche ces onze mesures « en place » sans qu’aucun document nouveau n’ait été produit, l’écart se verra.

Un format qui marche

Un tableau, sept colonnes, une ligne par mesure : identifiant, intitulé, applicable (O/N), justification, état, preuve (référence documentaire), responsable.

La colonne preuve est celle qu’on oublie, et c’est celle qui fait gagner deux jours pendant l’audit. Une référence documentaire par mesure, et l’auditeur navigue seul.

Évitez les SoA de trente pages en texte rédigé. Personne ne les lit, vous compris.

Sources

• ISO/IEC 27001:2022, clauses 6.1.2 et 6.1.3 — appréciation et traitement des risques, déclaration d’applicabilité
• ISO/IEC 27002:2022 — les 93 mesures et leurs recommandations de mise en œuvre
• ISO — page officielle de la norme ISO/IEC 27001

Aller plus loin

La construction de la SoA est traitée en profondeur dans notre formation ISO/IEC 27001 Lead Implementer, et vue du côté du contrôle dans Lead Auditor. Si vous migrez depuis la version 2013, la formation ISO/IEC 27001 Transition couvre spécifiquement les écarts.

Pour un accompagnement opérationnel, nous intervenons en gouvernance, risques et conformité.