Périmètre ISO 27001 et déclaration d'applicabilité : comment les rédiger

Le périmètre ISO 27001 est la frontière de votre système de management et figure sur le certificat. La déclaration d'applicabilité liste les 93 mesures de l'annexe A et sert de base à l'audit. Comment tracer le périmètre, justifier les exclusions et tenir les deux à jour.

Daniel Grigorovich
Daniel Grigorovich
Fondateur · 2 Sept 2026 · 9 min de lecture
ISO 27001GRC
Périmètre ISO 27001 et déclaration d'applicabilité

Dans ISO 27001, le périmètre est la frontière écrite de ce que couvre votre système de management, et la déclaration d’applicabilité (DdA, en anglais « Statement of Applicability ») est un tableau des 93 mesures de l’annexe A qui indique lesquelles s’appliquent et pourquoi. Le périmètre détermine la quantité de travail que vous vous engagez à fournir, et il figure sur votre certificat. La DdA détermine ce sur quoi l’auditeur vous jugera.

Ce guide traite du périmètre, des trois erreurs de cadrage les plus courantes, de la DdA, de la rédaction des justifications, des mesures de 2022 qui prennent les entreprises au dépourvu, et de la mise à jour des deux documents.

Énoncé de périmètreDéclaration d’applicabilité
Ce que c’estLa frontière écrite du système de managementUn tableau des 93 mesures de l’annexe A
Ce qui y est consignéOrganisation, services, systèmes, sites et personnes couvertsApplicable ou non, pourquoi, mise en œuvre ou non, où se trouve la preuve
Qui le litLe service achats de votre client, sur le certificatL’auditeur, comme base de l’audit
Erreur habituelleUne frontière trop étroite, trop large ou indéfendableUne exclusion qui ne résiste pas à une seule question de relance

Presque tous les projets ISO 27001 qui tournent mal ont déraillé dans les quinze premiers jours, sur ces deux documents. Si vous les ratez, soit vous faites deux fois le travail nécessaire, soit vous obtenez un certificat qui ne répond pas à la question de votre client.

Qu’est-ce que le périmètre ISO 27001 ?

Le périmètre est la frontière écrite de ce que couvre votre système de management : quelles parties de l’organisation, quels services, quels systèmes, quels sites et quelles personnes.

Il figure sur le certificat. C’est le détail que tout le monde oublie. Le service achats de votre client grand compte ne lit pas votre registre des risques. Il lit la ligne de périmètre sur le certificat et vérifie qu’elle contient le service qu’il achète. Un certificat techniquement parfait avec le mauvais périmètre a très peu de valeur commerciale.

Quelles sont les erreurs de périmètre ISO 27001 les plus fréquentes ?

1. Cadrer le périmètre pour faciliter l’audit

Réduisez la frontière à une équipe, un produit, un bureau, et la charge de travail s’effondre. La valeur aussi. Nous avons vu des certificats dont le périmètre se limitait à une fonction informatique interne, alors que l’entreprise vend un produit hébergé. Cela ne répond à la question de personne.

2. Inclure toute l’entreprise parce que cela semble honnête

Une entreprise de 40 personnes qui inclut dans le périmètre tous ses systèmes, tous ses bureaux et tous ses projets annexes a multiplié la charge de preuve sans aucun gain commercial. Un périmètre large est une décision qui se paie, pas une position morale.

3. Tracer une frontière que vous ne pouvez pas défendre

Supposons que votre produit inclus dans le périmètre tourne sur une infrastructure partagée, utilise le même fournisseur d’identité et soit développé par les mêmes ingénieurs que le produit hors périmètre. Un auditeur demandera comment la frontière est appliquée. Si elle ne l’est pas, la frontière est une fiction et le constat d’audit est bien réel.

Le test pratique : pourriez-vous expliquer à un auditeur exactement où passe la frontière, ce qui la traverse et comment ces traversées sont contrôlées ? Si vous hésitez, redessinez-la.

Comment définir un périmètre ISO 27001 qui économise du travail ?

Définissez le périmètre par service, pas par département.

Les départements sont politiques et poreux. Les services ont des interfaces, une infrastructure et des responsables que l’on peut désigner. Un périmètre défini comme « la plateforme SaaS et les équipes et systèmes qui la développent, l’exploitent et en assurent le support » donne une frontière qu’un auditeur peut parcourir. C’est aussi exactement ce que votre client veut voir nommé sur le certificat.

La décision qui se retourne le plus souvent contre vous est l’exclusion d’une dépendance partagée : le fournisseur d’identité, la chaîne CI, l’outil de tickets, les ordinateurs portables. Tout ce qui est partagé entre ce qui est dans le périmètre et ce qui n’y est pas finit en pratique dans le périmètre. Incluez-le donc délibérément et contrôlez-le une seule fois.

C’est le même raisonnement qui détermine si une entité entre dans un périmètre réglementaire. Si vous travaillez aussi sur NIS2, le parallèle figure dans notre guide du champ d’application et de l’applicabilité de NIS2.

Qu’est-ce que la déclaration d’applicabilité ?

La DdA est un tableau unique qui liste chaque mesure de l’annexe A de la norme : les 93 de l’édition 2022. Pour chacune, vous consignez quatre éléments :

  1. Si elle s’applique à vous.
  2. Pourquoi, en une phrase. Cette justification est exigée aussi bien pour une mesure applicable que non applicable.
  3. Si elle est actuellement mise en œuvre.
  4. Où se trouve la preuve.

C’est tout : 93 lignes et quatre colonnes utiles.

Son importance est sans commune mesure avec sa complexité, car c’est sur la DdA que vous êtes audité. Pas sur la norme dans l’abstrait, pas sur ce que fait une entreprise comparable. C’est votre plan de travail, votre liste de contrôle d’audit et, si vous la rédigez sans soin, le bâton que vous tendez à l’auditeur pour vous faire battre.

Comment justifier l’exclusion d’une mesure de l’annexe A ?

Déclarer une mesure non applicable est légitime, et la norme s’y attend. Une entreprise sans salle serveur physique n’a pas besoin de mesures de contrôle d’accès aux salles serveurs. Une entreprise qui ne développe aucun logiciel n’a pas besoin des mesures de codage sécurisé. L’échec, c’est une exclusion dont la justification ne résiste pas à une seule question de relance.

Des justifications qui ne tiennent pas :

  • « Non applicable, nous sommes une petite entreprise. » La taille n’est pas une raison. La norme s’adapte déjà en fonction du risque.
  • « Non applicable, nous utilisons un fournisseur cloud. » Recourir à un fournisseur transfère l’exploitation, pas la responsabilité. Vous devez toujours démontrer que vous l’avez sélectionné et que vous le supervisez.
  • « Non applicable, sans rapport avec notre activité. » C’est une reformulation, pas une raison.

Des justifications qui tiennent :

  • « Non applicable. L’organisation n’exploite aucun centre de données sur site. Toute l’infrastructure de production est hébergée par [fournisseur], couverte par les mesures fournisseurs 5.19 à 5.22. »
  • « Non applicable. L’organisation ne développe aucun logiciel. Toutes les applications sont des produits du commerce, couverts par la mesure 8.30 Développement externalisé, déclarée applicable. »
  • « Applicable, pas encore mise en œuvre. La prévention des fuites de données est prévue au T1 avec le déploiement sur les postes de travail. Risque accepté dans l’intervalle par le CTO, enregistré sous R-014. »

Les bonnes justifications nomment la raison, désignent la mesure compensatoire ou la décision de risque, et donnent à l’auditeur une piste à suivre.

Admettre qu’une mesure est applicable mais pas encore mise en œuvre n’est pas un échec. C’est un état légitime, à condition qu’un plan et un risque accepté se trouvent derrière. Les entreprises s’attirent des ennuis en déclarant mises en œuvre des mesures qui ne sont encore que des intentions, ce qui transforme une discussion de planification en non-conformité.

Ce sont les mesures fournisseurs qui demandent le travail le plus long : commencez-les tôt. Voir l’appréciation des risques de la chaîne d’approvisionnement.

Quelles mesures de l’annexe A prennent les entreprises au dépourvu ?

L’édition 2022 a ajouté onze mesures absentes des anciens réflexes : renseignement sur les menaces, services cloud, préparation des TIC pour la continuité d’activité, surveillance de la sécurité physique, gestion des configurations, suppression des informations, masquage des données, prévention des fuites de données, activités de surveillance, filtrage web et codage sécurisé.

Ce sont les lignes où les DdA deviennent vagues, faute de réponse type héritée à recopier. Si votre DdA contient des justifications minces, elles se trouvent presque certainement ici.

Vérifiez aussi le modèle. La transition depuis l’édition 2013 s’est terminée le 31 octobre 2025 : tout modèle qui utilise encore l’ancienne numérotation à 114 mesures est donc obsolète. Les auditeurs travaillent désormais exclusivement sur le référentiel 2022.

À quelle fréquence mettre à jour le périmètre et la DdA ?

Le périmètre et la DdA sont les deux documents les plus susceptibles de devenir faux sans que personne ne s’en aperçoive.

Vous lancez un produit, déplacez une charge de travail, adoptez un nouveau fournisseur ou reprenez une équipe. Chacun de ces changements déplace la frontière ou modifie les mesures applicables. Si aucun des deux documents ne bouge, votre système de management décrit une entreprise qui n’existe plus.

L’édition 2022 traite ce point par la clause qui impose de planifier les modifications du système de management plutôt que de le laisser dériver. L’habitude qui fonctionne :

  1. Revoir le périmètre et la DdA à chaque revue de direction.
  2. Poser la question pour chaque changement technique ou organisationnel significatif : cela déplace-t-il la frontière, ou modifie-t-il une décision d’applicabilité ?

C’est là que l’outillage trouve sa place : non pas en rédigeant les documents, mais en gardant liés les mesures, les risques, les responsables et les preuves, pour qu’un changement dans l’un apparaisse dans les autres. C’est le rôle du module risque et conformité de notre plateforme. C’est la différence entre un système qui reste exact et un système exact le temps d’un trimestre.

Pour une vue d’ensemble dans une entreprise sans fonction sécurité, lisez ISO 27001 pour une entreprise sans équipe sécurité. Côté budget, voir les 50 000 € pour ISO 27001 en valent-ils la peine. Le parcours complet est présenté sur notre page solution ISO 27001.

Un périmètre restreint rend-il l’entreprise plus sûre ?

Non. Un périmètre restreint protège le certificat, pas l’entreprise.

Le périmètre définit la frontière de ce qui est audité, pas de ce qui est attaqué. Un attaquant ne lit pas votre énoncé de périmètre. Votre site marketing hors périmètre peut partager un fournisseur d’identité avec votre plateforme incluse dans le périmètre. Votre outillage interne exclu peut détenir des identifiants de production. La frontière certifiée et la surface d’attaque réelle n’ont alors pas la même forme, et aucun des documents que vous avez produits ne le montre.

Il en va de même pour la DdA. Une mesure déclarée non applicable avec une justification impeccable reste une mesure que vous n’appliquez pas. Cela peut être à la fois une position défendable en audit et une mauvaise position de sécurité, et la DdA n’est pas conçue pour vous signaler quand les deux divergent.

Tenez donc deux listes. La DdA, qui est ce que vous devez à l’auditeur. Et une liste plus courte et plus franche de ce que vous avez exclu ou reporté et qui ferait mal en cas d’exploitation : le chemin d’identité partagé, le travail de détection reporté, la fenêtre de correctifs acceptée, la restauration jamais testée. Personne ne demande cette seconde liste. C’est celle qui mérite d’être lue en revue de direction.

Définissez le périmètre de votre certificat pour répondre à la question de votre client. Puis regardez ce qui est resté en dehors, et soyez honnête sur ce qu’un attaquant atteindrait en premier.

Liste de contrôle : périmètre et DdA

  • Définissez le périmètre par service, pas par département, et nommez le service que vos clients achètent.
  • Vérifiez que vous pouvez expliquer où passe la frontière, ce qui la traverse et comment ces traversées sont contrôlées.
  • Incluez délibérément les dépendances partagées dans le périmètre : fournisseur d’identité, chaîne CI, outil de tickets, ordinateurs portables.
  • Construisez la DdA sur les 93 mesures de l’édition 2022, pas sur l’ancienne numérotation à 114 mesures.
  • Donnez à chaque mesure une justification d’une phrase qui résiste à une question de relance.
  • Ne déclarez une mesure mise en œuvre que lorsqu’elle fonctionne réellement ; pour les autres, consignez le plan et le risque accepté.
  • Revoyez le périmètre et la DdA à chaque revue de direction et à chaque changement significatif.
  • Tenez une liste séparée des exclusions et des reports qu’un attaquant atteindrait en premier.

Questions fréquentes

Que doit contenir l'énoncé de périmètre ISO 27001 ?

Le périmètre est la frontière écrite de ce que couvre votre système de management : quelles parties de l'organisation, quels services, quels systèmes, quels sites et quelles personnes. Il figure sur le certificat et doit donc nommer le service que vos clients achètent.

Qu'est-ce que la déclaration d'applicabilité dans ISO 27001 ?

C'est un tableau unique qui liste chaque mesure de l'annexe A, soit 93 dans l'édition 2022. Pour chacune, il indique si elle s'applique, une justification d'une phrase, si elle est mise en œuvre et où se trouve la preuve. C'est le document sur lequel vous êtes audité.

Peut-on exclure des mesures de l'annexe A dans la déclaration d'applicabilité ?

Oui. Déclarer une mesure non applicable est légitime, et la norme s'y attend. La justification doit nommer une vraie raison, par exemple l'absence de centre de données sur site, et résister à une question de relance. La taille de l'entreprise n'est pas une raison.

Une mesure peut-elle être applicable sans être encore mise en œuvre ?

Oui, à condition qu'un plan et un risque accepté se trouvent derrière, par exemple un déploiement programmé dont le risque intermédiaire est accepté par un responsable nommé. Déclarer mises en œuvre des mesures qui ne sont que des intentions transforme une discussion de planification en non-conformité.

Une déclaration d'applicabilité fondée sur ISO 27001:2013 est-elle encore valable ?

Non. La transition depuis l'édition 2013 s'est terminée le 31 octobre 2025 : un modèle qui utilise l'ancienne numérotation à 114 mesures est donc obsolète. Les auditeurs travaillent désormais exclusivement sur le référentiel 2022.

Découvrez comment CloudSoul fonctionnerait pour vous.

Daniel Grigorovich

Daniel Grigorovich · Fondateur

Je pense qu'aucune entreprise ne devrait avoir à subir les « listes de contrôle de conformité » ni à se débattre avec des textes réglementaires obscurs. Bien que je reste attaché au principe selon lequel tous les logiciels doivent être fiables et sécurisés, je souhaite offrir aux entreprises un moyen de surmonter les difficultés rencontrées lors de la mise en œuvre de ces exigences.