Une obligation qui existe sur papier mais n'a pas de propriétaire n'existe pas pour un auditeur. C'est le cœur du problème sur lequel de nombreuses organisations s'enlisent. Une obligation de reporting a été identifiée, une politique a été rédigée, mais la question de savoir qui veille quotidiennement à ce que la politique soit exécutée et qui peut démontrer que cela se produit reste sans réponse. Sans un nom associé à une obligation, il n'y a pas de contrôle, et sans contrôle, il n'y a pas de conformité démontrable.
L'appropriation d'une obligation est plus qu'un nom dans un organigramme. Cela signifie qu'une seule personne ou une seule fonction est responsable de trois choses : que l'obligation soit exécutée, que la preuve en soit consignée, et que cette preuve soit trouvable au moment où quelqu'un la demande. Un propriétaire qui sait seulement qu'une tâche lui appartient, mais qui ne peut pas montrer ce qui a été consigné à ce sujet, n'est en pratique pas un propriétaire mais un nom sur une liste.
Cette distinction est précisément là où de nombreux systèmes de contrôle interne échouent. La politique est établie au niveau de la direction, l'exécution a lieu au niveau des départements, et le lien entre les deux est rarement rendu explicite. Comment ce lien peut être établi, et pourquoi la politique et la pratique divergent sans ce lien, est décrit dans comment vous démontrez que la politique est aussi la pratique.
Dans une organisation à entité unique, le propriétaire d'une obligation est généralement encore identifiable : il y a une seule entité juridique, un seul conseil d'administration, un seul jeu de livres comptables. Dans un groupe avec plusieurs entités, cela change. Une obligation qui s'applique au niveau du groupe doit être exécutée quelque part dans l'organisation, et cela peut se situer au niveau du groupe, au niveau d'une filiale opérationnelle, ou être répartie sur plusieurs entités qui fournissent chacune une partie de l'information.
La question de savoir qui est propriétaire devient alors une question de structure : quelle entité consolide les données, quelle entité fournit les données sous-jacentes, et qui est responsable si l'un de ces maillons manque. Cette question se pose si souvent et de manière si spécifique dans les structures de groupe qu'elle fait l'objet d'un traitement séparé : qui est propriétaire d'une obligation dans un groupe avec plusieurs entités aborde comment cette responsabilité se répartit et où la répartition échoue.
L'appropriation et la preuve vont de pair, mais en pratique elles se séparent. Un propriétaire est désigné sur la base d'un schéma organisationnel, tandis que la preuve d'exécution est consignée ailleurs : dans un e-mail, une feuille de calcul sur un disque local, un système utilisé uniquement par une filiale opérationnelle. Celui qui doit rendre compte au niveau du groupe doit alors d'abord découvrir où se trouve la preuve avant de pouvoir montrer que l'obligation a été respectée.
Ce problème n'est pas incident, il est structurel dans toute organisation composée de plusieurs entités. C'est précisément ce que développe où la preuve se disperse dans un groupe avec plusieurs entités : quels endroits d'une organisation génèrent de la preuve sans que personne ne la collecte de manière centralisée, et pourquoi cela ne se remarque qu'au moment où un auditeur la demande.
Tout document fourni ne compte pas comme preuve pour un auditeur. Un document de politique démontre qu'il existe une intention, pas que cette intention a été exécutée. Un procès-verbal de réunion du conseil d'administration démontre qu'un sujet a été discuté, pas qu'une décision a été suivie. La preuve doit avoir un lien direct avec l'obligation qu'elle doit étayer : qui a fait quoi, quand, et comment cela a été consigné.
Dans un groupe avec plusieurs entités, cette question se complexifie, car la preuve peut naître à différents niveaux et chaque niveau n'a pas la même force probante. Ce qui compte spécifiquement comme preuve dans cette situation, et pourquoi la preuve d'une entité n'est pas automatiquement la preuve pour l'obligation du groupe, est détaillé dans ce qui compte comme preuve pour une obligation dans un groupe avec plusieurs entités.
Une liste de propriétaires est un point de départ, pas un système. Pour être démontrablement en contrôle, chaque obligation doit être liée à un propriétaire, à la preuve que ce propriétaire fournit, et à un contrôle qui établit si cette preuve est complète et à jour. Ce lien est souvent consigné dans une control matrix, un aperçu qui montre, par obligation, qui est responsable et comment cela est contrôlé. Ce qu'implique précisément une control matrix et pourquoi une liste de propriétaires sans cette matrice ne tient pas devant un audit est traité dans ce qu'est une control matrix.
Tout aussi important est la question de savoir où cette preuve est conservée, et si un auditeur peut la retrouver sans l'aide de l'organisation. Un système qui dépend de la connaissance d'un seul collaborateur n'est pas un système mais un risque. Comment la preuve est conservée de manière à rester trouvable, même lorsqu'un groupe est composé de plusieurs entités, est décrit dans comment vous conservez la preuve pour qu'un auditeur la trouve dans un groupe avec plusieurs entités.
L'attribution de l'appropriation et la mise en place de la preuve représentent du travail : établir des aperçus, collecter la documentation, suivre qui a fourni quoi. Une partie de ce travail est répétable et suit un schéma fixe, ce qui le rend adapté à un soutien par l'IA. Le scan de travail de FTE TO AI calcule, par tâche, quelle part de ce travail peut être reprise, afin de rendre visible où les personnes restent nécessaires pour l'évaluation et où les systèmes peuvent reprendre la collecte et l'organisation de la preuve.
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.