Le périmètre du SMSI (Système de Management de la Sécurité de l'Information) est la première décision stratégique de tout projet de certification ISO 27001. Défini par la clause 4.3 de la norme, il délimite précisément ce que couvre et ce qu'exclut votre certification : quelles entités, quels sites, quels processus, quels services et quelles technologies.

Un périmètre mal défini est l'une des causes les plus fréquentes d'échec ou de surcoût dans un projet ISO 27001. Trop large, il rend la certification coûteuse, complexe et difficile à maintenir. Trop restreint, il nuit à la crédibilité du certificat auprès des clients et donneurs d'ordre. Entre les deux, un périmètre juste, cohérent et défendable devant un auditeur externe.

Ce guide vous explique comment construire ce périmètre pas à pas, avec des exemples concrets et les erreurs à éviter.

Qu'est-ce que le périmètre SMSI en ISO 27001 ?

La clause 4.3 d'ISO 27001:2022 stipule que l'organisation doit "déterminer les limites et l'applicabilité du système de management de la sécurité de l'information afin d'en établir le périmètre". Cette détermination doit prendre en compte :

  • Les enjeux internes et externes (clause 4.1)
  • Les exigences des parties intéressées (clause 4.2)
  • Les interfaces et dépendances entre activités interne et activités externes à l'organisation

Le périmètre est formalisé dans un document de déclaration de périmètre (scope statement) qui sera l'un des premiers documents examinés lors de l'audit Stage 1 par l'organisme de certification. Ce document répond à la question : "Qu'est-ce qui est certifié ISO 27001 dans cette organisation ?"

Concrètement, le périmètre peut être défini selon plusieurs dimensions :

  • Organisationnelle : filiales, départements, équipes
  • Géographique : sièges, sites, agences, pays
  • Fonctionnelle : processus métiers, services, produits
  • Technologique : systèmes d'information, plateformes, services cloud

Les critères de définition du périmètre (clauses 4.1 → 4.3)

La définition du périmètre n'est pas arbitraire. Elle doit résulter d'une analyse méthodique du contexte organisationnel et des attentes des parties prenantes.

Clause 4.1 — Comprendre le contexte organisationnel

L'organisation doit identifier les facteurs internes et externes susceptibles d'influencer son SMSI. Facteurs internes : culture d'entreprise, gouvernance, structure organisationnelle, ressources disponibles, capacités technologiques, héritage des systèmes. Facteurs externes : réglementation sectorielle (DORA pour la finance, HDS pour la santé), exigences clients et donneurs d'ordre, paysage des menaces, dépendances fournisseurs.

Cette analyse détermine naturellement ce qui doit être dans le périmètre (ce qui est exposé, ce qui est réglementé, ce qui est critique) et ce qui peut en rester exclu.

Clause 4.2 — Comprendre les besoins des parties intéressées

Les parties intéressées qui ont des exigences liées à la sécurité de l'information influencent le périmètre : clients qui exigent la certification (B2B, marchés publics), régulateurs (ANSSI, ACPR, ARS), actionnaires, partenaires stratégiques, auditeurs financiers.

Si un client exige que son prestataire soit certifié ISO 27001 sur le service de traitement de ses données, ce service doit impérativement être dans le périmètre.

Clause 4.3 — Définir les frontières

En partant des analyses 4.1 et 4.2, l'organisation délimite les frontières du SMSI en répondant à ces questions :

  • Quelles unités organisationnelles traitent les informations les plus sensibles ?
  • Quels systèmes et plateformes hébergent, traitent ou transmettent ces informations ?
  • Quelles sont les interfaces avec des tiers (fournisseurs cloud, sous-traitants) ?
  • Quels processus génèrent ou consomment les informations critiques ?

Les types de périmètres courants

Il n'existe pas de périmètre universel. Selon la maturité, la taille et le secteur de l'organisation, plusieurs approches sont possibles.

Périmètre restreint — un service ou une fonction

L'organisation certifie uniquement un service ou département spécifique : par exemple, le service informatique, le service de traitement des paiements, ou l'équipe développement produit. Avantages : coût réduit, plus facile à maîtriser, permet de gagner en expérience avant d'étendre. Inconvénients : crédibilité limitée, les interfaces avec les autres départements doivent être soigneusement documentées.

Périmètre fonctionnel — un ou plusieurs processus

Le périmètre couvre un ou plusieurs processus métiers de bout en bout : par exemple, "la conception, le développement, l'hébergement et le support de la plateforme SaaS X pour les clients". Ce type de périmètre est très courant pour les ESN, les éditeurs logiciels et les opérateurs cloud. Il est naturellement aligné sur les exigences clients.

Périmètre étendu — toute l'organisation

L'ensemble de l'organisation est certifié. Ce périmètre est privilégié par les grandes entreprises, les ETI dont tout le métier est lié à l'information (cabinets de conseil, banques, assurances) et les organisations soumises à des réglementations sectorielles strictes. Avantages : cohérence globale, valeur marketing maximale. Inconvénients : coût élevé, mobilisation totale des équipes, durée de mise en œuvre plus longue.

Périmètre géographique — un ou plusieurs sites

La certification couvre un ou plusieurs sites géographiques. Utile pour les organisations multi-sites qui veulent certifier progressivement. L'extension à d'autres sites peut être planifiée dans la feuille de route SMSI.

Exemples de périmètres par secteur

PME tech / éditeur SaaS : "Le Système de Management de la Sécurité de l'Information couvre la conception, le développement, l'exploitation et le support de la plateforme [NomProduit], y compris les systèmes d'information associés hébergés sur AWS Europe (région eu-west-1), ainsi que les processus de gestion des incidents et de continuité associés. Siège social : [Ville]. Périmètre documentaire : toutes les équipes Produit, Engineering et Ops."

Cabinet d'expertise comptable : "Le SMSI couvre le traitement, le stockage et la transmission des données comptables et fiscales des clients, depuis la collecte des pièces justificatives jusqu'à la remise des liasses fiscales, incluant les processus de contrôle qualité. Périmètre géographique : bureau principal à [Ville]. Sont exclus : les activités de formation non liées aux données clients."

Industriel / OT : "Le SMSI couvre les systèmes d'information de gestion (ERP, CRM, messagerie d'entreprise) et les interfaces IT/OT du site de production de [Ville]. Les systèmes de contrôle industriel (SCADA, automates) sont exclus du périmètre SMSI mais leurs interfaces avec le réseau IT sont documentées et contrôlées." Pour les périmètres industriels, voir aussi notre guide sur le SMSI ISO 27001 industriel.

ESN / société de conseil : "Le SMSI couvre les activités de conseil en cybersécurité et de tests d'intrusion, y compris la gestion des données clients relatives aux missions, les environnements de test dédiés et les outils de reporting. Périmètre géographique : bureau de [Ville]. Hors périmètre : les activités de formation certifiante et de recrutement."

Les erreurs classiques dans la définition du périmètre

Erreur 1 — Périmètre trop large pour les ressources disponibles

Vouloir certifier "toute l'organisation" sans avoir les ressources pour maintenir le SMSI dans la durée est la première cause d'échec en audit de surveillance. Mieux vaut un périmètre restreint mais parfaitement maîtrisé qu'un périmètre étendu superficiellement traité.

Erreur 2 — Exclusions non justifiées

Exclure un département ou un système uniquement parce qu'il est "difficile à sécuriser" est une pratique que les auditeurs détectent immédiatement. Si un actif important traite des données sensibles, son exclusion doit être justifiée par des raisons valables (hors portée organisationnelle, interface maîtrisée) et non par sa résistance à la sécurisation.

Erreur 3 — Périmètre incohérent avec les interfaces

Un périmètre qui inclut un système de gestion clients mais exclut le système de messagerie par lequel transitent les données clients crée une incohérence flagrante. L'auditeur vérifiera systématiquement que les interfaces entre périmètre inclus et exclu sont maîtrisées.

Erreur 4 — Périmètre qui évolue sans être documenté

Une fusion-acquisition, le lancement d'un nouveau service SaaS ou un déménagement modifient le périmètre. Ces changements doivent être documentés et communiqués à l'organisme de certification avant l'audit de surveillance suivant.

Rédiger sa déclaration de périmètre (scope statement)

La déclaration de périmètre est un document court (1 à 2 pages) mais stratégique. Elle doit contenir les éléments suivants :

  1. Identification de l'organisation : raison sociale, forme juridique, siège
  2. Description du périmètre : processus, services, produits, systèmes couverts
  3. Périmètre géographique : sites inclus et exclus avec justification
  4. Périmètre organisationnel : entités, départements, équipes inclus
  5. Systèmes d'information inclus : liste des applications, infrastructures, services cloud dans le périmètre
  6. Exclusions et justifications : ce qui n'est pas couvert et pourquoi
  7. Interfaces avec l'extérieur du périmètre : comment les données traversent les frontières

Modèle de phrase type : "Le Système de Management de la Sécurité de l'Information de [Raison Sociale] couvre [description des processus/services], y compris [systèmes d'information associés], au sein de [périmètre géographique]. Les activités [X et Y] sont exclues du périmètre au motif de [justification]. Les interfaces entre les activités incluses et exclues sont gérées conformément à [référence de procédure]."

Périmètre et organismes de certification (Stage 1 Audit)

Lors de l'audit Stage 1, l'auditeur de l'organisme de certification (Bureau Veritas, BSI, LRQA, AFNOR Certification, Apave) examine en priorité la déclaration de périmètre pour vérifier :

  • La cohérence entre le périmètre et le contexte organisationnel (clause 4.1)
  • La prise en compte des exigences des parties prenantes pertinentes (clause 4.2)
  • La justification des exclusions
  • La maîtrise des interfaces entre périmètre inclus et exclu
  • La cohérence entre le périmètre et la Déclaration d'Applicabilité (SOA)

Un périmètre flou ou incohérent peut suffire à déclencher une non-conformité majeure dès le Stage 1, retardant le projet de certification de plusieurs mois.

Notre cabinet accompagne les organisations dans la définition rigoureuse de leur périmètre SMSI dans le cadre de nos missions d'accompagnement ISO 27001. Pour votre calendrier de certification, consultez notre Roadmap ISO 27001 PME en 9 mois et notre guide sur les coûts et étapes de la certification ISO 27001.

Pour la phase d'audit, préparez-vous avec notre méthode complète d'audit interne ISO 27001.

Périmètre ISO 27001 et sous-traitants (clause 4.2)

La définition du périmètre SMSI ne concerne pas uniquement votre organisation : la clause 4.2 d'ISO 27001:2022 impose d'identifier les parties intéressées et leurs exigences pertinentes, ce qui inclut vos fournisseurs et prestataires. Les contrôles A.5.19 à A.5.22 de l'Annexe A traitent spécifiquement de la sécurité dans la chaîne d'approvisionnement.

Quand inclure un sous-traitant dans le périmètre SMSI ?

Un sous-traitant doit être inclus (ou ses exigences de sécurité formalisées) dès lors qu'il traite des actifs informationnels classifiés Confidentiel ou Secret pour votre compte. Les cas les plus fréquents :

  • Hébergeur / cloud provider : AWS, Azure, GCP, OVHcloud. Ces fournisseurs ne sont pas "dans" votre périmètre mais leurs exigences de sécurité doivent être documentées (voir contrôle A.5.23). Leurs certifications ISO 27001 propres sont acceptées comme preuve.
  • MSSP (Managed Security Service Provider) : Un SOC externalisé qui accède à vos journaux d'événements et à vos systèmes est souvent dans le périmètre, ou fait l'objet d'une annexe dédiée dans votre SMSI.
  • ESN / prestataire de développement : S'ils ont accès à votre code source ou à votre base de données de production, leur accès et leurs pratiques de sécurité doivent être encadrés par des clauses contractuelles (A.5.20) et vérifiés régulièrement (A.5.22).

Clauses contractuelles de sécurité (A.5.20)

Pour chaque fournisseur critique, votre SMSI doit prévoir un contrat ou avenant de sécurité qui précise : exigences de confidentialité, procédures de notification d'incident, droit d'audit, conditions de retour des données en fin de contrat, et conformité aux réglementations applicables (RGPD, NIS 2 le cas échéant). L'absence de telles clauses est une non-conformité majeure fréquemment relevée lors des audits de certification.

Réduction du périmètre — risques et bonnes pratiques

La tentation de réduire le périmètre SMSI à un sous-ensemble de l'organisation est compréhensible : certification plus rapide, coût réduit, effort limité. Mais un périmètre cosmétique — volontairement étroit pour éviter les points difficiles — est l'une des erreurs les plus risquées d'un projet ISO 27001.

Comment les auditeurs évaluent la cohérence du périmètre

Les auditeurs de certification (Bureau Veritas, BSI, AFNOR, LRQA) sont formés pour détecter les périmètres artificiellement restreints. Leurs vérifications habituelles :

  • Cohérence physique et logique : Si votre périmètre couvre la "Direction des Systèmes d'Information" mais que les serveurs sont hébergés dans un datacenter opéré par une autre direction exclue, l'auditeur questionnera la réalité du périmètre.
  • Flux d'information : Toute donnée qui entre ou sort du périmètre doit être contrôlée. Un périmètre restreint avec de nombreux flux non maîtrisés vers l'extérieur est un signal d'alarme.
  • Parties prenantes : Si vos clients ou régulateurs exigent une certification sur l'ensemble de votre SI, un périmètre restreint sera rejeté comme insuffisant.

Exclusions justifiées : ce qui est acceptable

Exclure certains éléments du périmètre est parfaitement légitime, à condition de pouvoir justifier que ces exclusions n'affectent pas la capacité de l'organisation à répondre aux exigences de conformité. Les exclusions courantes acceptées par les auditeurs :

  • Une filiale étrangère récemment acquise, avec un plan d'intégration SMSI défini dans les 12 à 18 mois
  • Un site de taille très réduite sans traitement de données sensibles
  • Des systèmes industriels (OT/SCADA) faisant l'objet d'une démarche IEC 62443 séparée

Dans tous les cas, les exclusions doivent être documentées dans le scope statement avec leur justification formelle.

Évolution du périmètre post-certification

Obtenir la certification ISO 27001 n'est pas la fin du voyage. Le périmètre SMSI est un élément vivant qui doit évoluer avec l'organisation. La clause 10.2 (amélioration continue) et les audits de surveillance annuels encadrent cette évolution.

Audit de surveillance vs recertification : quelle procédure ?

Les certificats ISO 27001 sont valables 3 ans, avec des audits de surveillance chaque année. La procédure en cas de modification du périmètre dépend de l'importance du changement :

  • Modification mineure (ajout d'un site secondaire, extension à une équipe) : notification à l'organisme de certification, traitement lors de l'audit de surveillance suivant
  • Modification majeure (fusion-acquisition, changement d'activité principal, réduction significative) : audit de certification complet requis sur la nouvelle portée
  • Réduction temporaire (cession d'une filiale) : notification immédiate, possible mise à jour du certificat avec nouvelle portée

Impact sur le Plan de Traitement des Risques

Toute modification du périmètre déclenche une réévaluation partielle des risques (clause 6.1). Si vous ajoutez un nouveau site ou une nouvelle activité, les actifs correspondants doivent être intégrés dans votre registre d'actifs, les risques identifiés et traités. Cette réévaluation doit être documentée et présentée à la prochaine revue de direction (clause 9.3).

Consultez notre guide sur le Plan de Traitement des Risques ISO 27001 pour les modèles et méthodes de réévaluation.

Périmètre SMSI et directive NIS 2

La directive européenne NIS 2 impose des exigences de sécurité renforcées aux entités "essentielles" et "importantes" dans les secteurs critiques (énergie, santé, transport, numérique). Il existe un lien fort entre la définition du périmètre SMSI ISO 27001 et la notion de systèmes d'information essentiels (SIE) de NIS 2.

Pour les organisations soumises à NIS 2, le périmètre SMSI devrait idéalement couvrir au minimum les systèmes d'information supportant les services essentiels ou importants identifiés dans le cadre NIS 2. Cet alignement évite la complexité de gérer deux référentiels avec des périmètres différents et simplifie les audits réglementaires.

Concrètement, l'analyse d'impact NIS 2 (identification des services essentiels et de leurs dépendances SI) peut servir de base à votre définition de périmètre SMSI : les systèmes qui supportent vos services essentiels ont vocation à être couverts par votre SMSI. Notre guide NIS 2 vs ISO 27001 : différences et complémentarités détaille les synergies opérationnelles entre les deux référentiels.

Cette convergence représente un argument commercial fort : une organisation certifiée ISO 27001 avec un périmètre couvrant ses SIE NIS 2 peut démontrer sa conformité à deux référentiels en un seul effort d'audit, réduisant le coût de mise en conformité globale.

À retenir

  • ✓ Le périmètre SMSI (clause 4.3) est le premier document examiné lors de l'audit Stage 1 de certification.
  • ✓ Sa définition doit résulter des analyses contextuelles (clause 4.1) et des exigences parties prenantes (clause 4.2).
  • ✓ Toute exclusion doit être justifiée — exclure ce qui est difficile à sécuriser est une non-conformité potentielle.
  • ✓ Un périmètre fonctionnel (par processus ou service) est souvent plus adapté aux PME qu'un périmètre géographique.

FAQ — Périmètre de certification ISO 27001

Qu'est-ce que le périmètre SMSI en ISO 27001 ?

Le périmètre SMSI (clause 4.3) définit les frontières et l'applicabilité du Système de Management de la Sécurité de l'Information. Il précise quelles parties de l'organisation, quels sites géographiques, quels processus et quels systèmes sont couverts par la certification. C'est le premier document examiné lors de l'audit Stage 1.

Peut-on exclure certains services ou sites du périmètre ISO 27001 ?

Oui, des exclusions sont possibles à condition d'être justifiées et de ne pas compromettre l'atteinte des objectifs de sécurité. L'organisation doit démontrer que les interfaces entre activités incluses et exclues sont maîtrisées et ne créent pas de failles dans le SMSI certifié.

Comment définir le périmètre ISO 27001 pour une PME ?

Pour une PME, le plus pratique est de partir des activités traitant les informations les plus sensibles et de construire le périmètre autour d'elles. Un périmètre fonctionnel ('service de développement logiciel et support client') est souvent plus adapté qu'un périmètre géographique pour une PME avec peu de sites.

Quelle est la différence entre périmètre SMSI et périmètre d'audit ISO 27001 ?

Le périmètre SMSI est défini par l'organisation et couvre tout ce qui est sous son contrôle dans le cadre du système de management. Le périmètre d'audit est ce que l'organisme de certification va effectivement examiner. En pratique ils coïncident, sauf accord contraire explicite.

Peut-on modifier le périmètre ISO 27001 après la certification ?

Oui. Le périmètre peut être modifié lors des audits de surveillance annuels ou de renouvellement (tous les 3 ans). Une extension peut faire l'objet d'un audit spécifique. Une réduction doit être justifiée et ne doit pas constituer une tentative d'exclure des zones à problèmes.