Définir le périmètre d’une certification ISO 27001 est l’une des premières décisions structurantes d’un projet de sécurité de l’information. Ce choix détermine ce qui sera audité, protégé, documenté et amélioré dans le cadre du système de management de la sécurité de l’information, ou SMSI. Mal cadré, le périmètre peut rendre la certification confuse, trop coûteuse ou difficile à défendre face à un auditeur.
Le périmètre d’une certification ISO 27001 désigne les limites exactes du SMSI. Il précise les activités, sites, équipes, applications, infrastructures, données et services couverts par la démarche. Autrement dit, il répond à une question simple : qu’est-ce qui est inclus dans la certification, et qu’est-ce qui ne l’est pas ?
Ce périmètre n’est pas seulement administratif. Il conditionne l’analyse des risques, le choix des mesures de sécurité, les responsabilités internes, les preuves à fournir et le contenu de l’audit. Un périmètre trop large peut rendre le projet difficile à piloter. À l’inverse, un périmètre trop restreint peut être jugé artificiel si des dépendances critiques sont exclues sans justification solide.
La norme ISO/IEC 27001 demande à l’organisation de tenir compte de son contexte, de ses parties intéressées et de ses interfaces internes et externes. Cette exigence implique une vision réaliste de l’entreprise, de ses flux d’information et de ses dépendances. Le périmètre doit donc être cohérent, documenté et défendable.
La définition du périmètre commence par l’analyse du contexte. Il s’agit d’identifier les enjeux internes et externes qui influencent la sécurité de l’information : exigences clients, contraintes réglementaires, organisation des activités, maturité informatique, localisation des équipes, dépendance à des prestataires ou sensibilité des données traitées.
Une entreprise SaaS qui héberge des données clients n’aura pas le même périmètre pertinent qu’un cabinet de conseil, une usine ou une collectivité. Dans certains cas, la certification vise un produit, une plateforme ou un service précis. Dans d’autres, elle couvre l’ensemble de l’organisation. La bonne approche consiste à relier le périmètre à la finalité métier de la certification.
Cette étape doit aussi intégrer les attentes des parties intéressées : clients grands comptes, autorités de régulation, partenaires, assureurs, actionnaires ou direction générale. Si la certification est exigée dans un appel d’offres, le périmètre doit correspondre aux services réellement concernés. Un écart entre la promesse commerciale et le périmètre certifié peut créer une ambiguïté préjudiciable.
Pour délimiter correctement le périmètre, il faut comprendre où se trouvent les informations sensibles, comment elles circulent et qui les utilise. Cela suppose de cartographier les actifs d’information : bases de données, applications, serveurs, postes de travail, documents contractuels, outils collaboratifs, environnements cloud, archives ou supports physiques.
Les processus métier sont également déterminants. Une activité de support client, par exemple, peut manipuler des données personnelles, des historiques d’incidents ou des informations contractuelles. Même si elle n’est pas au cœur du produit certifié, elle peut entrer dans le périmètre si elle contribue directement au service sécurisé. La notion de processus critique devient alors centrale.
Cette logique rejoint les méthodes de management déjà connues dans d’autres référentiels. La compréhension des interactions entre activités est notamment abordée dans la logique de cartographie des processus, qui aide à visualiser les responsabilités, les entrées, les sorties et les interfaces entre services.
Un bon périmètre ISO 27001 indique clairement ce qui est inclus, mais aussi ce qui est exclu. Les exclusions ne sont pas interdites, à condition d’être explicables. Par exemple, une filiale juridiquement indépendante, un site sans accès aux systèmes concernés ou une activité commerciale sans traitement de données sensibles peuvent être exclus si les liens avec le SMSI sont maîtrisés.
La difficulté apparaît lorsque des éléments exclus ont une influence directe sur la sécurité. Un prestataire d’infogérance, un outil cloud, une équipe support ou un service RH peuvent ne pas être inclus comme entités certifiées, mais rester nécessaires au fonctionnement du périmètre. Dans ce cas, l’organisation doit montrer comment ces dépendances sont contrôlées, notamment par des contrats, des clauses de sécurité, des revues ou des mesures de surveillance.
Une formulation efficace du périmètre doit être précise sans devenir illisible. Elle peut mentionner les activités couvertes, les sites concernés, les services délivrés, les populations impliquées et les systèmes principaux. En revanche, elle ne doit pas se limiter à une phrase vague comme « l’ensemble des activités informatiques ». L’auditeur attend une description concrète et vérifiable.
La première erreur consiste à choisir un périmètre uniquement pour simplifier l’audit. Un périmètre réduit peut sembler plus facile à certifier, mais il devient fragile s’il ignore des dépendances essentielles. La seconde erreur consiste à inclure toute l’entreprise sans disposer des ressources nécessaires. Dans ce cas, le projet risque de s’enliser dans une documentation excessive et des actions de sécurité impossibles à prioriser.
Une autre erreur fréquente est de définir le périmètre sans associer les métiers. La sécurité de l’information ne relève pas seulement de la DSI ou du RSSI. Les équipes juridiques, RH, commerciales, achats, production et support peuvent traiter des informations sensibles. Leur absence dans la phase de cadrage limite la qualité de l’analyse des risques et affaiblit la gouvernance du SMSI.
Une fois le périmètre posé, l’analyse des risques permet de vérifier sa pertinence. Elle identifie les menaces, vulnérabilités et impacts associés aux actifs inclus. Si cette analyse révèle qu’un élément externe ou exclu influence fortement la sécurité, le périmètre devra peut-être être ajusté ou complété par des mesures de maîtrise.
Par exemple, si une application certifiée dépend d’un fournisseur cloud, celui-ci n’est pas forcément inclus dans la certification de l’entreprise. En revanche, les risques liés à ce fournisseur doivent être évalués : localisation des données, continuité de service, chiffrement, droits d’accès, clauses contractuelles, réversibilité. Le périmètre doit donc rester aligné avec la réalité opérationnelle.
La déclaration d’applicabilité, souvent appelée SoA, découle ensuite de cette analyse. Elle indique quelles mesures de sécurité de l’annexe A sont applicables, lesquelles ne le sont pas et pourquoi. Si le périmètre est flou, la déclaration d’applicabilité le sera aussi. Une chaîne logique doit exister entre le contexte, le périmètre, les risques, les mesures et les preuves.
La norme ISO 27001 exige que le périmètre soit disponible sous forme d’information documentée. Cette formalisation peut figurer dans un document dédié, dans le manuel du SMSI ou dans une politique de sécurité. L’important est que la version retenue soit validée, maîtrisée et connue des personnes concernées.
Le document doit éviter les formulations approximatives. Une rédaction utile précise les activités certifiées, les entités juridiques, les implantations géographiques, les principaux systèmes d’information et les services supports inclus ou reliés. Elle peut également présenter les exclusions et leurs justifications. Cette transparence facilite la compréhension du SMSI par les collaborateurs comme par les auditeurs.
La documentation ne doit pas rester figée. Une évolution de l’organisation, une acquisition, un nouveau datacenter, un changement de prestataire ou le lancement d’une offre commerciale peuvent modifier les frontières du SMSI. Le périmètre doit donc être réexaminé lors des revues de direction, des audits internes et des changements majeurs. C’est une condition de maintien de la certification.
Lors de l’audit, le certificateur vérifie que le périmètre est clair, cohérent avec les activités réelles et correctement couvert par le SMSI. Il examine aussi si les exclusions sont raisonnables. Une définition trop marketing, trop technique ou trop vague peut entraîner des demandes de clarification, voire des non-conformités si elle empêche d’évaluer efficacement le système.
Les auditeurs croisent généralement la formulation du périmètre avec les entretiens, les procédures, les contrats, les schémas d’architecture, les preuves de contrôle et les résultats de l’analyse des risques. Les entreprises peuvent mieux anticiper cette étape en comprenant les étapes habituelles d’un audit externe, notamment la revue documentaire, les échanges avec les équipes et l’échantillonnage des preuves.
Un périmètre bien préparé aide aussi les collaborateurs à répondre de manière homogène. Chacun doit savoir si son activité est incluse, quelles règles s’appliquent et comment son travail contribue à la sécurité de l’information. Cette appropriation est souvent un marqueur de maturité plus convaincant qu’un document très détaillé mais peu compris.
Le meilleur périmètre ISO 27001 n’est pas forcément le plus large. C’est celui qui reflète fidèlement les activités à protéger, les attentes des parties intéressées et les capacités de l’organisation. Il doit permettre une gestion efficace des risques sans masquer des dépendances importantes. La crédibilité repose sur l’équilibre entre ambition, maîtrise et transparence.
Pour une première certification, certaines organisations choisissent un périmètre ciblé, par exemple un service cloud, une plateforme logicielle ou une activité d’hébergement. Cette stratégie peut être pertinente si elle correspond à un besoin client ou réglementaire. Elle doit toutefois s’inscrire dans une trajectoire plus large, avec la possibilité d’étendre progressivement le SMSI à d’autres activités.
Définir le périmètre d’une certification ISO 27001 revient donc à poser les fondations du projet. Cette décision influence la charge de travail, la qualité de l’analyse des risques, la pertinence des contrôles et la valeur du certificat. Un périmètre bien conçu est lisible, justifié, maîtrisé et aligné sur les enjeux réels de sécurité de l’information.
