An obligation that exists on paper but has no owner does not exist for an auditor. That is the core of what many organizations get stuck on. A reporting obligation has been identified, policy has been written, but the question of who is responsible on a daily basis for ensuring the policy is carried out, and who can demonstrate that this happens, remains unanswered. Without a name attached to an obligation there is no control, and without control there is no demonstrable compliance.
Ownership of an obligation is more than a name in an organizational chart. It means that one person or one function is responsible for three things: that the obligation is carried out, that the evidence of this is recorded, and that this evidence can be found the moment someone asks for it. An owner who only knows that a task belongs to him, but cannot show what has been recorded of it, is in practice not an owner but a name on a list.
This distinction is precisely where many internal control systems fall short. Policy is established at board level, execution takes place at department level, and the link between the two is rarely made explicit. How that link can be made, and why policy and practice drift apart without it, is described in how you demonstrate that policy is also practice.
In a single organization, the owner of an obligation can usually still be found: there is one legal entity, one board, one set of books. In a group with multiple entities, that changes. An obligation that applies at group level must be carried out somewhere in the organization, and that can be at group level, at the level of an operating company, or spread across multiple entities that each deliver a part of the information.
The question of who is the owner then becomes a question of structure: which entity consolidates the data, which entity supplies the underlying data, and who is responsible if one of those links is missing. This question comes up so often and so specifically in group structures that a separate treatment exists for it: who owns an obligation in a group with multiple entities addresses how that responsibility is divided and where the division goes wrong.
Ownership and evidence belong together, but in practice they drift apart. An owner is designated based on an organizational chart, while the evidence of execution is recorded somewhere else: in an email, a spreadsheet on a local drive, a system that is only in use at one operating company. Whoever has to account for this at group level must then first find out where the evidence is located before he can show that the obligation has been fulfilled.
This problem is not incidental, it is structural in every organization that consists of multiple parts. This is exactly where where evidence becomes scattered in a group with multiple entities continues: which places in an organization allow evidence to arise without anyone centrally collecting that evidence, and why this only becomes apparent the moment an auditor asks for it.
Not every document that is submitted counts as evidence for an auditor. A policy document shows that there is an intention, not that the intention has been carried out. Minutes of a board meeting show that a topic has been discussed, not that a decision has been followed up. Evidence must have a direct line to the obligation it is meant to substantiate: who did what, when, and how was that recorded.
In a group with multiple entities, this question becomes more complex, because evidence can arise at different levels and not every level carries the same weight. What specifically counts as evidence in that situation, and why evidence from one entity is not automatically evidence for the obligation of the group, is set out in what counts as evidence for an obligation in a group with multiple entities.
A list of owners is a starting point, not a system. To be demonstrably in control, every obligation must be linked to an owner, to the evidence that owner produces, and to a control that establishes whether that evidence is complete and up to date. That link is often recorded in a control matrix, an overview that shows per obligation who is responsible and how this is checked. What a control matrix precisely entails, and why a list of owners without that matrix does not hold up in an audit, is addressed in what a control matrix is.
Equally important is the question of where that evidence is stored, and whether an auditor can find it again without help from the organization. A system that depends on the knowledge of one employee is not a system but a risk. How evidence is stored so that it remains findable, even when a group consists of multiple entities, is described in how you store evidence so that an auditor finds it in a group with multiple entities.
Assigning ownership and setting up evidence is work: drawing up overviews, gathering documentation, keeping track of who has submitted what. Part of that work is repeatable and follows a fixed pattern, which makes it suitable for support by AI. The work scan by FTE TO AI calculates per task which part of that work can be taken over, so that it becomes visible where people remain necessary for judgment and where systems can take over the collecting and organizing of evidence.
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.