La clause 4 d’ISO 27001 est la plus courte de la norme, et pourtant tout le reste en dépend. Avant de parler de risques, de mesures de sécurité ou d’audit, l’organisation doit répondre à trois questions simples en apparence : dans quel environnement évolue-t-elle, qui attend quoi d’elle en matière de sécurité de l’information, et que couvre exactement son système de management de la sécurité de l’information (SMSI) ?
Un périmètre mal posé fausse l’appréciation des risques, gonfle ou vide la déclaration d’applicabilité, et se paie cher à l’audit de certification. Cet article détaille les quatre exigences de la clause 4 dans la version ISO/IEC 27001:2022 (amendement 1:2024 inclus), avec un regard pratique sur la réalité des PME québécoises.
4.1 — Comprendre l’organisation et son contexte
La norme demande de déterminer les enjeux internes et externes pertinents au regard de la finalité de l’organisation et qui influencent sa capacité à atteindre les résultats attendus de son SMSI. Autrement dit : qu’est-ce qui, autour et au sein de l’entreprise, peut faciliter ou compromettre la sécurité de l’information ?
Enjeux externes : ce qui vient de l’environnement
- Réglementaire — au Québec, la Loi 25 sur la protection des renseignements personnels impose notamment un responsable désigné, des évaluations des facteurs relatifs à la vie privée et la déclaration des incidents de confidentialité.
- Marché et clients — des donneurs d’ordre qui exigent la certification ISO 27001 ou des questionnaires de sécurité dans leurs appels d’offres.
- Menaces — rançongiciels, hameçonnage ciblé, fraude au président, compromission de fournisseurs.
- Technologie — dépendance à l’infonuagique, au télétravail, aux logiciels en mode SaaS.
- Climat — depuis l’amendement de 2024, l’organisation doit déterminer si les changements climatiques constituent un enjeu pertinent. Pour beaucoup de PME, la réponse sera brève, mais elle doit être réfléchie et consignée.
Enjeux internes : ce qui dépend de vous
Structure et gouvernance, culture de sécurité, taille de l’équipe TI, infogérance, applications critiques, croissance rapide, fusions ou projets de transformation numérique. Une PME de 40 employés dont toute l’informatique est confiée à un fournisseur externe n’a pas le même contexte qu’une firme de logiciels qui héberge les données de ses clients.
La norme n’impose pas de méthode. Une analyse PESTEL ou SWOT fait très bien l’affaire, à condition que les enjeux retenus se retrouvent ensuite dans l’appréciation des risques. C’est ce lien que l’auditeur cherchera.
4.2 — Les besoins et attentes des parties intéressées
Il s’agit d’identifier les parties intéressées pertinentes pour le SMSI, leurs exigences, et — précision introduite en 2022 — lesquelles de ces exigences seront traitées par le SMSI. Toutes les attentes ne deviennent pas des obligations ; la norme demande de faire ce tri explicitement.
- Clients : clauses contractuelles de confidentialité, disponibilité des services, preuves de conformité.
- Autorités : Commission d’accès à l’information, exigences sectorielles (santé, finance, marchés publics).
- Employés : protection de leurs renseignements personnels, outils de travail sécurisés.
- Fournisseurs et infogérants : accès encadrés, responsabilités partagées dans l’infonuagique.
- Actionnaires, assureurs, banques : continuité des activités, exigences de cyberassurance.
Un simple tableau suffit : partie intéressée, exigence, source (contrat, loi, attente), traitée ou non par le SMSI, et où elle est prise en charge. Ce registre alimente directement la politique de sécurité (clause 5) et l’appréciation des risques (clause 6).
4.3 — Déterminer le domaine d’application du SMSI
Le périmètre est une information documentée obligatoire. Il doit tenir compte des enjeux (4.1), des exigences (4.2) et des interfaces et dépendances entre les activités de l’organisation et celles d’autres organisations. C’est souvent ce dernier point qui est négligé.
Un bon énoncé de périmètre précise :
- les activités, produits ou services couverts ;
- les sites physiques et le travail à distance ;
- les systèmes d’information et les services infonuagiques concernés ;
- les unités organisationnelles et les personnes ;
- les interfaces avec les fournisseurs et ce qui reste sous leur responsabilité ;
- les exclusions, avec leur justification.
Périmètre restreint ou périmètre complet ?
Une PME peut limiter son SMSI à une activité, par exemple la plateforme SaaS qu’elle vend à ses clients. C’est légitime et souvent judicieux pour une première certification. Mais le périmètre doit rester cohérent et défendable : exclure le service des ressources humaines alors que les administrateurs de la plateforme en dépendent pour leurs accès, c’est créer une zone grise que l’auditeur remarquera. Le certificat mentionne le périmètre ; vos clients le liront.
4.4 — Établir le système de management
La dernière exigence rappelle que le SMSI doit être établi, mis en œuvre, tenu à jour et amélioré en continu. La version 2022 ajoute une nuance importante : cela inclut les processus nécessaires et leurs interactions. Le SMSI n’est pas une pile de politiques, mais un ensemble de processus reliés : gestion des risques, gestion des incidents, gestion des accès, gestion des changements, audit interne, revue de direction.
Une cartographie simple de ces processus, avec leurs responsables et leurs entrées et sorties, répond à cette exigence et facilite énormément la suite du projet.
Les erreurs fréquentes dans les PME
- Un contexte générique, copié d’un modèle, qui ne décrit pas réellement l’entreprise.
- Des parties intéressées listées sans exigences, ou des exigences jamais reliées au SMSI.
- Un périmètre flou (« l’ensemble des systèmes TI ») qui ne permet pas de savoir ce qui est inclus.
- Des fournisseurs infonuagiques ignorés alors que les données critiques y résident.
- Une analyse figée : le contexte change, mais le document n’est jamais revu en revue de direction.
Ce que l’auditeur vérifiera
À l’étape 1 de la certification, l’auditeur lit l’énoncé de périmètre et l’analyse de contexte. À l’étape 2, il vérifie qu’ils sont vivants : les enjeux se retrouvent-ils dans le registre des risques ? Les exigences contractuelles sont-elles couvertes par des mesures ? Le périmètre correspond-il à ce qu’il observe sur le terrain ? Une incohérence ici se répercute sur toutes les clauses suivantes.
Questions fréquentes
L’analyse du contexte doit-elle être documentée ?
La norme n’exige formellement que le périmètre sous forme documentée. En pratique, sans trace écrite des enjeux et des parties intéressées, il est très difficile de démontrer à l’auditeur que l’exercice a été fait.
Peut-on élargir le périmètre après la certification ?
Oui. L’extension se fait généralement lors d’un audit de surveillance ou de renouvellement, en accord avec l’organisme de certification. Commencer petit puis élargir est une stratégie courante.
Combien de temps faut-il pour réaliser la clause 4 ?
Pour une PME, deux à trois ateliers avec la direction et les responsables clés suffisent habituellement. L’essentiel est d’y associer les bonnes personnes plutôt que de rédiger seul dans son coin.
La série ISO 27001, clause par clause
- Clause 4 — Contexte de l’organisation (vous êtes ici)
- Clause 5 — Leadership et politique de sécurité
- Clause 6 — Appréciation des risques et déclaration d’applicabilité
- Clause 7 — Support : ressources, compétences, documentation
- Clause 8 — Fonctionnement et traitement des risques
- Clause 9 — Évaluation de la performance
- Clause 10 — Amélioration
Parlons de votre périmètre
Définir le bon périmètre dès le départ fait gagner des mois sur le projet de certification. CyberBloc accompagne les PME québécoises dans leur démarche de conformité ISO 27001, de l’analyse de contexte jusqu’à l’audit blanc.
Appelez le 438-458-3325 ou écrivez-nous depuis la page Contact.
