Comment fonctionne le scoring de santé des contrôles dans Acuna GRC ?

Un statut saisi à la main reflète ce que quelqu’un croit le jour où il le saisit. Les référentiels demandent davantage. ISO/IEC 27001:2022 exige de déterminer ce qui doit être surveillé et mesuré, y compris les processus et les mesures de sécurité de l’information, et d’en évaluer les résultats (article 9.1). NIS2 cite, parmi les mesures de l’article 21, paragraphe 2, des politiques et procédures permettant d’évaluer l’efficacité des mesures de gestion des risques en matière de cybersécurité (point f).

Acuna GRC distingue donc deux types de valeurs :

• Le statut de conformité et la maturité sont des appréciations délibérées, que vous fixez sur une exigence ou une mesure.
• La santé est calculée à partir de ces appréciations et de ce qui se passe réellement en dessous : contrôles exécutés à temps, tâches faites, documents à jour. Personne ne peut la fixer à la main.

L’écart entre les deux est souvent l’information la plus utile à l’écran : une exigence jugée conforme dont les contrôles ont cessé de tourner.

La santé naît au contrôle. Un contrôle est une activité de vérification dotée d’une fréquence, et chacun est jugé de l’une de trois façons, indiquées dans la colonne Type de la Control Library :

• Record Completion : jugé sur l’achèvement de son enregistrement.
• Target Value : une valeur comparée à une cible, saisie à la main, issue d’un KPI ou remontée par un connecteur.
• Checklist : des sections et des points remplis et signés à chaque exécution, sur un ordinateur ou un téléphone. Chaque exécution terminée crée un enregistrement avec le PDF de l’exécution signée.

Sa santé dépend ensuite de son exécution à temps et de l’achèvement de ses tâches récurrentes. Les connecteurs peuvent en prendre une part : une métrique de contrôle issue d’un service connecté enregistre un succès ou un échec, qui met à jour la santé du contrôle et décale sa prochaine échéance une fois celle-ci atteinte. Voir comment fonctionnent les tâches récurrentes.

Chaque niveau applique la même règle du plus faible, pour qu’un bon résultat à un endroit ne masque pas un échec ailleurs :

• 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). La dimension la plus faible fixe le résultat.
• La santé d’une exigence remonte de ses mesures et contrôles reliés. Les exigences affichent Healthy, At Risk, Unhealthy, N/A ou Unknown.
• La santé d’un plan de traitement est calculée à partir de ses contrôles, mesures et tâches reliés, et remonte dans le risque qu’il traite.
• Un objectif affiche la santé des contrôles et des mesures qui lui sont reliés.

Comme une même mesure peut servir des exigences de plusieurs référentiels, un seul contrôle défaillant apparaît sur chaque exigence qui en dépend, qu’il s’agisse d’ISO 27001, de NIS2, de SOC 2 ou d’un référentiel propre. Voir comment les mesures et les contrôles sont reliés aux exigences.

Ouvrez l’onglet Health du contrôle. Il montre quelle dimension tire le score vers le bas et remonte la chaîne jusqu’à l’élément défaillant : une tâche en retard, une exécution manquée, une valeur sous la cible ou un document dont la revue est dépassée. Aiko peut aussi lister les éléments selon leur santé, par exemple les contrôles en mauvaise santé.

Les causes sont le plus souvent banales :

• Une tâche récurrente que personne n’a terminée, souvent parce que la personne assignée est partie ou a changé de poste.
• Un contrôle sans calendrier, ou un calendrier que personne ne porte.
• Une politique reliée à une mesure dont la revue annuelle est dépassée, ce qui dégrade la dimension documentation.
• Un connecteur qui ne se synchronise plus, si bien qu’un contrôle Target Value n’a plus de valeur récente.

Lorsque la cause est une vraie faiblesse et non un oubli, consignez-la comme constat et ouvrez une action corrective, pour que la correction soit suivie jusqu’à sa vérification dans Assure.