Preuves de gestion des changements acceptées par les auditeurs

Dans un audit SOC 2 Type II, la gestion des changements (CC8.1) est l'un des contrôles les plus échantillonnés : l'auditeur sélectionne des changements sur toute la période et vous demande de prouver que chacun a été autorisé, testé et approuvé avant sa mise en production. ISO 27001 (A.8.32), PCI DSS (6.5.1, 6.5.2) et le règlement d'exécution de NIS2 (point 6.4) demandent la même chose, en d'autres termes. Les équipes d'ingénierie font généralement le travail ; c'est la preuve qui fait défaut.

Ce que testent les auditeurs

Pour un échantillon de changements, ils veulent voir :

1. Le changement a été demandé et décrit : un ticket ou une pull request indiquant quoi et pourquoi.
2. Il a été revu par une personne autre que son auteur : séparation des tâches.
3. Il a été testé avant la mise en production, avec les résultats.
4. Il a été approuvé avant le déploiement.
5. Ce qui a été déployé correspond à ce qui a été approuvé : aucun code non revu n'a atteint la production.
6. La population est complète : chaque changement en production est passé par le processus, y compris l'infrastructure et la configuration.

Preuves recevables

• Protection de branche : la branche principale exige au moins une revue approbatrice émanant d'une personne autre que l'auteur, et des contrôles réussis, avant la fusion. Exportez les paramètres et montrez qu'ils n'ont pas changé pendant la période.
• Déploiement par pipeline uniquement : les déploiements en production ne proviennent que de la branche protégée via CI/CD ; les ingénieurs ne peuvent pas pousser directement.
• Enregistrements liés : chaque déploiement renvoie à la pull request fusionnée, qui renvoie à son ticket.
• Infrastructure as code soumise aux mêmes règles, de sorte que les changements d'infrastructure laissent la même trace.
• Une liste complète des changements issue de l'outil de déploiement pour la période, à partir de laquelle l'auditeur peut échantillonner.

Changements d'urgence

Tout processus a besoin d'une voie rapide pour les incidents, et les auditeurs s'y attendent. Définissez-la : qui peut approuver, dans quel délai la revue a posteriori doit avoir lieu (sous un ou deux jours ouvrés est courant), et comment le changement est lié à l'incident. Assurez-vous ensuite que les changements d'urgence restent réellement rares.

Ce qui fait échouer les audits

• Administrateurs disposant d'un accès direct à la production qui contournent parfois le pipeline.
• Pull requests auto-approuvées, ou revues effectuées uniquement par des bots.
• Modifications de configuration effectuées dans une console sans trace.
• Protection de branche désactivée « temporairement » pendant la période.
• Aucune preuve de test au-delà de « CI réussie », alors que le changement en nécessitait davantage.

Échantillonnage : ce que fera réellement l'auditeur

Dans un audit SOC 2 Type II, l'auditeur demande généralement la population complète des changements en production sur la période, sélectionne un échantillon (sa taille dépend de la population et de la méthodologie de l'auditeur), et vous demande de montrer pour chaque changement échantillonné : la demande, la revue par une personne autre que l'auteur, les résultats des tests, l'approbation, et la correspondance entre ce qui a été déployé et ce qui a été approuvé.

Deux conséquences pratiques en découlent. D'abord, la population doit être complète et exportable : si des changements peuvent atteindre la production par plus d'une voie, chaque voie doit laisser une trace. Ensuite, tout changement échantillonné sans preuve devient une exception dans le rapport. Il est moins coûteux de corriger le processus pour que la preuve soit automatique que de la reconstituer en pleine vérification.

La page SOC 2 CC8.1 montre comment ce critère correspond à ISO 27001, PCI DSS et NIS2.

Un seul processus, tous les référentiels

Dans nos données, les exigences de gestion des changements sont liées d'un référentiel à l'autre :

Direction	Mis en correspondance	Faiblement liés	Aucune correspondance
Avoir SOC 2 → viser NIS2	47 sur 49 (96%)	1	1	rapport →
Avoir NIS2 → viser SOC 2	37 sur 61 (61%)	0	24	rapport →

Un processus fondé sur les pull requests, avec branches protégées et déploiement par pipeline uniquement, satisfait ensemble SOC 2, ISO 27001, PCI DSS et NIS2. PCI DSS ajoute quelques exigences : séparer le pré-production de la production (6.5.3), empêcher que des données de compte réelles ne se retrouvent dans les environnements de test (6.5.5) et confirmer les exigences de sécurité après des changements significatifs (6.5.2).

Consultez le sujet Développement sécurisé pour les exigences associées, et notre article sur la réutilisation des preuves entre SOC 2, ISO 27001 et PCI DSS.

Questions

Les pull requests comptent-elles comme approbation de changement pour SOC 2 ?

En général oui, si le dépôt impose une revue par une personne autre que l'auteur avant la fusion, que le déploiement est limité au code approuvé, et que vous pouvez le démontrer pour un échantillon de changements sur toute la période.

Comment les changements d'urgence doivent-ils être traités pour l'audit ?

Avec un processus d'urgence défini : correction immédiate si nécessaire, puis revue a posteriori et approbation dans un délai fixé, et un enregistrement reliant le changement à l'incident qui l'a justifié.