C'est la question qui fait dérailler plus de programmes de gestion des risques et de conformité que nous ne voulons l'admettre :
"Qui est responsable ?".
Elle est soulevée lors des réunions lorsqu'une constatation reste sans réponse pendant des mois. Elle apparaît dans la préparation de l'audit lorsqu'un contrôle clé n'a pas été examiné. Et elle apparaît dans les analyses rétrospectives, juste après que quelque chose d'évitable est passé à travers les mailles du filet.
Tout le monde voit le problème, mais personne ne sait à qui incombe la tâche de le résoudre.
La propriété est le point de rupture de la GRC
La plupart des échecs des CRG ne résultent pas d'une négligence. Ils se produisent parce que personne n'est clairement responsable. Les risques sont enregistrés, mais ils ne bougent pas. Les constatations sont saisies, étiquetées et suivies... mais ne sont pas réellement clôturées. Les contrôles échouent et personne n'en assure le suivi. Les drapeaux de tiers sont reconnus, mais ne sont pas transmis à un échelon supérieur.
Non pas parce que les gens ne font pas leur travail, mais parce que le système ne leur a jamais dit que c 'était leur travail.
Trop souvent, les tâches sont attribuées à des rôles génériques ou à des boîtes de réception communes. Des échéances sont fixées mais rarement suivies. Les étapes de remédiation se déroulent de manière informelle dans des courriels ou des réunions et ne sont jamais intégrées dans la plateforme. Les rapports semblent clairs en surface, mais lorsqu'on creuse un peu, il n'y a aucune trace de qui a fait quoi (ou quand) ou pourquoi.
Dans un monde qui se nourrit de la collaboration, la GRC souffre encore d'ambiguïté. Et l'ambiguïté tue le suivi.
La documentation ne suffit pas. Vous avez besoin d'une responsabilisation intégrée
La saisie d'un risque ou l'enregistrement d'un problème ne représente que la moitié du travail. Ce qui se passe ensuite, la manière dont le problème est suivi et résolu, c'est là que la plupart des systèmes s'effondrent.
Un programme de GRC sain ne se contente pas de stocker des informations. Il rend les responsabilités visibles. Non pas d'une manière punitive, mais d'une manière pratique, "nous savons tous ce que l'on attend de nous".
Cela commence par l'attribution d'éléments à des individus, et non à des départements. Si tout le monde se l'approprie, personne ne se l'approprie. Une personne spécifique doit être responsable, avec les outils pour agir et la clarté nécessaire pour savoir ce qu'il faut faire.
Cela signifie également que la propriété doit être visible dans l'ensemble du système, et non enfouie dans les petits caractères. Les tableaux de bord et les rapports doivent indiquer qui est responsable, ce qui est en retard et où en sont les choses. Si une date limite est dépassée, le système ne doit pas dépendre de la mémoire de quelqu'un pour assurer le suivi. Il doit automatiquement détecter les retards, inciter les bonnes personnes à agir et faire remonter l'information si nécessaire.
Et surtout, la responsabilité ne doit pas s'arrêter à la phase de détection. Lorsqu'un contrôle échoue ou qu'un risque se déplace, votre plateforme doit prendre en charge l'ensemble du cycle de vie, de l'identification à la résolution. Cela signifie qu'il faut intégrer les étapes de remédiation dans le flux de travail et ne pas attendre des utilisateurs qu'ils recherchent des mises à jour dans des systèmes déconnectés les uns des autres.
La responsabilité est un problème de conception, pas un défaut de caractère
Il est facile de rejeter la faute sur les personnes lorsque les choses se passent mal. Mais le plus souvent, le véritable problème est d'ordre structurel.
Si un système ne permet pas de savoir qui est propriétaire de quoi, s'il n'y a pas de moyen intégré de suivi et si les rapports ne reflètent pas la réalité, il est évident que les choses se gâteront. La responsabilité ne peut pas être un élément maintenu manuellement. Elle doit être intégrée dans l'architecture.
Parce qu'en fin de compte, les risques les plus dangereux dans votre organisation ne sont pas ceux que vous avez documentés. Ce sont ceux que personne ne surveille.
Dernière réflexion : Le CRG ne fonctionne que lorsque quelqu'un se l'approprie
Une bonne GRC n'est pas une question de documentation parfaite. Il s'agit de mettre en place un système dans lequel la propriété est claire, l'action est attendue et personne ne se demande ce qu'il doit faire.
Lorsque vous intégrez ce type de clarté dans votre plateforme, la question cesse d'être "Qui est propriétaire de cela ?" et devient "Quelle est la meilleure façon de faire avancer les choses ?".
Vous voulez concevoir un programme de GRC où rien ne passe à travers les mailles du filet ? Parlons-en.
