A board can approve a policy document and at the same time not know whether that policy is actually applied. That is not an exception, it is the normal state of affairs in an organisation where policy is written centrally and executed decentrally. The question an auditor asks is not "do you have a policy", but "can you show that this policy works". That is a different kind of question, and it calls for a different kind of answer.
Policy is an intention. It describes what an organisation wants to do: how it deals with suppliers, with data, with risks. Operation is what actually happens on the work floor, in a system, in a decision made last month. Between those two there can be a gap that no one has noticed, simply because no one has systematically checked whether the policy was actually carried out as intended.
Demonstrability bridges that gap. It is not the policy itself, but the trail that proves the policy has been applied: a decision, an approval, a deviation that was flagged and followed up. Without that trail, policy is a statement of intent, not of execution.
Not every document that relates to a topic is proof that the obligation has been complied with. A process description shows how something is supposed to work, not that it worked that way. Proof that holds up is generally more concrete: an approval with a date and name, a system log, a deviation report with the follow-up action taken. What counts as proof for an obligation, worked out for a group with multiple entities shows what level of detail is needed to make an obligation demonstrable, and what level falls short.
That distinction matters more than it seems. An organisation that relies on policy documents and training overviews generally has more paper than proof. The question is not how much documentation exists, but whether that documentation proves that a specific action was carried out at a specific moment by a specific person.
In a single entity with a manageable organisation, proof can usually be found in a limited number of places. In a group with multiple entities, countries or departments, a different picture emerges. Policy is set centrally, but execution takes place in subsidiaries that have their own systems, their own responsible parties and their own ways of recording things. The proof that the policy works therefore arises in dozens of places at once, without there being a central overview of exactly where that proof sits.
Where proof gets scattered in a group with multiple entities describes how that fragmentation arises and why it often only reveals itself at the moment someone actually needs the proof. That moment is usually an audit, a due diligence, or a question from a supervisory authority, and that is precisely the moment when haste and uncertainty are most damaging.
Proof that exists but cannot be found does not function as proof in practice. An auditor who has to wait three weeks for an answer that was already sitting somewhere else draws a conclusion about the quality of internal control from that, regardless of whether the underlying policy was substantively sound. Demonstrability therefore requires not only proof, but a structure in which that proof surfaces within a reasonable amount of time.
How you store proof so an auditor can find it, worked out for a group with multiple entities addresses that findability: where proof is recorded, who has access to it, and how to prevent the answer to a simple question from turning into a weeks-long search. This also requires a clear assignment of ownership: who owns an obligation in a group with multiple entities determines not only who is responsible for execution, but also who can be held accountable at the moment the proof is requested.
To bring policy and practice together, it must be clear per obligation who the owner is, what counts as proof, and which control demonstrates that the proof is checked periodically. Those three elements together form a control matrix: an overview that links obligation, owner and proof, so that a board does not have to reconstruct who was responsible for what every time a question arises. The same structure, worked out specifically for the complexity of a group structure, is described in how you demonstrate that policy is also practice in a group with multiple entities.
The Compliance Check from csrdcompliance.net is under construction. The goal is an overview in which the owner, the proof and the corresponding control are recorded for each obligation, so that a board can demonstrate that it is in control instead of having to claim it. Anyone who wants to make use of this as soon as it becomes available can sign up for the waiting list.
Mapping out ownership and proof is one side of the matter, carrying out all those checks and records is the other. Anyone wondering how much of that executional work actually needs to remain human work can turn to the work scan from FTE TO AI: it calculates, per task, which part of the work can be taken over by AI, and which part requires judgement that remains with a human.
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.