Un conseil d'administration peut approuver un document de politique et ne pas savoir en même temps si cette politique est également appliquée. Ce n'est pas une exception, c'est l'état normal des choses dans une organisation où la politique est rédigée de manière centralisée et exécutée de manière décentralisée. La question qu'un auditeur pose n'est pas « avez-vous une politique », mais « pouvez-vous démontrer que cette politique fonctionne ». C'est un autre type de question, qui exige un autre type de réponse.
Une politique est une intention. Elle décrit ce qu'une organisation veut faire : comment elle gère ses fournisseurs, ses données, ses risques. Le fonctionnement est ce qui se passe réellement sur le terrain, dans un système, dans une décision prise le mois dernier. Entre ces deux éléments peut se trouver un écart que personne n'a remarqué, simplement parce que personne n'a systématiquement vérifié si la politique a bien été exécutée comme prévu.
La démontrabilité comble cet écart. Ce n'est pas la politique elle-même, mais la trace qui démontre que la politique a été appliquée : une décision, une approbation, un écart qui a été signalé et suivi. Sans cette trace, la politique est une déclaration d'intention, pas d'exécution.
Tout document traitant d'un sujet n'est pas une preuve que l'obligation a été respectée. Une description de processus montre comment quelque chose devrait fonctionner, pas que cela a effectivement fonctionné ainsi. Une preuve qui tient est généralement plus concrète : une approbation avec date et nom, un journal système, un rapport d'écart avec l'action de suivi entreprise. Ce qui compte comme preuve pour une obligation, développé pour un groupe avec plusieurs entités montre quel niveau de détail est nécessaire pour rendre une obligation démontrable, et quel niveau est insuffisant.
Cette distinction est plus importante qu'elle ne le paraît. Une organisation qui se contente de documents de politique et de tableaux récapitulatifs de formations a généralement plus de papier que de preuve. La question n'est pas de savoir combien de documentation il y a, mais si cette documentation démontre qu'une action spécifique a été effectuée à un moment spécifique par une personne spécifique.
Dans une entité unique avec une organisation claire, la preuve se trouve généralement dans un nombre limité d'endroits. Dans un groupe comprenant plusieurs entités, pays ou services, la situation est différente. La politique est établie de manière centralisée, mais l'exécution a lieu dans des filiales qui disposent de leurs propres systèmes, de leurs propres responsables et de leurs propres méthodes d'enregistrement. La preuve que la politique fonctionne se forme donc simultanément à des dizaines d'endroits, sans qu'il existe une vue d'ensemble centrale indiquant précisément où se trouve cette preuve.
Où la preuve se disperse dans un groupe avec plusieurs entités décrit comment naît cette fragmentation et pourquoi elle ne se révèle souvent qu'au moment où quelqu'un a effectivement besoin de la preuve. Ce moment est généralement un audit, une due diligence, ou une question d'une autorité de contrôle, et c'est précisément le moment où la précipitation et l'incertitude sont les plus dommageables.
Une preuve qui existe mais qui n'est pas trouvable ne fonctionne pas, dans la pratique, comme une preuve. Un auditeur qui doit attendre trois semaines une réponse qui se trouvait déjà ailleurs en tire une conclusion sur la qualité du contrôle interne, indépendamment de la question de savoir si la politique sous-jacente était sur le fond en ordre. La démontrabilité exige donc non seulement des preuves, mais aussi une structure dans laquelle ces preuves remontent à la surface dans un délai raisonnable.
Comment conserver les preuves pour qu'un auditeur les retrouve, développé pour un groupe avec plusieurs entités aborde cette question de la trouvabilité : où les preuves sont enregistrées, qui y a accès, et comment éviter que la réponse à une question simple ne devienne une recherche de plusieurs semaines. Cela implique également une attribution claire de la responsabilité : qui est propriétaire d'une obligation dans un groupe avec plusieurs entités détermine en effet non seulement qui est responsable de l'exécution, mais aussi qui peut être interpellé au moment où la preuve est demandée.
Pour rapprocher politique et pratique, il faut que pour chaque obligation, il soit clair qui en est le propriétaire, ce qui constitue une preuve, et quel contrôle démontre que la preuve est vérifiée périodiquement. Ces trois éléments réunis forment une matrice de contrôle : un aperçu qui relie obligation, propriétaire et preuve, de sorte qu'un conseil d'administration n'ait pas à reconstruire, question par question, qui était responsable de quoi. Cette même structure, spécifiquement développée pour la complexité d'une structure de groupe, est décrite dans comment démontrer que la politique est aussi une pratique dans un groupe avec plusieurs entités.
Le Compliance Check de csrdcompliance.net est en construction. L'objectif est un aperçu dans lequel, pour chaque obligation, le propriétaire, la preuve et le contrôle correspondant sont consignés, de sorte qu'un conseil d'administration puisse démontrer qu'il maîtrise la situation plutôt que de devoir l'affirmer. Toute personne souhaitant en faire usage dès sa disponibilité peut s'inscrire sur la liste d'attente.
Cartographier la responsabilité et les preuves est un aspect de la question, exécuter tous ces contrôles et enregistrements en est un autre. Pour ceux qui se demandent quelle part de ce travail d'exécution doit réellement rester un travail humain, le scan de travail de FTE TO AI est disponible : il calcule, par tâche, quelle part du travail peut être reprise par l'IA, et quelle part exige un jugement qui reste du ressort d'une personne.
Vraag maar welke verplichting op u van toepassing is, en waaraan u dat kunt aantonen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.