Quelle est la différence entre une mesure et un contrôle dans la GRC ?

Les référentiels demandent deux choses différentes. D’abord, qu’une pratique soit en place : une politique d’accès, une routine de sauvegarde, une revue des fournisseurs. Ensuite, que vous sachiez qu’elle fonctionne : ISO/IEC 27001:2022 exige de surveiller et de mesurer la performance du SMSI (article 9.1), et un rapport SOC 2 Type II porte une opinion sur l’efficacité du fonctionnement des contrôles tout au long d’une période.

Séparer la mesure du contrôle répond aux deux :

• La mesure est rédigée une fois et reliée à chaque exigence qu’elle satisfait, dans ISO 27001, NIS2, SOC 2 ou tout autre référentiel.
• Le contrôle porte ce qui prouve le fonctionnement : un responsable, une fréquence, un critère de réussite et la preuve qu’il produit.
• Lorsqu’une vérification échoue, vous voyez quelle pratique est fragile et chaque exigence qui en dépend.

Sans cette séparation, les organisations finissent soit par documenter des pratiques que personne ne vérifie, soit par mener des vérifications rattachées à aucune exigence.

Un contrôle n’est utile que si chacun peut dire s’il est réussi. Il lui faut :

• Un responsable qui l’exécute ou le signe.
• Une fréquence, par exemple mensuelle ou trimestrielle.
• Un test clair : ce qui est vérifié, et ce qui vaut réussite.
• La preuve produite à chaque exécution, conservée avec sa date.
• Ce qui se passe en cas d’échec : un constat, une action corrective ou une escalade.

Dans Acuna GRC, l’assistant Add Control passe par les étapes Basics, Effectiveness, Target or Checklist, Schedule, Related et Review. Chaque contrôle est jugé de l’une de trois façons : Record Completion, une Target Value (saisie à la main, issue d’un KPI ou remontée par un connecteur), ou une Checklist remplie et signée point par point, qui crée un enregistrement avec le PDF de l’exécution signée. Un contrôle arrivé à échéance apparaît dans My Actions de son responsable.

• Rédiger une mesure comme un projet ponctuel, sans contrôle qui vérifie qu’elle se poursuit.
• Des contrôles sans fréquence, qui ne sont jamais dus et donc ne peuvent jamais échouer.
• Des vérifications qui testent l’existence d’un document plutôt que la réalité de la pratique.
• Une mesure par référentiel pour une même pratique, ce qui disperse les preuves.
• Des preuves rattachées au référentiel plutôt qu’au contrôle, si bien que la même preuve est collectée plusieurs fois.

Prenons la revue trimestrielle des droits d’accès. Dans Implement, la mesure « Les droits d’accès sont revus chaque trimestre » est reliée aux exigences de contrôle d’accès de chaque référentiel suivi. Un contrôle trimestriel la vérifie, jugé par Record Completion, et une tâche récurrente réalise la revue et dépose l’enregistrement une fois terminée.

La santé naît au contrôle, selon qu’il a été exécuté à temps et selon ses tâches. La santé d’une mesure combine trois dimensions : la conception, le fonctionnement (ses contrôles reliés) et la documentation (ses documents reliés à jour), et la plus faible l’emporte. La santé de l’exigence remonte des mesures et contrôles reliés selon la même règle du plus faible. L’onglet Health d’un contrôle montre quelle dimension tire le score vers le bas. Voir comment fonctionne la santé des contrôles et comment les mesures et les contrôles sont reliés aux exigences.