Workflow de gestion des changements informatiques (SOC 2 CC8.1)
Un workflow de gestion des changements informatiques compatible SOC 2 : demande de changement, évaluation d'impact, approbation, tests, déploiement, examen post-implémentation, avec signatures d'approbation capturées par porte.
Qu'est-ce que le processus workflow de gestion des changements informatiques (soc 2 cc8.1) ?
La gestion du changement est presque toujours documentée comme un long chemin : demande, évaluation, réunion du CAB, approbation, tests, publication. Et pourtant, la plupart des changements réels empruntent un chemin différent, car le long chemin prend quatre jours. Le processus n’est pas faux : ce qui ne va pas, c’est qu’il n’y a qu’une seule voie.
Un diagramme qui survit à une visite guidée comporte donc trois pistes : les modifications standard, qui sont pré-approuvées et exécutées sans autre approbation ; les changements normaux, qui passent par une évaluation et une approbation ; et les changements d'urgence, qui peuvent être déployés en premier et approuvés ensuite, dans un délai et avec une justification documentée. Le classement constitue la première décision du processus et non une note dans la procédure.
La deuxième chose qu’un auditeur teste est la séparation des tâches : la personne qui a développé le changement peut-elle la mettre en production elle-même ? Cette question ne trouve de réponse que par un diagramme dans lequel l'approbation et le déploiement se situent dans des voies distinctes avec des propriétaires distincts.
Ce que couvre cet organigramme
Dans ce modèle
- La demande de changement : qui peut demander, ce qui doit être décrit (objectif, systèmes concernés et plan de restauration) et comment la demande est enregistrée
- Classification en modifications standard, normales et d'urgence : la branche qui décide du chemin d'approbation suivi par une modification
- Évaluation de l'impact et des risques : systèmes et données concernés, temps d'arrêt prévu, dépendances et impact sur la sécurité
- Approbation par le change manager ou le Change Advisory Board (CAB), avec une branche pour les changements rejetés et différés
- Tests et approbation dans l'environnement de test, y compris l'exigence d'un plan de restauration documenté avant la publication du changement
- Déploiement avec séparation des tâches entre le développeur et l'éditeur, vérification post-déploiement, restauration en cas d'échec et examen final des modifications d'urgence.
Quand utiliser ce modèle
- Vous passez par un audit SOC 2 où la procédure pas à pas CC8.1 demande : comment un changement atteint-il la production ?
- Les changements d'urgence sont utilisés comme voie normale parce que le processus formel est trop lent et vous voulez comprendre pourquoi.
- Les développeurs publient leurs propres modifications et vous devez soit documenter, soit introduire une séparation des tâches.
- Vous utilisez Jira ou ServiceNow pour des tickets individuels mais n'avez aucune description contrôlée du processus lui-même
- Les normes SOC 2 CC8.1 et ISO 27001 A.8.32 doivent être couvertes, et vous souhaitez un seul processus plutôt que deux descriptions qui disent des choses différentes.
Contrôles documentés
- CC8.1
- ISO 27001 A.8.32
Comment cela fonctionne
Commencez par le classement
Définissez les changements standard, normaux et d’urgence avec des exemples concrets issus de vos propres systèmes. Une classification que personne ne peut appliquer sans le demander devient « normale » pour tout dans la pratique.
Pré-approuver les modifications standard
Faites une liste des modifications à faible risque et reproductibles, et laissez-les s'exécuter sans approbation individuelle. C'est le seul moyen d'utiliser le chemin formel pour ce à quoi il est destiné.
Séparer l’approbation du déploiement
Les deux marches doivent se trouver dans des voies séparées avec des propriétaires distincts. C’est ce qu’une procédure pas à pas SOC 2 teste en premier, et il est difficile de le documenter rétroactivement.
Donnez une date limite au chemin d'urgence
Un changement d'urgence peut être déployé avant l'approbation, mais l'approbation et l'examen de suivi doivent avoir une date limite écrite sur le nœud. Sans date limite, la voie d’urgence est une solution de contournement.
Terminer par l’examen post-mise en œuvre
Ajoutez l’étape où les modifications ayant échoué et annulées sont examinées. C’est là que les modèles d’échecs de déploiement deviennent visibles, et c’est l’étape qui manque le plus souvent.
Questions fréquentes
Qu’exige SOC 2 CC8.1 pour la gestion du changement ?
CC8.1 (modifications affectant le système) nécessite des procédures documentées pour évaluer, approuver, tester et déployer les modifications, ainsi que des preuves que la procédure a été suivie pour les changements échantillonnés pendant la fenêtre d'audit.
En quoi QueryChart est-il différent d'un système de ticketing comme Jira pour la gestion du changement ?
Les systèmes de billetterie suivent les tickets de changement individuels ; ils ne documentent pas la version actuelle contrôlée du processus de gestion du changement lui-même. QueryChart documente le processus (l'artefact contrôlé) afin que les auditeurs puissent voir la conception avant d'échantillonner l'opération dans Jira/ServiceNow.
Quelle est la différence entre un changement standard, normal et d’urgence ?
Un changement standard est à faible risque, fréquent et pré-approuvé par rapport à un modèle de changement documenté. Il ne nécessite donc aucune approbation individuelle et passe directement à la planification. Un changement normal est tout ce qui doit être évalué et approuvé selon ses propres mérites : le cheminement jusqu'à l'OCC en passant par l'évaluation d'impact. Un changement d'urgence est un changement pour lequel attendre la prochaine réunion du CAB ferait plus de mal que le changement lui-même, de sorte qu'il obtient une approbation accélérée dans un CAB d'urgence. Dans ce diagramme, les trois se rencontrent dans le même calendrier de modifications, de déploiement et de révision, car la catégorie modifie le chemin d'approbation, pas la documentation.
Chaque changement doit-il passer par le Comité consultatif du changement (CAB) ?
Non, et un CAB qui examine tout devient un goulot d'étranglement que l'organisation commence à contourner. Réservez le tableau pour les modifications qui concernent l'ensemble du système, affectent les clients ou nécessitent un temps d'arrêt, et laissez un responsable des modifications nommé approuver le reste. Ce qui compte pour un auditeur, c'est que le critère déterminant ce qui est envoyé au CAB soit inscrit dans le processus contrôlé, et non que le conseil ait tout vu.