La gouvernance, la gestion des risques et la conformité (GRC) dans le secteur public : un problème d’architecture sous-jacent

Les équipes en charge des risques, de la conformité et de la sécurité IT dans la plupart des agences travaillent chacune sur leurs propres systèmes : un registre des risques, une configuration de règles, une exportation distincte des journaux d’audit. Chaque équipe peut répondre aux questions concernant son domaine. Aucune ne peut répondre rapidement à une question qui concerne les trois domaines, car il n’existe pas de registre partagé sous-jacent.

Il ne s’agit pas de trois niveaux de gouvernance, mais de trois visions distinctes d’une même agence, saisies dans trois consoles différentes, par des personnes qui n’ont peut-être jamais échangé, à partir de données qui ne partagent pas la même source. Cet article explique pourquoi des outils GRC fragmentés produisent structurellement ce résultat dans le secteur public, et comment y remédier.

Résumé exécutif

Les agences qui utilisent des outils distincts pour la gestion des risques, la conformité et l’IT peinent à répondre rapidement à une question précise : cette règle a-t-elle été appliquée, sur ces données citoyennes, et pouvons-nous le prouver ? Chaque outil répond bien à sa propre question. Aucun n’a été conçu pour répondre à une question qui englobe les trois domaines. Pour les responsables IT et conformité, l’audit qui compte n’est pas de vérifier si chaque outil fonctionne, mais si l’agence dispose d’un registre partagé et interrogeable de l’application des règles couvrant les trois fonctions.

Résumé des points clés

  1. Le fait que les équipes risques, conformité et IT conservent chacune leur propre vision de l’agence garantit que ces visions divergent avec le temps, au lieu de rester alignées.
  2. Une règle appliquée correctement dans un système doit être vérifiée manuellement dans un autre pour confirmer qu’elle a bien été exécutée.
  3. Personne ne gère l’interface entre les registres de risques, l’application des règles et les preuves d’audit, alors que c’est précisément là que se cache un défaut de contrôle.
  4. Plus il y a de systèmes, plus il y a d’exports, et plus ces exports sont dans des formats différents, plus la production de preuves lors d’un contrôle externe est lente et peu fiable.
  5. Regrouper les preuves sous-jacentes dans un seul registre ne signifie pas renoncer à des outils spécialisés. Cela signifie que ces outils disposent enfin d’une base fiable à interroger.

Pourquoi trois outils distincts laissent une question sans réponse

Les fonctions risques, conformité et sécurité IT ont chacune acquis leurs propres outils pour résoudre leur problème immédiat, à des moments différents, souvent à plusieurs années d’intervalle.

Chaque outil répond bien à sa propre question

Un registre des risques est efficace pour suivre les attestations de contrôle. Un système d’archivage gère bien l’application des règles d’accès. Une exportation de journaux d’audit enregistre fidèlement ce qui s’est passé. Aucun n’a été conçu pour vérifier si le contrôle attesté et la règle appliquée correspondent réellement.

La réconciliation des trois visions devient un projet sans responsable

Une fois que chaque fonction dispose de son propre système de référence, il faut quelqu’un pour croiser manuellement le registre des risques, la configuration des accès et les journaux bruts, une tâche rarement menée à bien de façon exhaustive.

Où se situe réellement la faille pour les agences

La faille ne se trouve que rarement dans l’outil d’une seule équipe. Elle réside dans l’intervalle entre les outils, là où la responsabilité de la réconciliation n’est pas clairement définie.

La faille entre attestation et application

Un contrôle attesté comme « en place » dans un registre des risques n’est pas forcément appliqué en production. Les agences découvrent souvent ce décalage uniquement lors d’un contrôle externe.

Le problème d’assemblage des preuves lors d’un contrôle externe

Quand un organisme de contrôle pose une question précise, quelqu’un doit extraire manuellement les données de trois systèmes distincts et les assembler pour fournir une réponse cohérente dans un délai serré.

Pourquoi la consolidation concerne les preuves, pas le nombre d’outils

Réduire le nombre de systèmes n’est pas utile parce que moins d’outils serait forcément mieux. Cela permet de fusionner trois visions gérées séparément en un registre partagé et interrogeable.

Un registre unique permet de vérifier les attestations, pas seulement de les archiver

Quand risques, conformité et IT s’appuient sur le même registre d’application des règles, on peut réellement vérifier une attestation par rapport à ce que le système a fait.

Un journal d’audit unique permet d’assembler les preuves par conception, pas à la main

Un journal d’audit consolidé couvrant tous les canaux permet de démarrer un contrôle externe avec un registre cohérent, plutôt que de devoir concilier trois exports sous pression.

Auditer la fragmentation GRC plutôt que chaque outil

L’audit pertinent pour une agence n’est pas de vérifier si chaque outil fonctionne. Il s’agit de choisir un contrôle précis et de vérifier si l’attestation, la configuration et le journal d’audit concordent réellement.

Comment un Data Control Plane offre un registre partagé au GRC

Le Data Control Plane de Kiteworks gère l’application des règles sur tous les canaux, y compris la messagerie électronique, le partage de fichiers, les API et les agents IA, et enregistre chaque action dans un journal d’audit infalsifiable et sans limitation qui alimente directement les outils SIEM. Ainsi, risques, conformité et IT disposent d’une source unique et fiable sur l’application des règles, au lieu de trois visions séparées qui divergent avec le temps.

Les agences qui souhaitent découvrir comment une architecture partagée comble leurs failles GRC peuvent réserver une démo personnalisée.

Foire aux questions

Chaque fonction conserve son propre système de référence, générant trois visions indépendantes d’une même agence qui divergent avec le temps. Il n’existe pas de registre partagé, ce qui rend impossible de répondre rapidement ou de façon fiable à des questions qui concernent à la fois les registres de risques, l’application des règles et les journaux d’audit.

Un contrôle indiqué comme « en place » dans un registre des risques n’est pas forcément appliqué dans les systèmes de production. Les agences découvrent souvent ces écarts uniquement lors de contrôles externes, car la réconciliation entre outils est rarement menée de façon exhaustive.

Le personnel doit extraire et rapprocher manuellement les données de trois systèmes distincts dans l’urgence, ce qui ralentit la production de preuves et les rend moins fiables. Plus il y a d’exports dans des formats différents, plus le risque d’erreurs et de retards augmente.

Il fournit un journal d’audit partagé et infalsifiable couvrant tous les canaux, que les équipes risques, conformité et IT peuvent interroger. Cela permet de vérifier les attestations par rapport à l’application réelle des règles et d’assembler les preuves par conception, sans intervention manuelle.

Lancez-vous.

Il est facile de commencer à garantir la conformité réglementaire et à gérer efficacement les risques avec Kiteworks. Rejoignez les milliers d’organisations qui ont confiance dans la manière dont elles échangent des données privées entre personnes, machines et systèmes. Commencez dès aujourd’hui.

Partagez
Tweetez
Partagez
Explore Kiteworks