6.3 — Planification des modifications

L’exigence la plus courte de la clause 6, et l’une des plus courtes de toute la norme — mais c’est exactement le genre de chose qu’un auditeur questionne après avoir vu un changement manifestement pas planifié.

En langage clair

Chaque fois que votre organisation décide que le SGSI doit changer — un nouveau système, une équipe restructurée, un nouveau fournisseur, un traitement des risques revu — ce changement doit être mené de façon planifiée, pas improvisée au fur et à mesure.

Pourquoi cette exigence existe

Les changements non planifiés sont là où les lacunes du SGSI apparaissent silencieusement : un nouvel outil est adopté sans que personne ne mette à jour le registre des risques, une réorganisation d’équipe laisse une responsabilité de sécurité sans titulaire, une décision affectant le périmètre est prise sans vérification contre la clause 4.3. Cette sous-clause existe pour intercepter exactement cela.

Scénario : une entreprise migre sa base de données clients vers un nouveau fournisseur infonuagique un week-end chargé, purement comme un projet TI, sans que personne ne vérifie si le périmètre du SGSI, l’appréciation des risques ou la SoA devaient être mis à jour. Trois mois plus tard, un auditeur demande qui a examiné les implications de sécurité de la migration — et il n’y a pas de réponse.

Ce que la norme attend

L’exigence elle-même est brève : lorsque l’organisation détermine un besoin de changement au SGSI, ce changement doit être mené de façon planifiée. En pratique, cela signifie traiter les changements pertinents pour le SGSI avec la même discipline que tout autre projet : évaluer l’impact sécuritaire avant d’effectuer le changement, mettre à jour la documentation affectée (périmètre, registre des risques, SoA, politiques) dans le cadre du changement plutôt qu’après coup, et désigner un responsable chargé de s’en assurer.

En pratique

• Ajouter un court point de contrôle « impact SGSI » à votre processus de gestion du changement existant plutôt que d’en bâtir un nouveau de zéro.
• Pour tout changement affectant le périmètre, le risque ou les contrôles, mettre à jour le document pertinent (4.3, 6.1.2/6.1.3 ou la SoA) avant que le changement n’entre en vigueur, pas des semaines plus tard.
• Tenir un registre simple des changements significatifs pertinents pour le SGSI — ce qui a changé, qui l’a approuvé, ce qui a été mis à jour en conséquence.

Preuves que l’auditeur demandera

• Un registre de changements ou des dossiers de gestion du changement montrant que l’impact sécuritaire a été considéré pour les changements significatifs.
• La preuve que les documents de périmètre, de risque ou la SoA ont été mis à jour au rythme des changements récents, pas rétroactivement lors de la préparation de l’audit.

Pièges courants

• Traiter ceci comme un processus distinct et lourd plutôt que comme un point de contrôle intégré à la gestion du changement TI ou projet existante.
• Mettre à jour la SoA et le registre des risques en lot juste avant l’audit plutôt qu’au fil des changements réels.

Exigences liées

• 6.2 Objectifs de sécurité — poursuivre un objectif est lui-même un changement qui nécessite une planification.
• 6.1.3 Traitement des risques — les nouvelles décisions de traitement déclenchent souvent des changements au SGSI couverts par la 6.3.
• 8.1 Planification et maîtrise opérationnelles — là où cette discipline de planification s’applique sur le plan opérationnel, y compris la maîtrise des changements non intentionnels.
• Clause parente : Clause 6 · Planification

Correspondance 2013 → 2022