Contexte et parties intéressées

Pourquoi ce chapitre est le plus utile

La clause 4 est souvent traitée comme une formalité administrative que l'on expédie en une page avant de passer aux choses « sérieuses » — la politique, les contrôles de l'Annexe A, les procédures. C'est une erreur qui se paie cher en audit et, plus grave, en efficacité réelle du SMSI. Un périmètre mal posé produit une appréciation des risques hors sujet : on protège des actifs qui n'intéressent personne et on laisse hors champ des systèmes que les clients, eux, considèrent comme critiques.

Ce chapitre ne vise pas à remplir une case du référentiel. Il vise à produire un document de contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire qui sert réellement d'entrée à la clause 6 (appréciation des risques) et qui résiste à la première question d'un auditeur : « pourquoi ce périmètre et pas un autre ? ».

La clause 4 n'est pas optionnelle ni cosmétique. Elle conditionne juridiquement et techniquement la validité de tout ce qui suit : un SMSI certifié sur un périmètre mal justifié est un SMSI vulnérable à une non-conformité majeure dès le premier audit de surveillance.

La clause 4 dans la structure de la norme

ISO 27001:2022 suit la structure de haut niveau commune à toutes les normes de systèmes de management (Annex SL) : ISO 9001, ISO 14001, ISO 22301 partagent la même architecture en dix clauses. La clause 4, « Contexte de l'organisme », comporte quatre sous-clauses :

• 4.1 — Compréhension de l'organisme et de son contexte (enjeux externes et internes)
• 4.2 — Compréhension des besoins et attentes des parties intéressées
• 4.3 — Détermination du domaine d'application du SMSI
• 4.4 — Système de management de la sécurité de l'information

Cet enchaînement n'est pas arbitraire : chaque sous-clause alimente la suivante. Les enjeux (4.1) et les parties intéressées (4.2) déterminent ce qui doit être protégé et pourquoi ; le périmètre (4.3) traduit cela en frontières opérationnelles ; 4.4 rappelle que tout cela doit vivre comme un système managé, pas comme un document figé produit une fois pour l'audit initial.

4.1 — Enjeux externes et internes

L'objectif de 4.1 est de lister les facteurs, positifs ou négatifs, qui influencent la capacité de l'organisme à atteindre les résultats attendus de son SMSI. La norme ne prescrit pas de méthode, mais une analyse structurée type PESTEL (politique, économique, socioculturel, technologique, environnemental, légal) appliquée à la sécurité de l'information donne des résultats exploitables sans réinventer un cadre maison.

Ne cherchez pas l'exhaustivité théorique. Un enjeu mérite d'être retenu s'il a une conséquence identifiable sur la sécurité de l'information ou sur les objectifs du SMSI. Une liste de trente enjeux génériques recopiés d'un modèle en ligne n'apporte rien et alourdit inutilement la revue de direction.

Un piège classique consiste à confondre enjeux d'entreprise (croissance, rentabilité) et enjeux pertinents pour le SMSI. La clause 4.1 s'intéresse aux enjeux qui ont un impact sur la sécurité de l'information — soit directement (une nouvelle réglementation impose du chiffrementchiffrementCybersécuritéTransformation d'une donnée lisible en une forme inintelligible à l'aide d'une clé. Le destinataire disposant de la clé peut retrouver le message original. C'est le socle de la confidentialité sur Internet.Voir dans le glossaire), soit indirectement (une croissance rapide des effectifs dilue la culture de sécurité). L'analyse doit rester ancrée dans ce filtre.

4.2 — Parties intéressées et leurs exigences

La clause 4.2 demande de déterminer : (a) les parties intéressées pertinentes pour le SMSI, et (b) leurs exigences pertinentes en matière de sécurité de l'information. Depuis la révision 2022, un point c) a été ajouté : lesquelles de ces exigences seront traitées via le SMSI. Cette précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire est importante — toutes les attentes d'une partie intéressée ne relèvent pas nécessairement du système de management.

Les parties intéressées typiques d'un SMSI incluent :

• Clients et prospects — exigences contractuelles, clauses de sécurité dans les appels d'offres, SLA de disponibilité
• Actionnaires et direction — continuité d'activité, protection de l'image, retour sur investissement des contrôles
• Régulateurs et autorités — CNIL, ANSSI, autorités sectorielles selon le secteur d'activité
• Employés — droit à la protection de leurs donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire personnelles, conditions de travail liées aux outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire de sécurité
• Sous-traitants et fournisseurs — obligations réciproques, clauses de sécurité dans les contrats d'achat
• Partenaires technologiques — hébergeurs, éditeurs SaaS intégrés au système d'information

Pour chaque partie retenue, il faut documenter des exigences concrètes et vérifiables, pas des généralités. « Le client veut de la sécurité » n'est pas une exigence exploitable. « Le contrat-cadre avec le client X impose un chiffrement TLSTLSRéseauxProtocole cryptographique assurant confidentialité et intégrité des communications applicatives (notamment HTTPS).Voir dans le glossaire 1.2 minimum et une notification d'incident sous 48 heures » l'est.

Le piège le plus fréquemment relevé en audit : une liste de parties intéressées sans exigences associées, ou des exigences vagues non traçables vers un document source (contrat, texte réglementaire, politique interne). L'auditeur demandera systématiquement « où est-ce écrit ? ». Sans réponse, c'est une non-conformité mineure quasi automatique.

Les exigences se répartissent en trois familles qu'il est utile de distinguer dans le registre :

1. Exigences légales et réglementaires — d'application obligatoire, non négociables
2. Exigences contractuelles — engagées volontairement mais opposables (contrats clients, fournisseurs)
3. Exigences volontaires — engagements internes, chartes, certifications complémentaires visées

Cette distinction sert directement d'entrée au registre des exigences légales et contractuelles qui sera exploité plus loin dans le SMSI (souvent en clause 5.2 politique, et en Annexe A contrôle 5.31 « Exigences légales, statutaires, réglementaires et contractuelles »).

4.3 — Déterminer le périmètre du SMSI

Le périmètre (scope) est la sortie la plus visible de la clause 4 : c'est lui qui figure sur le certificat final. La norme exige qu'il soit déterminé en tenant compte des enjeux externes et internes (4.1), des exigences des parties intéressées (4.2), et des interfaces et dépendances entre les activités réalisées par l'organisme et celles réalisées par d'autres organismes.

Cette dernière clause — interfaces et dépendances — est souvent sous-estimée. Elle oblige à documenter explicitement les flux entrants et sortants du périmètre : quelles données transitent vers un prestataire hors périmètre, quels services externes le périmètre consomme, quelles responsabilités sont partagées avec un cloud provider par exemple.

Deux dérives opposées sont à éviter :

• Le périmètre trop large, souvent choisi par prudence ou par manque de temps d'analyse. Résultat : des activités périphériques, mal maîtrisées, plombent l'appréciation des risques et rendent le SMSI ingérable au quotidien.
• Le périmètre « gerrymandé », découpé pour exclure précisément les systèmes les plus problématiques (legacy non patché, filiale récente non intégrée). Les auditeurs certificateurs sont formés à repérer ce biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire : toute exclusion doit être justifiée par un critère objectif (criticité, dépendance, contrôle exercé), jamais par la simple volonté d'éviter un audit difficile.

Un éditeur SaaS RH, « NovaPaie », inclut dans son périmètre la plateforme de production « NovaCore », les équipes dev/ops/sécurité et les deux sites d'hébergement des postes de travail concernés. Il exclut explicitement un module de gestion des notes de frais racheté récemment, hébergé chez un tiers avec un contrat encore en cours de renégociation — exclusion documentée avec une date de réintégration prévue au prochain cycle de revue. Cette traçabilité, plus que le choix lui-même, est ce que l'auditeur valorise.

Le périmètre doit être disponible comme information documentée — au minimum un paragraphe dans le manuel SMSI ou un document dédié, incluant : les activités et sites couverts, les exclusions et leur justification, les interfaces avec l'extérieur du périmètre.

4.4 — Le SMSI comme système vivant

La clause 4.4 est courte mais structurante : l'organisme doit établir, mettre en œuvre, tenir à jour et améliorer en continu un SMSI conforme aux exigences de la norme. Elle rappelle que le contexte défini en 4.1-4.3 n'est pas un instantané figé pour l'audit initial. Un changement significatif — nouvelle réglementation, nouveau marché, acquisition, migration cloud — doit déclencher une révision du contexte et, potentiellement, du périmètre.

Le contexte alimente directement la clause 6 (appréciation des risques) et la clause 9.3 (revue de direction). Une revue de direction qui ne reconsidère jamais le contexte et les parties intéressées finit par appréciation des risques déconnectée de la réalité de l'entreprise.

Pièges courants et checklist avant audit

Les non-conformités relevées sur la clause 4 se répètent d'un audit à l'autre. Avant une revue interne ou un audit de certification, vérifiez :

• Les enjeux externes/internes sont-ils spécifiques à l'organisme, ou recopiés d'un modèle générique sans adaptation ?
• Chaque partie intéressée retenue a-t-elle au moins une exigence documentée et une source identifiable (contrat, texte de loi, charte) ?
• Le document précise-t-il explicitement quelles exigences sont traitées par le SMSI et lesquelles relèvent d'un autre dispositif ?
• Le périmètre mentionne-t-il les sites, activités, systèmes d'information ET les interfaces avec l'extérieur ?
• Chaque exclusion de périmètre est-elle justifiée par un critère objectif, daté et revu périodiquement ?
• Le document de contexte a-t-il une date de dernière révision et un propriétaire désigné ?
• Existe-t-il une trace de la prise en compte du contexte lors de la dernière revue de direction ?

Une pratique efficace consiste à tenir un registre unique — souvent appelé « registre du contexte » — regroupant enjeux, parties intéressées, exigences et périmètre dans un même document versionné, revu à fréquence fixe (annuelle a minima) et à chaque changement organisationnel majeur. Cela évite la dispersion entre plusieurs fichiers que personne ne finit par tenir à jour.

Ce registre gagne à être relié explicitement aux autres documents du SMSI plutôt que de rester isolé : un enjeu externe identifié en 4.1 (par exemple l'entrée en vigueur de NIS2 pour un secteur donné) devrait se retrouver comme facteur déclenchant dans le registre des risques de la clause 6, et une exigence contractuelle documentée en 4.2 devrait apparaître dans la déclaration d'applicabilité au moment de justifier le choix d'un contrôle de l'Annexe A. Sans ces liens explicites, la clause 4 reste un exercice isolé qui ne nourrit pas réellement les décisions de sécurité — exactement ce que les auditeurs cherchent à distinguer d'un simple exercice documentaire.

Sur le plan organisationnel, il est également utile de distinguer le rythme de revue du contexte lui-même (annuel, ou déclenché par un événement) du rythme de revue du périmètre, qui peut rester stable plusieurs années si l'activité de l'organisme ne change pas structurellement. Confondre les deux conduit soit à des révisions de périmètre trop fréquentes et coûteuses en gouvernance, soit à l'inverse à un périmètre figé qui ne reflète plus plusieurs années de croissance ou de refonte technique.

Ce qu'il faut retenir avant l'audit

La clause 4 n'est pas un préambule administratif : c'est le filtre qui détermine si l'appréciation des risques portera sur les bons actifs, et si le périmètre affiché sur le certificat correspond à une réalité opérationnelle vérifiable. Un contexte bien documenté se reconnaît à trois signes : les enjeux retenus ont un impact démontrable sur la sécurité de l'information, chaque partie intéressée a des exigences traçables jusqu'à leur source, et chaque frontière du périmètre — inclusion comme exclusion — est justifiée par un critère objectif plutôt que par la commodité.