À qui s’adresse cet article : à quiconque s’apprête à lancer ISO 27001 dans une entreprise sans équipe sécurité dédiée, et à quiconque voit son projet bloqué parce que les deux premiers documents n’ont jamais été réellement tranchés.
Presque tous les projets ISO 27001 qui tournent mal ont déraillé dans les quinze premiers jours, sur deux documents qui ressemblent à de l’administratif. L’énoncé de périmètre décide de la quantité de travail que vous avez acceptée. La déclaration d’applicabilité décide de ce sur quoi un auditeur vous tiendra. Réussissez-les et le reste du projet n’est que labeur. Ratez-les et soit vous ferez deux fois le travail nécessaire, soit vous terminerez en découvrant que le certificat ne répond pas à la question posée par votre client.
Aucun des deux documents n’est compliqué. Ils sont simplement mal expliqués.
Le périmètre : ce que c’est, en une phrase
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. Quand votre client grand compte demande une preuve, son service achats ne lit pas votre registre des risques. Il lit la ligne de périmètre sur le certificat et vérifie si elle contient le service qu’il achète. Un certificat techniquement parfait mais au mauvais périmètre a très peu de valeur commerciale.
Les trois façons dont les petites entreprises ratent leur périmètre
Cadrer pour faciliter l’audit. La tentation est évidente. Réduisez la frontière à une équipe, un produit, un bureau, et la charge s’effondre. La valeur s’effondre aussi. Nous avons vu des certificats cadrés sur une fonction informatique interne alors que l’entreprise vend un produit hébergé, ce qui ne répond à la question de personne.
Cadrer sur toute l’entreprise parce que cela semble honnête. L’échec inverse. Une entreprise de 40 personnes qui met tous ses systèmes, tous ses bureaux et tous ses projets annexes dans le périmètre 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.
Tracer une frontière que vous ne pouvez pas défendre. Le périmètre doit être défendable sur ses bords. Si votre produit dans le périmètre tourne sur une infrastructure partagée, utilise le même fournisseur d’identité et est développé par les mêmes ingénieurs que celui hors périmètre, un auditeur demandera comment la frontière est appliquée. Si la réponse est qu’elle ne l’est pas, la frontière est une fiction et la non-conformité est réelle.
Le test pratique : relisez votre projet d’énoncé de périmètre, puis demandez-vous si vous pourriez expliquer à un auditeur exactement où passe la frontière, ce qui la traverse et comment les traversées sont contrôlées. Si vous hésitez, redessinez-la.
La décision de cadrage qui économise le plus de travail
Cadrez par service, pas par département.
Les départements sont politiques et poreux. Les services ont des interfaces, une infrastructure et des responsables que vous pouvez désigner. Cadrer sur « la plateforme SaaS et les équipes et systèmes qui la construisent, l’exploitent et la supportent » donne une frontière qu’un auditeur peut parcourir, et c’est précisément ce que votre client veut voir nommé sur le certificat.
La décision de cadrage qui se retourne le plus souvent contre vous est l’exclusion d’une dépendance partagée : le fournisseur d’identité, la chaîne d’intégration continue, l’outil de tickets, les ordinateurs portables. Tout ce qui est partagé entre le travail dans le périmètre et hors périmètre finira dans le périmètre en pratique, autant l’inclure délibérément et le contrôler une seule fois.
C’est le même raisonnement qui décide si une entité tombe dans un périmètre réglementaire, et si vous traitez aussi NIS2, le parallèle mérite la lecture de notre guide du champ d’application et de l’applicabilité de NIS2.
La déclaration d’applicabilité : ce que c’est vraiment
La déclaration d’applicabilité, souvent abrégée DdA ou SoA, est un tableau unique listant chaque mesure de l’annexe A de la norme. Les 93 de l’édition 2022. Pour chacune, vous consignez quatre choses :
- Si elle s’applique à vous.
- Pourquoi, en une phrase. C’est la justification, et elle est exigée aussi bien pour applicable que pour non applicable.
- Si elle est actuellement mise en oeuvre.
- Où se trouve la preuve.
C’est tout. Un tableau de 93 lignes et quatre colonnes utiles.
Son importance est sans commune mesure avec sa complexité, pour une raison : c’est sur la DdA que vous êtes audité. Pas sur la norme dans l’abstrait, pas sur ce que fait une entreprise comparable. Sur le document dans lequel vous avez dit à l’auditeur ce que vous alliez faire. Elle est à la fois votre plan de travail, votre liste de contrôle d’audit et, si vous l’écrivez sans soin, la corde que vous tendez à l’auditeur.
Là où les audits se gagnent et se perdent : le mot « applicable »
Marquer une mesure non applicable est parfaitement légitime. La norme s’y attend. Une entreprise sans salle serveur n’a pas besoin de mesures sur l’accès aux salles serveurs. Une entreprise qui n’écrit pas de logiciel n’a pas besoin des mesures de codage sécurisé.
L’échec n’est pas l’exclusion. L’échec est l’exclusion avec une justification qui ne survit pas à une seule question de relance.
Des justifications qui échouent :
- « Non applicable, nous sommes une petite entreprise. » La taille n’est pas une raison. La norme s’adapte déjà au 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 choisi et que vous le surveillez.
- « 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 sur étagère et couvertes par la mesure 8.30 développement externalisé, marquée applicable. »
- « Applicable, non encore mise en oeuvre. La prévention des fuites de données est planifiée au premier trimestre avec le déploiement des postes. Risque accepté dans l’intervalle par le CTO, consigné sous R-014. »
Notez la forme des bonnes justifications. Elles nomment la raison, désignent la mesure compensatoire ou la décision de risque, et donnent à l’auditeur une piste à suivre. Ce dernier exemple mérite d’être copié : admettre qu’une mesure est applicable et pas encore mise en oeuvre n’est pas un échec. C’est un état légitime, tant qu’il existe un plan et un risque accepté derrière. Les entreprises s’attirent des ennuis en marquant comme mises en oeuvre des choses qui restent des intentions, ce qui transforme une conversation de planification en non-conformité.
Les onze mesures qui prennent tout le monde 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 d’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 à recopier. Si votre DdA contient des justifications minces, elles se trouvent presque certainement dans cette liste. À vérifier aussi : la transition depuis l’édition 2013 s’est close le 31 octobre 2025, donc tout modèle de DdA utilisant encore l’ancienne numérotation à 114 mesures est obsolète. Les auditeurs travaillent désormais exclusivement sur le jeu 2022.
Garder les deux documents vivants
Le périmètre et la DdA ne sont pas des livrables ponctuels. Ce sont les deux documents les plus susceptibles de devenir discrètement faux.
Vous lancez un nouveau produit. Vous déplacez une charge de travail. Vous adoptez un nouveau fournisseur. Vous intégrez une équipe. Chacun de ces événements déplace la frontière ou change les mesures applicables, et si aucun des deux documents ne bouge, votre système de management décrit désormais une entreprise qui n’existe plus.
L’édition 2022 traite cela directement par la clause qui impose de planifier les changements du système de management plutôt que de le laisser dériver. En pratique, l’habitude qui fonctionne est de revoir périmètre et DdA à chaque revue de direction, et d’ajouter une question unique à tout changement technique ou organisationnel significatif : cela déplace-t-il la frontière, ou change-t-il une décision d’applicabilité ?
C’est aussi là que l’outillage gagne sa place, non pas en écrivant les documents à votre place mais en gardant les mesures, les risques, les responsables et les preuves connectés, de sorte qu’un changement dans l’un apparaisse dans les autres. C’est l’objet du module risque et conformité de notre plateforme, et c’est la différence entre un système qui reste vrai et un système exact pendant un trimestre.
Pour une vue d’ensemble de ce qu’implique une première certification dans une entreprise sans fonction sécurité, commencez par ISO 27001 pour une entreprise sans équipe sécurité, et sur la question du budget en particulier, les 50 000 € pour ISO 27001 en valent-ils la peine. Les fournisseurs méritent une attention précoce, car les mesures fournisseurs de la DdA sont celles dont la traîne de travail est la plus longue, sujet traité dans l’appréciation du risque de la chaîne d’approvisionnement. Le parcours complet est présenté sur notre page solution ISO 27001.
La réalité technique : un périmètre serré protège le certificat, pas l’entreprise
Voici ce que la norme laisse ouvert, et cela découle directement de tout ce qui précède.
Le périmètre définit la frontière de ce qui est audité. Il ne définit pas la frontière de ce qui est attaqué. Un attaquant ne lit pas votre énoncé de périmètre. Si votre site marketing hors périmètre partage un fournisseur d’identité avec votre plateforme dans le périmètre, ou si votre outillage interne exclu détient des identifiants de production, alors la frontière certifiée et la surface d’attaque réelle ont des formes différentes, et l’écart est invisible dans tous les documents que vous avez produits.
La même chose vaut pour la DdA. Une mesure marquée non applicable avec une justification impeccable reste une mesure que vous n’appliquez pas. C’est une position d’audit défendable et cela peut être une mauvaise position de sécurité. Les deux affirmations peuvent être vraies en même temps, et la DdA n’est pas conçue pour vous dire quand elles divergent.
La discipline utile consiste donc à tenir deux listes. La DdA, qui est ce que vous devez à l’auditeur. Et une liste plus courte et plus brutale de ce que vous avez exclu ou reporté et qui vous ferait réellement mal si c’était exploité : 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 qu’il vaut la peine de lire en revue de direction.
Cadrez votre certificat pour répondre à la question de votre client. Puis regardez ce qui est tombé en dehors, et soyez honnête sur ce qu’un attaquant atteindrait en premier.
