Compliance Evidence Should Be Generated, Not Assembled

The word “assembled” is doing more damage in compliance functions than almost any other single word in the vocabulary. Evidence that has to be assembled, at audit time, from systems that weren’t built to produce it, isn’t really evidence. It’s a research project with a deadline — and the deadline is usually set by someone else.

I’ve written about the evidence chain that runs from regulatory reference through to attestation. This is the operational failure mode that breaks it most often: treating evidence generation as a task performed when someone asks, rather than a property built into how systems already operate day to day.

What assembled evidence actually looks like

The pattern is familiar to anyone who has been through a real audit. A request arrives — show us the access reviews for this system over the last twelve months, show us every change approval for this critical function — and the response is a scramble: someone pulls records from three different systems, reconciles inconsistent formats, fills gaps from memory or from asking colleagues who might remember, and produces a document that technically answers the question while representing days of effort that added no value to the business, only to the audit.

That scramble is the tell. If evidence has to be assembled under time pressure, it means the underlying systems were never designed to produce it as a natural byproduct of operating — the access review happened, informally, but nobody logged it in a retrievable form; the change was approved, genuinely, but the approval lived in a chat message rather than a queryable record. The control existed. The evidence of the control did not, until someone was forced to manufacture it retrospectively.

What generated evidence looks like instead

Generated evidence is a structural property of the system doing the work, not a separate deliverable produced afterward. An access-review process that automatically logs who reviewed what, when, and what they decided — as a mandatory step in the review itself, not an optional note — produces the audit evidence as a side effect of the review happening at all. A change-approval workflow that requires the approval to be recorded in the system of record before the change can proceed produces its own evidence trail structurally, because the evidence and the approval are the same event, not two separate things one of which sometimes gets skipped.

The test for whether evidence is generated or assembled is simple and immediate: can the evidence for last month’s activity be produced right now, in minutes, by a query — or does producing it require someone’s time, judgment, and memory? A system generating real evidence answers the first way, always, regardless of when the question is asked. A system relying on assembly answers the second way, and the gap between “we could produce that” and “here it is” is exactly where audit findings live. That gap is also, not incidentally, where an organisation’s own confidence in its controls quietly erodes over time, long before any external party notices it too.

Why this matters more as the compliance burden grows

Every regulation I write about on this site — DORA’s register, the CRA’s reporting chain, NIS2’s audit posture — assumes evidence exists on demand, not evidence that gets assembled once a request lands. An organisation facing an increasing number of overlapping regulatory demands cannot scale a manual assembly process to meet them; the only approach that scales is redesigning the underlying systems so evidence generation is structural, once, rather than repeated manual effort for every new regulator that asks a version of the same question.

What the shift from assembled to generated actually looked like

A regulated payments firm’s access-review process, for years, involved a compliance analyst emailing system owners quarterly, collecting screenshots and confirmations manually, and compiling them into a document ahead of each audit — a genuine, honest process, and a two-week effort every quarter that produced evidence nobody could query between cycles. Rebuilding the process around the identity-management platform’s own audit log — requiring every review decision to be recorded in the system itself, as the review happened, rather than reported afterward by email — turned the quarterly two-week scramble into a query that returned results in seconds, any time, not just at audit time. The underlying reviews hadn’t become more rigorous. The evidence of them had simply stopped needing to be reconstructed by hand. The compliance analyst’s time, freed from quarterly assembly, went instead into actually reviewing the exceptions the system flagged — work that improved the control rather than just documenting it.

Generated evidence is what makes the feedback loop in genuine governance possible in the first place.

Assessing whether a specific control’s evidence is genuinely generated or quietly assembled under pressure — and what it would take to close that gap structurally — is exactly the kind of evidence-architecture work a technology control assessment is built to diagnose.