Définir le périmètre d’une certification ISO 27001 est l’une des décisions les plus structurantes d’un projet de sécurité de l’information. Trop large, il peut devenir lourd à piloter ; trop étroit, il risque de perdre en crédibilité. L’enjeu consiste à tracer des frontières claires, cohérentes et défendables pour construire un système de management de la sécurité de l’information réellement adapté à l’organisation.
Pourquoi le périmètre ISO 27001 est une étape décisive
Le périmètre d’une certification ISO 27001 définit ce qui est inclus dans le SMSI : activités, sites, équipes, applications, infrastructures, données, prestataires et processus concernés. Il ne s’agit pas d’un simple découpage administratif. C’est le cadre officiel dans lequel l’organisation démontre sa capacité à gérer les risques liés à la sécurité de l’information.
Un périmètre bien défini facilite l’analyse des risques, la mise en œuvre des mesures de sécurité, la production des preuves d’audit et la compréhension du certificat par les clients, partenaires ou autorités. À l’inverse, un périmètre flou crée des ambiguïtés : qui est responsable ? quels actifs sont couverts ? quelles interfaces doivent être maîtrisées ? Ces questions sont centrales lors d’un audit de certification ISO 27001.
La norme ISO/IEC 27001 demande à l’organisation de déterminer les limites et l’applicabilité du SMSI en tenant compte du contexte interne et externe, des parties intéressées et des interfaces avec d’autres activités. Le périmètre doit donc être justifié, documenté et compatible avec la réalité opérationnelle.
Partir du contexte de l’organisation
Avant de dessiner les frontières du périmètre, il faut comprendre l’environnement dans lequel l’organisation évolue. Cela implique d’identifier ses enjeux métiers, ses obligations réglementaires, ses engagements contractuels, ses contraintes techniques et son exposition aux menaces. Une entreprise qui héberge des données de santé, par exemple, ne fera pas les mêmes choix qu’un éditeur de logiciels B2B ou qu’un service support interne.
Cette analyse du contexte permet de relier la certification à des objectifs concrets : sécuriser une offre SaaS, rassurer des clients grands comptes, répondre à un appel d’offres, renforcer la gouvernance IT ou protéger des informations sensibles. Le périmètre doit refléter ces priorités, sans chercher à certifier artificiellement toute l’entreprise si cela n’est ni nécessaire ni maîtrisable.
Il est également important d’identifier les parties intéressées : clients, collaborateurs, actionnaires, régulateurs, fournisseurs, assureurs, partenaires technologiques. Leurs attentes peuvent influencer directement le choix du périmètre. Un client stratégique peut exiger que l’activité de support soit incluse, tandis qu’un régulateur peut porter une attention particulière aux traitements de données personnelles.
Identifier les activités, processus et actifs concernés
Un périmètre ISO 27001 doit être construit autour des activités qui manipulent, stockent, transmettent ou protègent l’information. La question de départ est simple : quelles activités doivent être couvertes pour que la certification ait du sens ? La réponse suppose de cartographier les processus métiers, les services internes, les applications, les bases de données, les environnements cloud et les équipements critiques.
Il ne suffit pas d’écrire que le périmètre concerne “le système d’information”. Cette formulation est souvent trop vague. Il faut préciser les activités couvertes, par exemple : développement et exploitation d’une plateforme SaaS, hébergement d’applications clients, gestion du support technique, administration des infrastructures ou traitement de données financières. Cette précision rend le périmètre auditable et compréhensible.
Les actifs doivent ensuite être rattachés à ces activités : serveurs, postes de travail, outils collaboratifs, comptes administrateurs, dépôts de code, sauvegardes, locaux, contrats fournisseurs, documentation, procédures et compétences clés. Cette étape alimente l’analyse de risques et prépare la sélection des mesures de sécurité de l’annexe A de la norme.
Définir des frontières claires et cohérentes
La difficulté principale consiste à fixer des limites qui correspondent à la réalité. Un périmètre peut être défini par entité juridique, site géographique, activité métier, produit, service, département ou environnement technique. Le bon choix dépend de la structure de l’organisation et des objectifs de certification.
Dans une entreprise multisite, il peut être pertinent de commencer par un siège social et un centre d’exploitation, puis d’élargir progressivement. Dans une société technologique, le périmètre peut couvrir une plateforme spécifique, son équipe de développement, son exploitation et son support. Pour une direction informatique interne, il peut inclure les services fournis aux métiers, comme la gestion des accès, l’infrastructure réseau et les postes utilisateurs.
Les frontières doivent aussi intégrer les dépendances. Si une activité certifiée dépend fortement d’un service non inclus, cette interface doit être maîtrisée. Par exemple, une application certifiée hébergée sur une infrastructure interne exclue du périmètre créerait une incohérence si les responsabilités ne sont pas clairement établies. La notion de frontière du SMSI ne doit jamais masquer un risque réel.
Ce qu’il faut inclure dans la description du périmètre
La description du périmètre doit être suffisamment précise pour être comprise par un auditeur, un client ou un responsable interne. Elle doit éviter les formulations trop marketing et s’appuyer sur des éléments vérifiables. Une bonne description mentionne généralement les activités couvertes, les sites concernés, les systèmes inclus, les catégories d’informations traitées et les exclusions justifiées.
- Les activités métier incluses, comme le développement, l’exploitation, le support ou l’hébergement.
- Les sites physiques, environnements cloud, réseaux ou infrastructures concernés par le SMSI.
- Les équipes, rôles et responsabilités impliqués dans la gestion de la sécurité.
- Les types de données protégées : données clients, données personnelles, informations contractuelles, secrets d’affaires.
- Les principales interfaces avec des prestataires, filiales, services mutualisés ou partenaires techniques.
- Les exclusions éventuelles, accompagnées d’une justification claire et documentée.
Cette description doit rester stable pendant l’audit, mais elle peut évoluer dans le temps. Une organisation peut commencer avec un périmètre maîtrisé, puis l’étendre lors d’un cycle ultérieur. Cette approche progressive est fréquente, à condition que le périmètre initial reste pertinent et ne donne pas une image trompeuse de la couverture réelle.
Gérer les exclusions sans fragiliser la certification
Exclure une activité, un site ou un système n’est pas interdit. En revanche, l’exclusion doit être cohérente, transparente et justifiable. Une exclusion devient problématique lorsqu’elle retire du périmètre un élément indispensable à l’activité certifiée ou lorsqu’elle empêche de traiter un risque significatif.
Par exemple, une entreprise peut exclure son service commercial si la certification vise uniquement une plateforme d’hébergement technique. Mais si ce service gère les contrats clients, les accès aux environnements ou des informations sensibles liées à l’activité certifiée, l’exclusion devra être encadrée. Les interfaces, les responsabilités et les flux d’informations devront être décrits.
La logique est la même pour les prestataires. Le fait d’externaliser l’hébergement, la maintenance ou le support ne supprime pas la responsabilité de l’organisation certifiée. Les fournisseurs critiques doivent être intégrés à l’analyse de risques, aux exigences contractuelles et aux mécanismes de surveillance. La maîtrise des tiers fait partie des attentes fortes d’un SMSI conforme à ISO 27001.
Relier le périmètre à l’analyse de risques
Le périmètre et l’analyse de risques sont indissociables. Une fois les frontières définies, l’organisation doit identifier les risques qui pèsent sur les actifs inclus : perte de disponibilité, fuite d’informations, altération de données, usurpation de comptes, mauvaise configuration cloud, défaillance fournisseur ou erreur humaine.
Un périmètre trop large peut produire une analyse de risques interminable et difficile à maintenir. Un périmètre trop restreint peut, au contraire, laisser de côté des dépendances essentielles. L’objectif est de choisir un périmètre suffisamment représentatif pour couvrir les risques réellement importants, tout en restant pilotable avec les ressources disponibles.
Les résultats de l’analyse de risques servent ensuite à établir le plan de traitement et la déclaration d’applicabilité, souvent appelée SoA. Ce document indique quelles mesures de sécurité sont retenues, lesquelles ne le sont pas et pourquoi. La cohérence entre le périmètre, les risques et les mesures est un point d’attention majeur lors de l’audit.
Impliquer la direction et les responsables opérationnels
La définition du périmètre ne doit pas être un exercice isolé mené uniquement par l’équipe sécurité. Elle engage l’organisation dans son ensemble. La direction doit valider les objectifs, les ressources, les priorités et le niveau de risque acceptable. Les responsables opérationnels doivent confirmer que les processus décrits correspondent à la réalité du terrain.
Cette implication évite les périmètres théoriques, conçus pour paraître simples mais difficiles à défendre en audit. Elle permet aussi d’anticiper les impacts : mise à jour des procédures, formation des équipes, gestion des preuves, contrôle des accès, suivi des incidents, revues de fournisseurs et indicateurs de performance.
Dans les systèmes de management, la gouvernance joue un rôle central. La logique de revue périodique par la direction, bien connue dans d’autres référentiels, illustre l’importance d’un pilotage régulier des objectifs, des risques et des décisions structurantes. Pour ISO 27001, cette discipline contribue à maintenir un périmètre pertinent dans la durée.
Préparer la lecture du périmètre par l’auditeur
Lors de l’audit, l’auditeur vérifie que le périmètre est défini, documenté, communiqué et cohérent avec les activités observées. Il cherchera à comprendre ce qui est inclus, ce qui ne l’est pas, et comment les interfaces sont maîtrisées. Il analysera également si les exigences de la norme s’appliquent correctement dans le cadre retenu.
La description du périmètre doit donc être alignée avec les preuves disponibles : cartographie des actifs, organigramme, procédures, contrats, inventaires, résultats d’analyse de risques, plans d’action, indicateurs et enregistrements d’incidents. Un écart entre le périmètre annoncé et les pratiques réelles peut fragiliser la certification.
Le choix de l’organisme certificateur a aussi son importance, notamment pour la reconnaissance du certificat par le marché. Comprendre le rôle d’un organisme certificateur accrédité aide à situer les exigences d’indépendance, de compétence et de confiance associées au processus de certification.
Faire évoluer le périmètre après la certification
Un périmètre ISO 27001 n’est pas figé. Les organisations changent : nouveaux produits, acquisitions, migration cloud, ouverture de sites, externalisation, réorganisation d’équipes, nouvelles obligations réglementaires. Chaque évolution significative doit conduire à réexaminer les limites du SMSI et les risques associés.
Cette révision peut avoir lieu lors des audits internes, des revues de direction, des changements majeurs ou de la préparation des audits de surveillance. L’objectif n’est pas de modifier le périmètre en permanence, mais de s’assurer qu’il reste fidèle aux activités réellement couvertes. Une certification crédible repose sur un périmètre vivant, maîtrisé et transparent.
Pour bien définir le périmètre d’une certification ISO 27001, il faut donc combiner pragmatisme et rigueur. Le bon périmètre est celui qui protège les informations critiques, répond aux attentes des parties intéressées, reste exploitable par les équipes et peut être démontré par des preuves solides. C’est moins une question de taille qu’une question de cohérence.
