Tout programme de conformité possède une étagère de documents : politiques, descriptions de contrôles, procédures, chacun décrivant comment l'organisation a l'intention de se comporter. Ces documents sont nécessaires. Ils ne sont pas non plus l'endroit où la conformité réussit ou échoue réellement.
L'écart entre la politique et la réalité
La politique de contrôle d'accès stipule le principe du moindre privilège. La politique de chiffrement stipule que les données en transit sont protégées. La politique de conservation stipule que les données personnelles sont supprimées après la fin de leur finalité. Ce sont des déclarations vraies sur l'intention.
Leur véracité concernant votre système dépend entièrement du code : la politique IAM effectivement déployée, le niveau minimal de TLS effectivement appliqué par le service, le travail de suppression effectivement exécuté. L'écart entre le document et le déploiement est précisément là où les audits trouvent leurs constats, et il s'ouvre une pull request ordinaire à la fois.
La diff est l'endroit où l'état du contrôle change
Un contrôle ne se dégrade pas silencieusement. Quelque chose le modifie : un rôle est élargi, un paramètre de chiffrement est supprimé, une limite de conservation est retirée. Chacune de ces modifications est une diff, écrite par quelqu'un, révisée par quelqu'un, avec un moment où elle aurait pu être détectée.
Si vous souhaitez gérer un contrôle, gérez le moment où il change. Le document de politique ne peut pas le faire ; il ne sait pas que la diff a eu lieu. La pull request est l'endroit où l'état du contrôle change réellement, donc c'est là qu'il doit être vérifié.
Des preuves qui correspondent à la réalité
Un effet secondaire de la vérification des contrôles au niveau de la diff est que vos preuves cessent d'être une histoire que vous assemblez au moment de l'audit et deviennent un enregistrement de ce qui s'est réellement passé : ce changement a concerné ce contrôle, voici la clause, voici comment il a été résolu, dans le fil de la PR, avec des horodatages.
heygrc cite le contrôle spécifique sur le changement qui le concerne, de sorte que la trace est ancrée dans le code, et non dans un document décrivant ce que le code est censé faire.