La déclaration d’applicabilité est le document le plus lu et le plus mal rédigé de toute une démarche ISO 27001. C’est la première chose qu’ouvre un auditeur, parce qu’elle lui donne en quelques pages le périmètre réel de votre système de management. C’est aussi celle que la plupart des organisations produisent en dernier, à partir d’un modèle téléchargé, ce qui est exactement l’ordre inverse de celui qui fonctionne. Voici la méthode en sept étapes que nous appliquons, dans l’ordre où elle doit être suivie.
Ce que ce document est réellement
La déclaration d’applicabilité — Statement of Applicability, ou SoA — recense quatre informations et rien d’autre : les mesures de sécurité que vous retenez, la raison pour laquelle vous les retenez, leur état de mise en œuvre, et la justification de l’exclusion de celles de l’Annexe A que vous n’appliquez pas.
La version 2022 de l’Annexe A compte 93 mesures, contre 114 dans la version précédente, réorganisées en quatre thèmes : organisationnel (37 mesures), personnes (8), physique (14) et technologique (34). Cette réorganisation a une conséquence pratique que beaucoup d’équipes découvrent tard : les mesures ne sont plus rangées dans l’ordre où une PME les met en place, et parcourir la liste de haut en bas donne une impression de désordre qui décourage.
Le malentendu de fond est là. Ce document n’est pas un questionnaire à remplir, c’est le compte rendu d’une décision déjà prise. Si la décision n’a pas été prise, aucune rédaction soignée ne sauvera le document.
Étape 1 — Partir de l’analyse de risque, jamais de la liste des 93 mesures
C’est l’étape qui décide de la qualité de tout le reste, et c’est celle que l’on saute presque toujours, parce que la liste des 93 mesures existe et qu’il est tentant de la parcourir.
L’ordre correct est le suivant : vous identifiez vos risques, vous décidez de la manière de les traiter, et les mesures que ce traitement appelle deviennent les mesures incluses. L’Annexe A n’intervient qu’ensuite, comme une liste de vérification destinée à repérer ce que vous auriez oublié. C’est d’ailleurs sa fonction explicite dans la norme : un filet de sécurité, pas un point de départ.
La différence est immédiatement visible à la lecture. Un document construit dans le bon sens contient des mesures dont la justification renvoie à un risque identifié. Un document construit à l’envers contient des justifications interchangeables du type « bonne pratique de sécurité », qui ne disent rien de votre organisation et qu’un auditeur repère en trois pages.
Étape 2 — Trancher les quatre statuts possibles, sans en inventer un cinquième
Chaque mesure reçoit exactement un statut parmi quatre : incluse et en place ; incluse et planifiée, avec une date et un responsable ; exclue, avec justification ; sans objet, faute de périmètre concerné.
Le statut qui pose problème est le cinquième, celui que les équipes créent spontanément : « partiellement en place ». Il paraît honnête et il est ingérable, parce qu’il ne dit ni ce qui est fait, ni ce qui reste. Quand une mesure est partiellement appliquée, la bonne écriture consiste à la découper : la partie appliquée passe en incluse et en place avec sa preuve, le reste passe en incluse et planifiée avec une date. Le document devient plus long et beaucoup plus solide.
La distinction entre exclue et sans objet mérite aussi d’être tenue. Une mesure sur le développement sécurisé est sans objet si vous ne développez rien ; elle est exclue si vous développez et choisissez de ne pas l’appliquer — ce qui est un tout autre sujet, et une décision qui devra être défendue.
Étape 3 — Justifier chaque exclusion par une phrase vérifiable
Exclure est normal. Aucune organisation n’applique les 93 mesures, et un document qui n’exclut rien est plus suspect qu’un document qui exclut sept mesures avec méthode.
Ce qui déclenche un écart, ce n’est jamais l’exclusion, c’est sa justification. Une justification recevable énonce un fait constatable sur votre périmètre : « l’organisation n’exploite aucun système d’information hébergé dans ses locaux », « aucun développement logiciel n’est réalisé en interne », « l’organisation n’emploie aucun personnel sur site ». Une justification irrecevable exprime une intention ou une contrainte : trop coûteux, prévu l’an prochain, non prioritaire.
Retour de terrain
Le test que nous utilisons est brutal et il fonctionne : l’auditeur doit pouvoir vérifier l’exclusion en une seule question. « Hébergez-vous des serveurs dans vos locaux ? » — non — l’exclusion des mesures de sécurité physique des salles machines tombe d’elle-même. Si votre justification demande trois minutes d’explication, un schéma et un « mais en fait », ce n’est pas une exclusion : c’est une mesure incluse que vous n’avez pas traitée, et il vaut infiniment mieux l’écrire ainsi, avec une date, que de la déguiser. Un auditeur pardonne un plan d’action ; il ne pardonne pas une exclusion qui masque un trou.
Votre SoA tient-il en une question par ligne ?
Nous relisons votre déclaration d’applicabilité mesure par mesure et vous rendons la liste des justifications qui ne passeront pas, avant que l’auditeur ne la fasse.
Lance-toi — relecture de SoAÉtape 4 — Rattacher chaque mesure incluse à une preuve qui existe déjà
Pour chaque mesure incluse, une colonne supplémentaire, et une seule : où se trouve la preuve. Un nom de document, une capture d’un écran de configuration, un export daté, une référence de procédure. Pas « politique de sécurité » en général, mais le paragraphe précis.
Cette colonne est la raison pour laquelle l’exercice prend deux à trois semaines plutôt que deux jours, et c’est aussi la raison pour laquelle il a de la valeur. Elle révèle systématiquement le même écart : des pratiques réelles, appliquées correctement depuis des années, dont il n’existe aucune trace consultable. La sauvegarde est testée — personne n’a jamais noté quand. Les accès sont revus au départ d’un salarié — aucune liste ne l’atteste.
Une mesure sans preuve nommée et datée sera considérée comme non appliquée le jour de l’audit. Ce n’est pas une injustice de procédure : du point de vue de l’auditeur, une pratique que rien ne matérialise repose entièrement sur la mémoire d’une personne, et disparaît avec elle.
Étape 5 — Distinguer la mesure en place et la mesure documentée
Deux situations symétriques échouent à l’audit, pour des raisons opposées, et il faut savoir les nommer séparément.
La première est la pratique non écrite : l’équipe fait la bonne chose, personne ne l’a formalisée. C’est la plus fréquente en PME et la plus rapide à corriger — une demi-page de procédure et un enregistrement daté suffisent souvent.
La seconde est la procédure non suivie : le document existe, il est beau, et la réalité s’en écarte depuis dix-huit mois. Celle-ci est nettement plus grave, parce qu’un auditeur qui constate un écart entre le document et le terrain cesse de faire confiance à l’ensemble du système documentaire — y compris aux parties qui étaient justes. Si vous devez arbitrer, corrigez d’abord les procédures fausses, ensuite les pratiques non écrites.
Étape 6 — Faire relire par quelqu’un qui n’a pas écrit le document
Le rédacteur d’une déclaration d’applicabilité connaît son organisation, et c’est précisément le problème : il complète mentalement chaque ligne avec ce qu’il sait, sans voir que le document, lui, ne le dit pas.
La relecture utile ne demande aucune expertise ISO. Elle demande une consigne unique : pour chaque ligne, poser la question « comment le vérifierais-je si je ne te croyais pas ? ». Un responsable d’une autre équipe fait très bien l’affaire, souvent mieux qu’un consultant, parce qu’il ne partage pas les angles morts de l’auteur. Comptez une demi-journée pour un document complet.
Étape 7 — Dater, versionner et fixer la revue avant de clore
Une déclaration d’applicabilité est un document vivant, et un document vivant sans numéro de version ni date d’approbation ne prouve rien : on ne sait pas à quel périmètre ni à quelle organisation il correspond.
Trois mentions suffisent : la version et sa date, le nom de la personne qui approuve — une personne, pas une direction —, et la date de la prochaine revue. Une revue annuelle constitue le minimum, à laquelle s’ajoutent les revues déclenchées par un événement : nouveau site, changement d’hébergement, acquisition, incident significatif. C’est ce dernier point qui distingue un document tenu d’un document ressorti en urgence trois semaines avant l’audit de surveillance.
Où ce document croise NIS2
NIS2 n’exige ni déclaration d’applicabilité ni certification ISO 27001. Elle impose des mesures de gestion des risques et des obligations de notification. Mais la correspondance est forte : politique de sécurité, gestion des incidents, continuité d’activité, sécurité de la chaîne d’approvisionnement et contrôle d’accès trouvent tous leur équivalent dans l’Annexe A. Une organisation qui tient sa déclaration d’applicabilité à jour a donc déjà fait l’essentiel de la cartographie, et il lui reste principalement à traiter la dimension de notification, avec ses délais propres.
Ces sujets de traçabilité et de preuve recoupent ceux que rencontrent les équipes techniques sur leurs dépendances et leurs chaînes de production, documentés côté écosystème open source, et les questions d’outillage traitées côté automatisation en entreprise. Pour délimiter ce qui vous concerne, commencez par notre page audit de périmètre NIS2 ; la comparaison des deux cadres est détaillée dans différence entre NIS2 et ISO 27001.
Questions fréquentes
Qu’est-ce que la déclaration d’applicabilité et pourquoi est-elle obligatoire ?
La déclaration d’applicabilité, souvent abrégée SoA pour Statement of Applicability, est le document qui recense les mesures de sécurité retenues pour votre système de management de la sécurité de l’information, la justification de leur sélection, leur état de mise en œuvre, et la justification de l’exclusion des mesures de l’Annexe A que vous n’appliquez pas. Elle est exigée par la norme au titre du traitement du risque et constitue, dans les faits, le premier document que consulte un auditeur : il y trouve en quelques pages le périmètre réel de votre démarche. C’est aussi le document qui relie l’analyse de risque, souvent abstraite, aux preuves concrètes que vous produirez ensuite. Une déclaration d’applicabilité bien construite rend l’audit prévisible ; une déclaration bâclée le transforme en exploration.
Peut-on exclure des mesures de l’Annexe A sans risquer un écart ?
Oui, et c’est même attendu : aucune organisation n’applique les 93 mesures de l’Annexe A de la version 2022. Ce qui déclenche un écart n’est pas l’exclusion elle-même mais sa justification. Une justification recevable s’appuie sur un fait constatable relatif à votre périmètre — vous n’exploitez aucun développement interne, vous n’hébergez aucun système en propre, vous n’employez aucun personnel sur site. Une justification irrecevable exprime une intention ou une contrainte : la mesure est jugée trop coûteuse, elle est prévue pour l’an prochain, elle ne paraît pas prioritaire. La règle pratique que nous appliquons est qu’une exclusion doit pouvoir être vérifiée par l’auditeur en une question ; si elle demande une explication de trois minutes, ce n’est pas une exclusion, c’est une mesure incluse et non traitée.
Combien de temps faut-il pour rédiger une déclaration d’applicabilité ?
Pour une PME dont l’analyse de risque est déjà faite, comptez deux à trois semaines de travail effectif, réparties sur un mois ou deux. La rédaction elle-même prend peu de temps : ce qui en prend, c’est la collecte des preuves associées à chaque mesure incluse, parce qu’elle révèle systématiquement des pratiques réelles mais non documentées. Si l’analyse de risque n’existe pas encore, ne commencez pas par la déclaration d’applicabilité : vous produiriez un document sans fondement, qu’il faudrait entièrement reprendre. L’erreur de séquence la plus coûteuse que nous rencontrons consiste à télécharger un modèle de SoA et à le remplir en réunion, ce qui donne un document cohérent en apparence et sans lien avec l’organisation réelle.
La déclaration d’applicabilité sert-elle aussi pour NIS2 ?
Elle ne s’y substitue pas, mais elle constitue le meilleur point de départ dont vous puissiez disposer. NIS2 ne demande pas de déclaration d’applicabilité et n’exige aucune certification ISO 27001 : elle impose des mesures de gestion des risques et des obligations de notification. En pratique, la majorité des attentes de NIS2 en matière de politique de sécurité, de gestion des incidents, de continuité, de sécurité de la chaîne d’approvisionnement et de contrôle d’accès trouvent une correspondance directe dans les mesures de l’Annexe A. Une organisation qui tient une déclaration d’applicabilité à jour dispose donc déjà de la cartographie et des preuves ; le travail restant consiste à ajouter la dimension de notification, avec ses délais propres, que la déclaration d’applicabilité ne couvre pas.
Combien de vos mesures « en place » ont une preuve datée ?
C’est la seule question qui décide de l’issue d’un audit initial. Nous construisons la déclaration d’applicabilité avec vos équipes, preuve par preuve, et vous repartez avec le document et la méthode.
Lance-toi