Comment les mesures et les contrôles sont-ils reliés aux exigences dans Acuna GRC ?

Les référentiels se recoupent bien plus que leur formulation ne le laisse paraître. Une revue trimestrielle des droits d’accès répond au point 5.18 de l’annexe A d’ISO/IEC 27001:2022 (droits d’accès) et à l’article 21, paragraphe 2, point i), de NIS2, qui cite les politiques de contrôle d’accès parmi les mesures de gestion des risques en matière de cybersécurité, et en général à un critère SOC 2.

Si chaque référentiel est traité séparément, la même revue est décrite trois fois, vérifiée trois fois et prouvée trois fois, et les copies divergent. Si la revue est une seule mesure reliée aux trois exigences, elle est rédigée une fois, vérifiée par un seul contrôle et prouvée par un seul jeu d’enregistrements, et chaque référentiel voit le même résultat.

C’est la chaîne d’Acuna GRC : l’exigence est l’obligation, la mesure est la pratique qui la satisfait, le contrôle est la vérification qu’elle fonctionne, et la tâche est l’action que quelqu’un réalise.

Il existe plusieurs chemins, qui écrivent tous les mêmes liens :

• Sur la mesure elle-même, dans la Measure Library d’Implement, dont le panneau liste les exigences, contrôles, risques, enregistrements et tâches reliés.
• En adoptant des mesures de référence depuis Common Measures dans Comply. Chacune arrive dans votre Measure Library déjà reliée aux exigences qu’elle couvre.
• Sur la page Mapping, qui suggère des liens pour les exigences et mesures orphelines à partir de la bibliothèque de référence, et dont Run AI classe les candidats de votre propre bibliothèque avec un score de confiance et une raison d’une ligne. Vous les appliquez un par un, en masse après une feuille de revue, ou avec Link all mapped pour tout ce que prévoit le catalogue.
• Avec Aiko, en demandant par exemple à quelles mesures relier un contrôle. Aiko propose jusqu’à 20 liens, chacun avec une raison, et les travaux plus vastes passent par un traitement en masse de 2 000 enregistrements au plus, que vous revoyez avant que quoi que ce soit ne soit appliqué.

Les contrôles sont reliés aux mesures qu’ils vérifient à l’étape Related de l’assistant Add Control, et les contrôles adoptés depuis le catalogue arrivent avec les mesures suggérées précochées.

La page Mapping tient deux listes de lacunes avec des compteurs en temps réel. Orphan Requirements montre chaque exigence sans mesure, avec sa référence réelle dans le référentiel. Orphan Measures montre chaque mesure reliée à aucune exigence, avec des badges verts pour les référentiels couverts et des badges orange Missing là où le catalogue attend un lien. Un sélecteur de référentiel restreint la vue, et l’interrupteur Include ignored fait réapparaître les orphelins écartés volontairement.

Une exigence qui ne s’applique pas doit être marquée Non applicable avec une justification plutôt que laissée orpheline. Elle porte alors un badge N/A et sort des KPI de conformité. Voir comment fonctionne le marquage d’applicabilité.

Deux choses : la santé et la preuve.

La santé naît au contrôle, selon son exécution à temps et ses tâches, puis remonte à la mesure et à chaque exigence qui lui est reliée, selon la règle du plus faible. Voir comment fonctionne la santé des contrôles.

La preuve circule dans l’autre sens. Les enregistrements sont reliés aux contrôles, mesures et exigences, si bien qu’un auditeur peut partir d’une clause et la suivre jusqu’à la mesure, au contrôle et aux enregistrements datés qui montrent que le contrôle a été exécuté. Voir comment fonctionne le cycle de vie des preuves.

Erreurs fréquentes : une mesure par référentiel pour une même pratique, des contrôles reliés à aucune mesure, des liens créés au départ puis jamais revus après une mise à jour du référentiel, et des orphelins ignorés sans raison.