Une déclaration de périmètre ISO 27001 est un paragraphe unique, prêt pour l'audit, qui définit la frontière du SMSI : les produits, services, sites et équipes couverts, ainsi que toute exclusion explicite accompagnée de sa justification. Elle répond directement à la clause 4.3, figure sur votre certificat et indique aux auditeurs exactement ce qu'ils vont contrôler. Une erreur à ce stade renchérit chaque étape ultérieure de la certification.
En résumé :
- Un périmètre large accroît l'effort d'audit, le nombre de mesures de sécurité requises et les coûts, tandis qu'un périmètre étroit et bien justifié permet d'obtenir la certification plus rapidement.
- Associer la direction générale, l'informatique, le juridique, le produit, les opérations et les fournisseurs clés garantit que le périmètre intègre tous les risques et toutes les dépendances pertinents, réduisant ainsi les questions ultérieures.
- Commencer la définition du périmètre par la liste des exclusions et leur justification améliore la clarté et réduit le risque de dérive du périmètre pendant la certification.
- La déclaration de périmètre doit être concise, centrée sur les produits, les sites et les équipes, avec des exclusions correctement expliquées, idéalement en un seul paragraphe.
- L'utilisation d'un outil de modélisation du périmètre permet de comparer différentes options de frontières, d'estimer leur impact sur l'effort d'audit et d'éviter des erreurs coûteuses avant de finaliser le périmètre.
Table des matières
- Pourquoi le périmètre ISO 27001 de votre SMSI est si important
- Qui doit être impliqué lors de la définition du périmètre
- Comment rédiger la déclaration de périmètre, étape par étape
- Un modèle de déclaration de périmètre et quatre exemples concrets
- Les erreurs de périmétrage qui retardent réellement la certification
- Déclaration de périmètre et déclaration d'applicabilité : quelle différence ?
- Ce que les auditeurs vérifient avant de valider
- Ce que les erreurs de périmètre coûtent réellement aux équipes en pratique
- Testez vos choix de périmètre avant de vous y engager
- Où trouver la norme elle-même et les ressources associées
- Sources
Pourquoi le périmètre ISO 27001 de votre SMSI est si important
La clause 4.3 exige que vous déterminiez et documentiez les limites et le domaine d'application de votre SMSI, et cette exigence est trompeusement courte au regard de son importance. Le périmètre n'est pas une formalité à expédier avant de commencer le « vrai travail ». C'est la décision qui conditionne tout le reste.
En pratique, le périmètre couvre les sites physiques, les unités organisationnelles, les actifs informationnels, les processus métier, la pile technologique et toutes les interfaces tierces en contact avec ce que vous protégez. Le périmètre d'un prestataire de paiement peut se limiter à un environnement AWS et à l'équipe d'ingénierie qui le gère. Celui d'un système hospitalier peut s'étendre sur trois bâtiments, une plateforme de dossiers patients et une douzaine d'intégrations fournisseurs.
Voici ce que beaucoup sous-estiment : les choix de périmètre se répercutent directement sur les coûts et les délais. Un périmètre large exige davantage d'effort d'audit, plus de mesures à justifier et plus de preuves à rassembler, tandis qu'un périmètre étroit et bien justifié permet d'obtenir le certificat plus vite et à moindre coût. Un certificat à périmètre défini détermine également quelles mesures de sécurité seront auditées et quelles parties de votre organisation le certificat couvre réellement — un client demandant « votre système de facturation est-il couvert ? » mérite une déclaration de périmètre qui répond sans ambiguïté. Le périmètre n'est pas seulement un exercice documentaire. C'est une décision budgétaire déguisée en clause de conformité.
Qui doit être impliqué lors de la définition du périmètre
Définir le périmètre en silo, c'est s'assurer de devoir réécrire la déclaration trois fois avant l'audit. Associez les personnes qui savent réellement où se trouvent les risques et les dépendances :
- La direction générale, pour confirmer quelles lignes d'activité le certificat doit soutenir commercialement.
- Les responsables informatiques et les leads techniques, qui connaissent la vraie cartographie de l'infrastructure, pas celle de l'organigramme.
- Le juridique et la conformité, pour les obligations réglementaires susceptibles d'imposer l'inclusion (ou l'exclusion) de certains types de données.
- Les responsables produit, qui savent quels services les clients souhaitent réellement voir certifiés.
- Les responsables des opérations et des sites, pour les emplacements physiques et l'infrastructure partagée.
- Les fournisseurs clés dont les systèmes sont en contact avec vos données ou processus dans le périmètre.
La cartographie des dépendances est là où la plupart des équipes se montrent négligentes. Si un système hors périmètre affecte substantiellement un service dans le périmètre — comme un pipeline CI/CD ou un système de sauvegarde partagé — vous devez soit l'inclure dans le périmètre, soit documenter les mesures compensatoires qu'un auditeur peut effectivement tester. Les exclusions arbitraires sont un signal d'alarme qui suscitera des questions plus difficiles par la suite.
Pour les organisations entièrement à distance ou hybrides, décrivez la réalité opérationnelle (régions cloud, politiques de télétravail, équipes distribuées) sans intégrer dans la déclaration elle-même des plages d'adresses IP ou des schémas réseau. Les auditeurs ont besoin de relier les mesures aux activités, pas de lire votre blueprint d'infrastructure.
Comment rédiger la déclaration de périmètre, étape par étape
Une fois les contributions rassemblées, la rédaction elle-même est mécanique si vous suivez une séquence fixe. Sauter des étapes, c'est exactement ainsi que les équipes se retrouvent avec un périmètre qui semble correct en interne et s'effondre face à un auditeur.
- Rassemblez le contexte et obtenez une validation. Documentez d'abord le contexte organisationnel (clause 4.1) et les parties intéressées (clause 4.2). Le périmètre doit servir les deux, pas seulement ce que l'informatique souhaite protéger.
- Cartographiez chaque actif, processus, site et interface. Listez les sites physiques, les applications, les flux de données et les connexions tierces. Cela constituera votre piste de preuves ultérieurement.
- Définissez vos frontières et consignez par écrit la raison de chaque exclusion. « La paie RH est exclue car elle fonctionne sur un système distinct, sans rapport, sans flux de données vers le SMSI » est défendable. « Les RH sont hors périmètre » sans explication ne l'est pas.
- Rédigez un paragraphe unique, en référence à la clause 4.3. Résistez à l'envie d'écrire deux pages. Une déclaration de périmètre doit être claire, concise et idéalement tenir en un seul paragraphe suffisamment court pour figurer sur le certificat lui-même.
- Testez-la face aux attentes des auditeurs et des clients. Lisez-la comme si vous étiez l'équipe sécurité d'un client potentiel. Répond-elle à la question « qu'est-ce qui est exactement couvert ? » sans nécessiter un appel de suivi ?
Conseil pratique : Rédigez la liste des exclusions avant la liste des inclusions. Coucher par écrit ce qui est exclu et pourquoi vous force à justifier chaque décision de frontière plutôt que de simplement décrire ce qui semble exhaustif.
La plupart des équipes rédigent le périmètre à rebours, en commençant large puis en réduisant. Partir de vos services orientés client et de vos opérations informatiques essentielles, puis n'étendre que là où les preuves l'exigent, produit un résultat plus précis et plus défendable. Démarrer avec les opérations essentielles et les services orientés client et étendre à la recertification est une approche éprouvée pour une bonne raison : elle rend la première année gérable.
Un modèle de déclaration de périmètre et quatre exemples concrets
Un modèle utilisable comporte quatre éléments variables, dont seulement deux sont véritablement obligatoires.
Modèle : « Le système de management de la sécurité de l'information couvre [nom du produit/service], notamment [activités/processus clés], exploité depuis [site(s)] par [équipe/unité opérationnelle]. Il exclut [exclusions spécifiques], car [justification]. »
La description du produit/service et les sites/équipes sont obligatoires. La clause d'exclusion est techniquement facultative, mais attendue par tout auditeur compétent. L'omettre ne rend pas votre périmètre plus large ; cela le rend vague, et le vague est ce qui est signalé.
Quatre exemples courts couvrant les types d'organisations les plus courants :
- Plateforme SaaS : « Le SMSI couvre l'infrastructure de production, le code applicatif et le traitement des données clients pour [Nom du produit], hébergé sur AWS dans la région US East et géré par les équipes Ingénierie de plateforme et Sécurité. Il exclut les systèmes RH et de paie de l'entreprise, qui fonctionnent sur un réseau distinct et isolé, sans flux de données vers la production. »
- Service managé pour grandes entreprises : « Le SMSI couvre la prestation de services de support informatique managé aux clients entreprises, notamment le service desk, les outils de supervision à distance et les données clients traitées dans le cadre des contrats de support actifs, exploité depuis nos bureaux de Chicago et d'Austin. Il exclut les systèmes marketing internes, qui ne contiennent aucune donnée client ni donnée opérationnelle. »
- Organisation entièrement à distance : « Le SMSI couvre l'ensemble de l'infrastructure hébergée dans le cloud, les postes de travail des collaborateurs soumis à la gestion des terminaux de l'entreprise, ainsi que les opérations de support client de [Société], quel que soit le lieu de travail des collaborateurs, géré par une équipe d'ingénierie et d'opérations entièrement distribuée. Il exclut les appareils personnels non enrôlés dans le dispositif de gestion des terminaux. »
- Site unique : « Le SMSI couvre l'ensemble des actifs informationnels, processus et personnels situés au siège social de [Société] à [adresse], notamment les départements Finance, Opérations et Service client. Il exclut les archives papier conservées hors site, gérées dans le cadre d'un accord de sécurité physique distinct. »
Notez qu'aucun de ces exemples ne dépasse trois phrases. Cette concision est le but, pas un choix stylistique dont vous pouvez vous affranchir si vous souhaitez développer davantage.
Les erreurs de périmétrage qui retardent réellement la certification
Un périmètre couvrant « l'ensemble de l'organisation » semble impressionnant, jusqu'à ce que vous soyez celui qui doit rassembler des preuves pour chaque département, y compris ceux qui n'ont rien à voir avec la sécurité de l'information. Cela peut se justifier pour les petites entreprises à fonction unique où tout touche réellement les mêmes systèmes. Pour toute structure plus grande, cela signifie généralement davantage d'heures d'audit et un calendrier plus long, sans bénéfice réel pour la sécurité.
L'erreur inverse consiste à définir un périmètre trop étroit pour contourner des mesures contraignantes. Si vous excluez un système qui touche clairement des données dans le périmètre, attendez-vous à ce que l'auditeur demande pourquoi, et à ce que « c'était plus simple » ne soit pas recevable.
- Évitez les formulations vagues comme « les systèmes informatiques concernés » qui ne nomment rien de concret.
- Documentez chaque exclusion avec une raison spécifique et vérifiable, pas une déclaration générale.
- Réévaluez le périmètre à la recertification plutôt que de l'élargir discrètement en cours de cycle sans mettre à jour votre analyse des risques.
- Soyez vigilant face à la dérive du périmètre lorsqu'un nouveau produit est lancé au sein d'un SMSI qui devait être étroitement délimité.
Conseil pratique : Si une nouvelle équipe ou un nouveau produit est constamment mentionné dans les discussions sur le périmètre sans avoir figuré dans la déclaration initiale, c'est une dérive du périmètre en temps réel. Gérez-la par une mise à jour formelle, ne laissez pas le libellé évoluer silencieusement.
Élargir le périmètre n'est pas intrinsèquement négatif. C'est souvent la bonne décision à mesure que votre SMSI mûrit. Le problème est de le faire sans mettre à jour la documentation, les analyses des risques et la déclaration d'applicabilité en conséquence.
Déclaration de périmètre et déclaration d'applicabilité : quelle différence ?
Ces deux éléments sont constamment confondus, et cette confusion est précisément ce qui ralentit les audits. La déclaration de périmètre (clause 4.3) définit la frontière : ce qui est inclus et ce qui est exclu. La déclaration d'applicabilité est un document distinct qui liste chaque mesure de l'Annexe A, indique si elle s'applique à l'intérieur de cette frontière et justifie pourquoi elle est incluse ou exclue.
Considérez le périmètre comme le tracé de la carte et la déclaration d'applicabilité comme la décision de savoir quelles routes de cette carte seront patrouillées. Les auditeurs s'attendent à ce que la déclaration d'applicabilité soit cohérente avec la déclaration de périmètre. Si votre périmètre mentionne le traitement des données clients mais que votre déclaration d'applicabilité exclut la justification du contrôle d'accès, c'est une incohérence immédiate qu'un auditeur signalera.
Exemple concret : une entreprise dont le périmètre est défini comme « l'infrastructure de production SaaS et l'équipe d'ingénierie qui la gère » justifierait généralement dans sa déclaration d'applicabilité des mesures relatives à la gestion des accès, à la cryptographie et aux relations fournisseurs, tandis que les mesures liées à la gestion des supports physiques pourraient être marquées comme non applicables, car aucun support physique n'existe dans ce périmètre. Le périmètre définit l'univers de ce qui est pertinent. La déclaration d'applicabilité procède à la justification mesure par mesure en son sein. Confondre les deux, ou traiter la déclaration d'applicabilité comme une extension du paragraphe de périmètre, est l'une des lacunes les plus fréquemment observées par les auditeurs.
Ce que les auditeurs vérifient avant de valider
Les auditeurs qui examinent le périmètre ne se contentent pas de lire le paragraphe isolément. Ils vérifient s'il est étayé par des preuves et cohérent avec l'ensemble de la documentation de votre SMSI.
- La déclaration de périmètre elle-même, comparée au libellé du certificat.
- L'analyse du contexte et des parties intéressées (clauses 4.1 et 4.2) justifiant le tracé de la frontière.
- Les résultats de l'analyse des risques couvrant tout ce qui est nommé dans le périmètre.
- La déclaration d'applicabilité, vérifiée pour sa cohérence avec les frontières du périmètre.
- Les cartographies des dépendances montrant comment les systèmes dans le périmètre se connectent à tout ce qui en est exclu.
- Les preuves fournisseurs pour tout tiers en contact avec des données ou des processus dans le périmètre.
- Les preuves de configuration et d'inventaire des actifs pour les systèmes dans le périmètre spécifiquement, et non pour l'ensemble du parc informatique.
Lorsque vous présentez des exclusions, commencez par la justification, pas par l'exclusion elle-même. « Nous avons exclu X parce que Y » donne une impression de contrôle et de délibération. Une liste d'exclusions sans explication donne l'impression d'un périmètre dessiné pour éviter le travail, et c'est cette impression qui déclenche des questions complémentaires lors de l'audit. Une liste de contrôle de certification détaillée permet de confirmer que vous disposez de chaque document avant que l'auditeur ne le demande.
Ce que les erreurs de périmètre coûtent réellement aux équipes en pratique
Les déclarations de périmètre qui posent le plus de problèmes ne sont pas les moins bien rédigées. Ce sont celles rédigées en silo par un unique responsable sécurité qui n'a pas impliqué les personnes qui gèrent réellement les systèmes exclus. J'ai vu des périmètres réécrits deux fois lors d'audits de phase 1, parce qu'« exclut le traitement de la paie par un tiers » signifiait en réalité que des données de paie transitaient par une base de données partagée que l'équipe sécurité ignorait. Ce n'est pas un problème de rédaction. C'est un problème de découverte qui se manifeste comme un symptôme rédactionnel.
Le périmètre étroit au niveau du service tend à s'imposer pour la plupart des organisations, notamment les éditeurs SaaS qui se certifient pour satisfaire des clients entreprises plutôt qu'une obligation réglementaire. Un périmètre organisationnel large n'a de sens que si votre activité est réellement constituée d'une seule fonction, d'un seul système, d'une seule équipe. Sinon, vous auditez des départements qui augmentent les coûts sans réduire le risque réel de quiconque.
C'est dans la phase d'estimation, avant de s'engager sur une frontière, que les outils de préparation à la certification prouvent leur valeur. Modéliser comment un périmètre plus large modifie les heures d'audit, le nombre de mesures et le calendrier par rapport à une alternative plus étroite transforme le périmètre d'une approximation en une comparaison que vous pouvez réellement défendre devant la direction.
— Martin
Testez vos choix de périmètre avant de vous y engager
Tracer la ligne entre « dans le périmètre » et « hors périmètre » est autant une décision de coût qu'une décision de sécurité, et se tromper signifie le payer en heures d'audit ultérieurement. L'évaluation de préparation de l'ISMS Calculator modélise la façon dont différentes frontières de périmètre modifient votre effort de mise en œuvre, en fonction de la taille de l'entreprise, du secteur d'activité et du niveau de maturité actuel en matière de sécurité, afin que vous puissiez comparer un périmètre étroit au niveau du service à un périmètre organisationnel plus large avant d'écrire une seule phrase de la déclaration finale.
L'outil décompose le travail induit par le périmètre en une évaluation de la maturité domaine par domaine couvrant l'ensemble des quatre thèmes de mesures ISO/IEC 27001:2022, puis traduit ces frontières en un calendrier Gantt personnalisable que vous pouvez remettre à la personne chargée de piloter la mise en œuvre. Chaque estimation peut être sauvegardée et exportée en PDF, ce qui facilite le partage des hypothèses de périmètre avec un auditeur ou une équipe de direction avant de vous engager sur un calendrier de certification. Effectuez maintenant le diagnostic de préparation gratuit en deux minutes, testez quelques scénarios de périmètre et sauvegardez la comparaison avant votre prochaine réunion de planification.
Où trouver la norme elle-même et les ressources associées
Pour le libellé officiel des clauses, consultez directement ISO/IEC 27001 plutôt que de vous fier uniquement à des résumés. Pour approfondir la façon dont les décisions de périmètre se répercutent sur la sélection des mesures, le guide d'Ismscalculator sur les mesures de l'Annexe A explique comment les choix de frontières s'associent à des exigences de mesures spécifiques, et le guide de mise en œuvre pour les éditeurs SaaS et les entreprises technologiques détaille les décisions de périmétrage propres aux produits hébergés dans le cloud. Les équipes des secteurs réglementés qui traitent des données sensibles lors de fusions-acquisitions ou de revues fournisseurs pourront également trouver utile, comme contexte pour un périmétrage correct du traitement des données par des tiers, les pratiques de due diligence pour les SaaS de santé.
Sources
- How to Define Your ISO 27001 Scope and Write Your Scope Statement
- ISO 27001 Certification: Complete Guide
- ISO 27001 Implementation: Information Security Management System | ECOSIRE
- The benefits of the Statement of Applicability in ISMS projects
- ISMS Implementation: ISO 27001 Step by Step | ADVISORI