Fonctionnement opérationnel

Pourquoi ce chapitre est le plus opérationnel

Les chapitres précédents ont couvert l'appréciation du risque et la construction de la Déclaration d'applicabilité (SoA). Ce travail produit des documents — un registre des risques, une liste de mesures sélectionnées. La clause 8 répond à une question différente : comment ces décisions se transforment-elles en actions vérifiables au quotidien ?

C'est la clause la plus courte du corps de texte normatif (trois paragraphes : 8.1, 8.2, 8.3) et pourtant celle qui génère le plus de preuves d'audit. Un auditeur qui veut évaluer la maturité réelle d'un SMSI ne s'arrête pas à la SoA : il demande comment un changement de configuration a été validé, comment un incident a été qualifié, et si le plan de traitement du risque a réellement été exécuté dans les délais annoncés.

La clause 8 n'introduit aucune nouvelle exigence de fond : elle exige la preuve d'exécution de ce que les clauses 6 et 7 ont planifié. Un SMSI qui a une SoA impeccable mais aucune trace de mise en œuvre échoue systématiquement en audit de certification, généralement sur une non-conformité majeure.

Du plan de traitement du risque à l'action

La clause 6.1.3 exige un plan de traitement du risque (PTR). La clause 8.3 exige sa mise en œuvre. Entre les deux, il y a un glissement que beaucoup d'organisations manquent : le PTR n'est pas la SoA.

La SoA répond à « quelles mesures de l'Annexe A avons-nous retenues, et pourquoi ». Le PTR répond à « qui fait quoi, avec quelles ressources, pour quelle échéance, afin d'amener le risque au niveau accepté ». Ce sont deux artefacts distincts, même s'ils partagent la même origine.

Un PTR exploitable contient, pour chaque risque non résiduel :

• l'identifiant du risque et sa référence dans le registre ;
• la mesure ou l'ensemble de mesures retenues, avec renvoi à la SoA ;
• un propriétaire nommé (pas une fonction générique comme « l'IT ») ;
• une échéance réaliste, cohérente avec les capacités réelles de l'équipe ;
• un critère de clôture vérifiable — pas « sécuriser le serveur » mais « MFA activé sur les 40 comptes à privilèges, vérifié par extraction Active Directory ».

Une PME de développement logiciel identifie en clause 6 le risque « fuite de code source via un poste de développeur compromis ». La SoA retient A.8.1 (dispositifs terminaux des utilisateurs) et A.8.5 (authentification sécurisée). Le PTR associé fixe : responsable = RSSI, échéance = fin de trimestre, action = déploiement EDR sur 100 % du parc dev + MFA obligatoire sur le VPNVPNRéseauxRéseau privé virtuel qui chiffre le trafic entre deux points sur un réseau public. Il crée un tunnel sécurisé permettant d'accéder à des ressources distantes comme si on était sur le réseau local.Voir dans le glossaire, critère de clôture = rapport de couverture EDR ≥ 95 % et zéro compte VPN sans second facteur. Six mois plus tard, l'auditeur ne demande pas « avez-vous un EDR » — il demande le rapport de couverture daté.

La maîtrise opérationnelle (clause 8.1) exige que ces processus soient exécutés « comme prévu » et que les critères associés soient documentés. En pratique, cela signifie conserver les preuves d'exécution — tickets de mise en œuvre, exports de configuration, comptes rendus de comité de pilotage — et non uniquement le plan initial. Un plan sans trace d'exécution vaut, pour un auditeur, un plan qui n'a jamais existé.

La gestion des changements planifiés

La clause 8.1 ajoute, depuis la révision 2022, une phrase courte mais lourde de conséquences : l'organisation doit maîtriser les changements planifiés et examiner les conséquences des changements non intentionnels. Ce n'est pas une exigence de gestion de projet générique — c'est une exigence de sécurité appliquée au changement.

En pratique, cela recouvre trois familles de changements :

1. Changements techniques — montée de version d'un ERP, migration d'infrastructure, ouverture d'un nouveau flux réseau.
2. Changements organisationnels — nouvelle prestation externalisée, réorganisation qui déplace la propriété d'un actif, arrivée d'un nouveau sous-traitant ayant accès à des 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 sensibles.
3. Changements non planifiés — panne majeure ayant conduit à un contournement de procédure, bascule d'urgence sur un site de secours, correctif appliqué en urgence hors fenêtre de maintenance.

La maîtrise attendue n'est pas la même sur les trois. Sur les changements planifiés, on attend une revue de sécurité avant mise en production : impact sur le registre des risques, impact sur la SoA, validation du propriétaire du risque concerné. Sur les changements non planifiés, on attend une revue a posteriori, dans un délai raisonnable, pour vérifier que le contournement n'a pas ouvert une brèche durable.

L'erreur la plus fréquente en audit de surveillance est le changement d'infrastructure — migration cloud, changement de prestataire d'hébergement, refonte réseau — mené sans qu'aucune trace ne relie la décision au processus de gestion des risques. L'auditeur retrouve alors un écart de plusieurs mois entre la SoA en vigueur et l'architecture réelle. C'est une non-conformité quasi automatique, car elle révèle que le SMSI ne suit pas l'organisation réelle.

Le moyen le plus simple d'éviter cet écart est d'intégrer un champ « impact SMSI » dans le processus de gestion des changements existant (ticket ITSM, CAB, ou simple fiche de changement), plutôt que de créer un circuit parallèle. La clause 8 n'exige pas un nouveau processus : elle exige que le processus existant produise une trace exploitable pour la sécurité.

La gestion des incidents de sécurité de l'information

La clause 8 ne détaille pas la gestion des incidents en profondeur — c'est l'Annexe A (A.5.24 à A.5.28) qui porte cette exigence technique. Mais le fonctionnement opérationnel du SMSI en dépend directement : un incident mal qualifié fausse tout le registre des risques en amont.

Distinction normative à retenir : un événement de sécurité est une occurrence identifiée indiquant une possible violation de la politique de sécurité ou une défaillance des mesures (une alerte antivirus, une tentative de connexion échouée). Un incident de sécurité est un événement — ou une série d'événements — qui présente une probabilité significative de compromettre les activités de l'organisation et de menacer la sécurité de l'information. Tous les événements ne deviennent pas des incidents ; la qualification est elle-même une étape du processus, pas un préalable.

Un cycle de traitement d'incident défendable en audit comprend, dans l'ordre :

La dernière ligne est la plus souvent négligée. Un incident traité et clôturé sans qu'aucune action ne remonte vers le registre des risques ou vers le programme d'audit interne est un incident à moitié traité du point de vue du SMSI — même si, opérationnellement, le service a été restauré dans les délais.

Une entreprise de services subit un incident de phishing ciblé ayant conduit à la compromission d'un compte de messagerie. L'incident est contenu en quatre heures, le compte réinitialisé, aucune donnée exfiltrée détectée. Traitement correct côté exploitation. Mais le retour d'expérience révèle que l'utilisateur ciblé n'avait suivi aucune sensibilisation depuis 18 mois — un fait qui aurait dû apparaître dans le registre des risques comme facteur aggravant sur le risque « ingénierie sociale ». Sans cette remontée, l'organisation répète l'exposition sans le savoir.

Cas particulier : les processus externalisés

La clause 8.1 précise que l'organisation doit s'assurer que les processus externalisés sont déterminés et maîtrisés. Cela concerne l'hébergement cloud, l'infogérance, mais aussi des prestations moins évidentes comme la paie ou le support client si elles traitent des informations dans le périmètre du SMSI.

La maîtrise ne signifie pas exécution directe — l'organisation ne pilote pas les serveurs de son hébergeur — mais elle exige un mécanisme de supervision : clauses contractuelles de sécurité, droit d'audit ou certification équivalente du prestataire, remontée d'incidents contractualisée avec un délai défini. Un contrat silencieux sur la sécurité, pour un processus dans le périmètre, est un point faible quasi systématiquement relevé.

Documenter sans bureaucratiser

Une inquiétude revient souvent chez les responsables SMSI d'organisations de taille moyenne : la peur de transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire la clause 8 en usine à documents qui ralentit les équipes opérationnelles sans apporter de sécurité réelle. Cette crainte est légitime, mais elle repose sur une confusion entre deux notions : la documentation exhaustive et la preuve suffisante.

La norme ne demande jamais de documenter un processus dans le détail narratif. Elle demande de pouvoir répondre, pour chaque décision structurante, à trois questions : qui a décidé, sur quelle base, et quand. Un export automatique d'un outil de ticketing, une entrée dans un journal de changement, ou même un compte rendu de réunion de quinze lignes suffisent largement, à condition qu'ils soient horodatés et non réécrits a posteriori.

Le test le plus fiable pour calibrer le niveau de documentation nécessaire consiste à se demander : « si cette action était remise en cause dans un an, est-ce que je retrouverais, en moins de dix minutes, qui l'a décidée et pourquoi ? » Si la réponse est oui, le niveau de traçabilité est suffisant, indépendamment du volume de papier produit.

Cette approche a une conséquence directe sur l'outillage : il est presque toujours préférable d'ajouter un champ « impact sécurité » à un outil que les équipes utilisent déjà — ticketing, gestionnaire de projet, outil de suivi d'incidents — plutôt que de faire vivre un registre parallèle en tableur que personne ne met à jour après le troisième mois. Les registres parallèles sont la première cause de désynchronisation entre le SMSI documenté et la réalité opérationnelle observée en audit.

La fréquence de revue compte autant que le contenu. Un PTR revu une fois par an au moment de la revue de direction, sans point intermédiaire, laisse dériver les échéances sans que personne ne s'en aperçoive avant l'audit. Un rythme trimestriel, même bref, permet de rattraper les retards avant qu'ils ne deviennent structurels et de garder le registre des risques aligné avec la réalité du terrain.

Checklist avant un audit de surveillance

• Le PTR est-il à jour, avec des échéances tenues ou justifiées si dépassées ?
• Chaque mesure de la SoA marquée « applicable » a-t-elle une preuve de mise en œuvre récente, pas seulement la mention initiale ?
• Les changements des six derniers mois touchant le périmètre du SMSI sont-ils tous reliés à une évaluation d'impact sécurité ?
• Le registre des incidents distingue-t-il clairement événements et incidents, avec des critères de qualification écrits ?
• Chaque incident clos a-t-il généré, le cas échéant, une action corrective visible en clause 10 ?
• Les contrats avec les prestataires couvrant un processus externalisé dans le périmètre contiennent-ils des clauses de sécurité et de notification d'incident ?

Cette checklist ne remplace pas un audit interne complet, mais elle permet de détecter en quelques heures les écarts les plus fréquemment sanctionnés par les organismes certificateurs.

Ce qu'il faut retenir avant le chapitre suivant

La clause 8 est le point où le SMSI cesse d'être un exercice documentaire pour devenir une pratique organisationnelle continue. Le chapitre suivant aborde la surveillance, la mesure et l'évaluation des performances (clause 9) — c'est-à-dire comment vérifier, avec des indicateurs, que ce fonctionnement opérationnel produit réellement l'effet recherché sur le niveau de risque.