An obligation is only demonstrated once there is something another party can verify without having to ask you. That is the essence of demonstrability: not what you know happened, but what an auditor, a regulator, or a new compliance officer can find without you having to explain it. Many companies only discover during an audit that the evidence does exist, but cannot be found.
Evidence is not the same as policy. A policy document states what is intended; evidence shows that intention was actually carried out. Think of an approved decision with a date and the approver's name, an email exchange that reveals a deliberation, a log of a check that was actually performed, or a report that reconciles with the underlying data. What exactly counts as sufficient evidence differs per obligation, and what counts as evidence for an obligation at a group with multiple entities shows how that question sharpens once multiple locations or subsidiaries are involved. The recurring theme is that the distinction between policy and practice is consistently underestimated: a document that looks good is not evidence that anyone actually acted on it. How to make that difference visible is worked out on how you demonstrate that policy is also practice.
Evidence usually does not originate at the place where it is eventually needed. A risk assessment is made by an operational team, an approval happens in an email, a check is recorded in a spreadsheet that only exists on a local drive. By the time an auditor asks for proof that an obligation has been met, someone has to track that evidence down again. With a single entity that is already difficult; with a group spanning multiple locations, countries, or subsidiaries, it becomes a search in itself. Each entity may have its own archive, its own system, its own way of recording things. Where exactly this goes wrong and why it is not simply a matter of discipline is described on where evidence gets scattered at a group with multiple entities. For group structures specifically, there is an elaboration of the same question as this page, tailored to that situation: how you keep evidence so an auditor can find it at a group.
Findability starts with ownership. Evidence that has no owner anywhere is not maintained anywhere, and therefore not kept in a place where anyone can find it. For every obligation there is someone who can ultimately explain what was done and why; who that is is not always obvious within an organisation with multiple departments or entities. How that ownership is established and why it does not automatically rest with the compliance department is explained on who owns an obligation. Once that ownership is clear, the next question is not yet another document, but a structure that links obligation, owner, and evidence together. That structure is usually called a control matrix, and what that matrix does and does not solve is explained on what a control matrix is.
The reflex when it comes to demonstrability is often: record more, archive more, create more folders. That does not solve the problem. An auditor who has to search through three systems to verify a single obligation does not experience that as being in control, even if the evidence does in fact exist. The question is not how much evidence there is, but whether it can be traced: from the obligation to the owner, to the evidence, to the check that demonstrates it happened. Without that traceability, evidence remains scattered, even if it is complete on paper.
This matters more the larger and more complex an organisation is. National implementations of the same European rule turn out differently per country, with different deadlines, different authorities, and different expectations about what counts as evidence. What is sufficient in one country is not automatically sufficient in another. That makes a central, traceable structure for evidence not a matter of tidiness, but a precondition for keeping oversight of what has actually been recorded per country, per entity, and per obligation.
Recording, maintaining, and making evidence findable is itself a form of work: organising documents, creating references, checking whether a file is complete before an auditor asks for it. Part of that work is repetitive and follows a fixed pattern per obligation. Anyone who wants to know which part of that work can be taken over by AI and which part remains dependent on human judgment can have that calculated with the werkscan from FTE TO AI, which indicates per task how much room there is for automation.
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.