Document de Périmètre SMSI ISO 27001 : Modèle Word [Clause 4.3]

Le document de périmètre SMSI — aussi appelé Statement of Scope — est le premier document fondateur de tout Système de Management de la Sécurité de l'Information certifiable selon ISO/IEC 27001:2022. Exigé par la clause 4.3 — Détermination du domaine d'application du système de management de la sécurité de l'information, il délimite avec précision ce qui est inclus dans le SMSI et ce qui en est exclu. Cette délimitation n'est pas un exercice purement formel : c'est une décision stratégique qui conditionne l'ensemble de la démarche de certification. Un périmètre trop large rend la certification impossible à tenir dans les délais et le budget. Un périmètre trop étroit peut sembler artificiel et être remis en cause par les auditeurs si des activités critiques en sont exclues sans justification valable. Le document de périmètre est systématiquement le premier document examiné lors de l'audit de Stage 1 — c'est sur lui que l'auditeur base sa planification du Stage 2. Il doit définir les activités, les processus, les entités organisationnelles, les sites géographiques, et les technologies inclus dans le SMSI, les interfaces et dépendances avec des entités externes au périmètre, et la justification de toute exclusion. Ce modèle Word, développé par Ayi NEDJIMI, consultant cybersécurité Lead Implementer ISO 27001, couvre l'ensemble des dimensions requises pour un Statement of Scope conforme : description de l'organisation, contexte interne et externe (lien avec les clauses 4.1 et 4.2), périmètre géographique et organisationnel, actifs et technologies inclus, interfaces et dépendances, et critères d'exclusion justifiés. Il doit être lu en parallèle avec notre template d'analyse de contexte (clauses 4.1/4.2) qui fournit les informations nécessaires à la définition du périmètre.

Contexte réglementaire et normatif

La clause 4.3 d'ISO/IEC 27001:2022 stipule que l'organisation doit déterminer les frontières et l'applicabilité du SMSI pour en établir le domaine d'application, en prenant en compte les enjeux externes et internes identifiés à la clause 4.1, les exigences des parties intéressées de la clause 4.2, et les interfaces et dépendances entre les activités de l'organisation et celles d'autres organisations. Le domaine d'application doit être disponible sous forme d'information documentée.

La version 2022 renforce l'exigence de considérer les interfaces et dépendances — ce qui signifie que même si une activité est hors périmètre, ses interactions avec les systèmes dans le périmètre doivent être documentées et les risques associés traités.

• ISO/IEC 27003:2017 (Guide d'implémentation ISO 27001) : fournit des lignes directrices détaillées pour déterminer le périmètre SMSI, avec exemples de facteurs à prendre en compte et méthodes de délimitation.
• Directive NIS 2 : pour les entités soumises à NIS 2, le périmètre de leur SMSI ISO 27001 doit couvrir au minimum les services qualifiés d'essentiels ou importants. Un périmètre trop restreint pourrait ne pas répondre aux obligations NIS 2. Voir notre article sur la conformité NIS 2.
• RGPD : le périmètre SMSI doit être cohérent avec les traitements de données personnelles soumis au RGPD. Les systèmes traitant des données personnelles sensibles doivent généralement être inclus dans le SMSI.
• Référentiels sectoriels : dans les secteurs financier (DSP2, DORA), santé (HDS), ou défense (II 901), le périmètre SMSI peut être partiellement imposé par les régulateurs sectoriels.

Structure détaillée du template

Section 1 — Présentation de l'organisation

Description synthétique de l'organisation : raison sociale, secteur d'activité, taille (effectif, chiffre d'affaires), structure juridique (groupe, filiales, entités liées), localisation géographique des sites. Cette section contextualise le périmètre pour l'auditeur qui découvre l'organisation lors du Stage 1.

Section 2 — Enjeux internes et externes pertinents

Synthèse des enjeux identifiés à la clause 4.1 qui influencent la définition du périmètre : maturité en sécurité, culture d'entreprise, contraintes techniques, réglementations applicables, pression concurrentielle, menaces sectorielles. Cette section démontre que le périmètre est défini sur la base d'une analyse contextuelle et non arbitrairement.

Section 3 — Parties intéressées et leurs exigences

Liste des parties prenantes concernées par le périmètre SMSI : clients (exigences contractuelles de sécurité), actionnaires (appétit pour le risque), régulateurs (obligations légales), partenaires (exigences de sécurité dans les accords), employés (attentes en matière de protection des données). Cette section justifie l'étendue du périmètre par les exigences des parties prenantes.

Section 4 — Délimitation du périmètre

Cœur du document. Description précise du périmètre selon quatre dimensions : Organisationnelle (quels départements, équipes, fonctions sont inclus), Géographique (quels sites, bâtiments, espaces sont inclus), Processus et activités (quels processus métier sont couverts par le SMSI), Technologies et systèmes (quels systèmes d'information, applications, infrastructures sont dans le périmètre). Pour chaque dimension, les éléments inclus et exclus sont listés explicitement.

Section 5 — Interfaces et dépendances

Documentation des interfaces entre le périmètre SMSI et les éléments externes : systèmes d'un prestataire qui traitent des données du périmètre, réseaux partagés avec des entités hors périmètre, services cloud utilisés par des systèmes dans le périmètre. Pour chaque interface : description, données échangées, contrôles de sécurité applicables, responsabilités.

Section 6 — Justification des exclusions

Pour chaque élément explicitement exclu du périmètre, justification claire et documentée. Les exclusions admissibles sont celles qui ne présentent pas de risques significatifs pour la sécurité des éléments inclus dans le périmètre. Une filiale à l'étranger non connectée au SI principal peut être exclue avec justification. En revanche, exclure un département qui traite des données très sensibles sera difficile à justifier.

Guide d'utilisation étape par étape

Étape 1 — Réaliser l'analyse de contexte préalable

Le périmètre ne peut pas être défini sans l'analyse de contexte (clauses 4.1 et 4.2). Commencez par compléter le template d'analyse de contexte — les enjeux internes/externes et les exigences des parties prenantes qu'il documente sont les inputs directs de la définition du périmètre.

Étape 2 — Identifier toutes les activités candidates

Listez toutes les activités, processus, systèmes et sites de l'organisation. Pour chacun, évaluez sa pertinence pour inclusion dans le SMSI selon trois critères : criticité informationnelle (traite-t-il des informations sensibles ?), exposition aux risques (est-il exposé à des menaces significatives ?), exigences parties prenantes (des clients ou régulateurs en imposent-ils l'inclusion ?).

Étape 3 — Délibérer sur les inclusions et exclusions

Réunissez la direction, le RSSI et les responsables métier pour délibérer sur le périmètre. La décision doit être formalisée dans un compte rendu. Évitez deux extrêmes : le périmètre "tout l'entreprise" qui est souvent irréaliste pour une première certification, et le périmètre "artificiel" qui exclut des éléments critiques sans justification valable.

Étape 4 — Documenter les interfaces et dépendances

Pour chaque élément hors périmètre qui interagit avec des éléments dans le périmètre, documentez la nature de l'interaction, les données échangées, et les contrôles qui assurent que la sécurité du périmètre n'est pas compromise. Cette étape est souvent oubliée mais est explicitement exigée par la clause 4.3.

Étape 5 — Valider et approuver le document

Le document de périmètre doit être validé formellement par la direction générale. Cette validation est symboliquement importante : elle marque l'engagement de la direction dans la démarche de certification et fixe le cadre de toute la suite du projet SMSI.

Étape 6 — Communiquer le périmètre aux parties prenantes concernées

Selon le plan de communication SMSI (clause 7.4), communiquez le périmètre du SMSI aux parties prenantes concernées : clients qui avaient demandé la certification, régulateurs, partenaires. La certification elle-même publiera le périmètre dans le certificat délivré.

Étape 7 — Réviser si nécessaire

Le périmètre doit être révisé si l'organisation connaît des changements significatifs : acquisition d'une nouvelle entité, ouverture d'un nouveau site, lancement d'une nouvelle activité majeure, modification de la structure organisationnelle. Toute révision du périmètre peut avoir des impacts sur l'ensemble du SMSI (registre des risques, SoA, politiques) et doit être gérée soigneusement.

Tableau des contrôles / checklist complète

Checklist de 28 points de contrôle pour valider la conformité du document de périmètre :

Points de vigilance pour l'audit de certification

Piège 1 — Périmètre trop vague ou générique

"Le SMSI couvre l'ensemble des activités informatiques de l'entreprise" est une formulation insuffisante. L'auditeur demande une description précise : quels sites, quels processus, quels systèmes. Remédiation : listez explicitement les éléments inclus plutôt que d'utiliser des formulations englobantes qui peuvent couvrir plus ou moins que prévu.

Piège 2 — Exclusions non justifiées ou mal justifiées

Exclure une filiale qui partage le même réseau que les entités dans le périmètre, ou un département qui accède aux mêmes bases de données, crée des incohérences flagrantes. L'auditeur questionnera toute exclusion qui compromet la sécurité du périmètre inclus. Remédiation : assurez-vous que les exclusions sont véritablement isolées ou que les interfaces avec le périmètre sont documentées et sécurisées.

Piège 3 — Incohérence avec l'inventaire des actifs

Si le périmètre SMSI inclut "le système de facturation" mais que l'inventaire des actifs ne liste pas les serveurs qui hébergent cette application, il y a une incohérence. Les auditeurs recoupent systématiquement le périmètre avec l'inventaire des actifs. Remédiation : vérifiez que tous les systèmes mentionnés dans le périmètre sont présents dans l'inventaire des actifs.

Piège 4 — Interfaces non documentées

L'exigence de documenter les interfaces et dépendances (clause 4.3c) est souvent oubliée. Si un prestataire d'hébergement gère des serveurs dans le périmètre, ou si une filiale hors périmètre partage des données avec des entités dans le périmètre, ces interfaces doivent être documentées. Remédiation : réalisez un inventaire systématique des flux de données et d'administration entre le périmètre et l'extérieur.

Piège 5 — Périmètre modifié sans mise à jour du document

Un rachat, une ouverture de bureau, un changement de prestataire d'hébergement peuvent modifier le périmètre réel sans que le document soit mis à jour. L'auditeur de surveillance (année 1 et 2) ou de recertification (année 3) identifiera l'écart. Remédiation : intégrez la révision du périmètre dans le processus de gestion des changements.

Intégration dans le SMSI

Le document de périmètre est le point d'ancrage de l'ensemble du SMSI :

• En entrée — Analyse de contexte (4.1/4.2) : les enjeux et les exigences des parties prenantes déterminent le périmètre.
• En sortie — Inventaire des actifs (A.5.9) : le périmètre définit les actifs à recenser.
• En sortie — Registre des risques (6.1.2) : seuls les actifs dans le périmètre font l'objet de l'analyse de risques.
• En sortie — Statement of Applicability : le SoA liste les contrôles Annexe A applicables dans le périmètre défini.
• En sortie — Toutes les politiques SMSI : leur champ d'application correspond au périmètre SMSI.

Bonnes pratiques terrain

Commencez par un périmètre limité mais solide : pour une première certification, mieux vaut un périmètre restreint mais parfaitement maîtrisé qu'un périmètre large avec des zones grises. Une fois le SMSI rodé, l'extension du périmètre est possible lors des cycles de recertification.

Alignez le périmètre avec les exigences clients : si votre certification est motivée par une exigence client (grands comptes, secteur public), vérifiez que votre périmètre couvre bien les activités concernées par la relation commerciale. Un périmètre qui n'inclut pas les activités pour lesquelles la certification est requise sera rejeté par le client.

Formalisez la décision de périmètre dans un PV de réunion : la délibération sur le périmètre doit être documentée. Un PV de réunion de direction approuvant le périmètre est une preuve d'engagement de la direction (clause 5.1) et de prise de décision structurée.

Anticipez les évolutions : rédigez le périmètre de manière à permettre son extension future sans avoir à réécrire entièrement le document. Utilisez des formulations qui incluent les critères d'inclusion plutôt que des listes exhaustives d'éléments, ce qui facilite l'ajout de nouveaux éléments répondant aux mêmes critères.

FAQ

Une PME peut-elle limiter son périmètre à un seul processus ou département ?

Oui, techniquement. ISO 27001 n'impose pas un périmètre minimum. Certaines organisations certifient uniquement leur centre de données, leur département R&D, ou leurs activités de traitement de paiements. Cependant, un périmètre très restreint présente des risques : il peut paraître artificiel si les activités exclues partagent des systèmes ou des données avec le périmètre inclus, il peut ne pas répondre aux exigences clients si ceux-ci attendent une certification couvrant les activités qui les concernent directement, et l'extension ultérieure du périmètre peut générer des écarts documentaires importants. En pratique, pour une PME, le périmètre couvre généralement l'intégralité du système d'information et de la direction informatique, avec éventuellement des exclusions géographiques (site secondaire non connecté) ou organisationnelles (filiale autonome).

Comment gérer le cas d'un groupe avec plusieurs filiales ?

Pour un groupe avec plusieurs filiales, trois approches sont possibles : certification unique couvrant toutes les entités du groupe (périmètre étendu, une seule certification, économies d'échelle mais complexité opérationnelle plus grande), certifications séparées par entité (chaque filiale gère son SMSI et sa certification, plus de flexibilité mais coûts démultipliés), certification de la holding avec périmètre incluant les filiales critiques. Le choix dépend de la maturité des filiales, de la structure du groupe (SI commun ou non), et des exigences des clients et régulateurs. L'auditeur examinera scrupuleusement que le périmètre couvre bien toutes les entités mentionnées et que les contrôles s'y appliquent effectivement. Une filiale dans le périmètre mais non auditée est une non-conformité potentielle.

Peut-on exclure des services cloud du périmètre SMSI ?

C'est une question complexe avec l'usage massif du cloud. Si des services SaaS, IaaS ou PaaS traitent des données ou exécutent des processus qui seraient autrement dans le périmètre SMSI, leur exclusion est difficile à justifier. La clause 4.3c impose de documenter les interfaces et dépendances — un service cloud qui stocke vos données critiques est une dépendance majeure que vous ne pouvez pas ignorer. En pratique, les services cloud dans le périmètre signifient que vous devez vérifier que vos fournisseurs cloud respectent des exigences de sécurité adéquates (A.5.23), pas nécessairement qu'ils doivent être certifiés ISO 27001 eux-mêmes. La politique de services cloud est le document qui définit comment vous gérez ces risques. Consultez notre template de politique services cloud (A.5.23) pour les exigences détaillées.

Que se passe-t-il si le périmètre change en cours de certification ?

Un changement de périmètre en cours de processus de certification (après le Stage 1 mais avant le Stage 2) doit être notifié immédiatement à l'organisme de certification. Selon l'ampleur du changement, l'auditeur peut décider de reporter le Stage 2, de réviser son plan d'audit, ou de réaliser un Stage 1 partiel sur le nouveau périmètre. Dans tous les cas, la documentation SMSI (périmètre, inventaire, registre des risques, politiques) doit être mise à jour avant le Stage 2. Évitez les changements de périmètre majeurs dans les 3 mois précédant un audit Stage 2 — ils génèrent systématiquement des incertitudes documentaires difficiles à résoudre rapidement.

La définition précise du périmètre SMSI conditionne directement la portée de la certification ISO 27001 et l'efficacité des mesures de sécurité déployées. Un périmètre trop large complexifie la gestion et augmente les coûts de conformité, tandis qu'un périmètre trop restreint expose l'organisation à des risques non couverts. La clause 4.3 exige que les interfaces et dépendances avec les entités hors périmètre soient explicitement documentées, notamment pour les fournisseurs critiques, les systèmes d'information partagés et les accès tiers aux données sensibles de l'organisation certifiée.