4.3 — Détermination du périmètre du SGSI

La décision unique à l’intérieur de laquelle opère chaque autre clause de la norme. Si le périmètre est mal défini, rien en aval ne peut être entièrement juste.

En langage clair

La 4.3 exige de tracer une frontière claire et défendable autour de ce que votre SGSI couvre réellement — quelles entités, sites, systèmes et services sont dans le périmètre — en s’appuyant sur le contexte identifié à la 4.1 et les exigences des parties intéressées traitées à la 4.2.

Pourquoi cette exigence existe

Le périmètre est le plus grand levier de tout le projet de certification — il détermine directement le coût, le délai et la valeur que le certificat porte auprès de vos clients. Un périmètre tracé trop étroitement protège peu et n’impressionne personne ; un périmètre tracé trop largement multiplie votre charge de travail sans nécessairement réduire votre risque réel. Cette exigence force la frontière à être une décision réfléchie et documentée plutôt que ce qui s’est retrouvé inclus par défaut.

Scénario : une entreprise SaaS cadre son SGSI autour de son environnement infonuagique de production, mais un client demande ensuite si le certificat couvre aussi le système RH interne où vivent les données des employés. Si ce système n’a jamais été explicitement exclu avec une justification documentée, l’écart ressemble à un oubli plutôt qu’à une décision — et la conversation avec le client devient beaucoup plus difficile.

Ce que la norme attend

La norme attend que l’organisation détermine les frontières et l’applicabilité du SGSI pour établir son périmètre, en tenant compte des enjeux externes et internes de la 4.1, des exigences de la 4.2, et des interfaces et dépendances entre les activités réalisées par l’organisation et celles réalisées par d’autres organisations. Le périmètre doit être disponible en tant qu’information documentée.

En pratique

• Définir le périmètre en termes que les auditeurs reconnaissent : entités légales, sites physiques, systèmes et applications, et les services qui en découlent — pas des énoncés vagues comme « le TI de l’entreprise ».
• Documenter explicitement les interfaces avec tout ce qui se trouve hors de la frontière du périmètre — un fournisseur infonuagique, un système de paie externalisé, une intégration partenaire — car ces points de transfert sont exactement ce que les auditeurs sondent.
• Justifier les exclusions explicitement plutôt que de les laisser implicites — « le système RH est hors périmètre parce qu’il ne traite aucune donnée client et se trouve sur un réseau entièrement ségrégué » est défendable ; le silence ne l’est pas.

Preuves que l’auditeur demandera

• Un énoncé de périmètre documenté nommant les entités, sites, systèmes et services couverts.
• Une justification documentée pour toute exclusion notable.
• La cohérence entre le périmètre énoncé et ce que l’appréciation des risques, la SoA et les audits internes couvrent réellement.

Pièges courants

• Un énoncé de périmètre suffisamment vague pour que des personnes raisonnables soient en désaccord sur ce qu’il couvre réellement.
• Une exclusion sans justification documentée, découverte par l’auditeur plutôt que divulguée dès le départ.
• Dérive du périmètre : l’entreprise croît ou change et le périmètre documenté cesse silencieusement de correspondre à la réalité (voir la clause 6.3 sur la planification des modifications).

Exigences liées

• 4.2 Parties intéressées — les exigences dont cette décision de périmètre doit tenir compte.
• 6.1.1 Généralités — exige que le périmètre de votre appréciation des risques corresponde exactement à ce périmètre du SGSI.
• 6.3 Planification des modifications — là où les changements affectant le périmètre sont maîtrisés plutôt que de dériver silencieusement.
• Clause parente : Clause 4 · Contexte de l’organisation