Noru

Continuous Evidence Collection: What Auditors Actually Accept

How to produce audit evidence as a by-product of running your systems: what makes evidence acceptable, why collection timestamps decide whether a SOC 2 Type II works, and the failure modes that leave a programme quietly unevidenced.

By Noru3 min readPublished

Continuous evidence collection means your systems emit proof that controls operated, at the time they operated, rather than someone assembling screenshots before an audit. What makes evidence acceptable is not its format but three properties: it identifies the control it supports, it carries a collection timestamp from when the control ran, and it can be traced back to an authoritative source rather than an intermediary. The timestamp is the load-bearing one — a SOC 2 Type II tests whether controls operated throughout a period, so evidence gathered afterwards can show the control works now but says nothing about the window under examination.

What makes a piece of evidence acceptable

Auditors are not attached to any particular format. What they need is to be able to conclude that a control operated, and that conclusion rests on three things being present.

It identifies the control

An export with no indication of which control it supports creates work for whoever receives it and invites a request for clarification. Evidence should carry the mapping, not rely on the reader inferring it from a filename.

It carries a collection timestamp

Not the date you sent it — the date the underlying state was observed. This is the property that decides whether a Type II examination can use the evidence at all, and it is the one screenshots systematically lack.

It traces to an authoritative source

Evidence that access reviews happened should come from the system where access is granted, not from a summary someone typed. The closer the evidence sits to the system of record, the less it depends on trusting an intermediary.

Why the timestamp is load-bearing

A SOC 2 Type II report opines on whether controls operated effectively throughout a review period, typically three to twelve months. The auditor samples from that window. If your evidence was produced in the week before fieldwork, it demonstrates that the control works today — which is a Type I question, not a Type II one.

This is the single most common reason a Type II timeline slips. The observation window runs, everyone believes the controls are operating, and it emerges in month five that nothing was being recorded in a form that survives. Evidence has to be instrumented before the window opens, because the window cannot be replayed.

Where evidence should come from

  • Cloud providers for configuration state — encryption, logging, network exposure, backup configuration.
  • Identity providers for access control — provisioning, deprovisioning, group membership, MFA enforcement, review completion.
  • Source control and CI for change management — reviews, approvals, deployment records tied to commits.
  • Device management for endpoint controls — disk encryption, patch level, screen lock.
  • Ticketing for incident response and remediation, where the trail of who did what and when already exists.

The pattern is that in each case the evidence already exists as a by-product of the system doing its job. Collection is a matter of reading it on a schedule and retaining it, not of creating something new.

Retention, which is longer than you think

Evidence has to survive the observation window plus the audit itself plus any follow-up, which in practice means well over a year for an annual Type II. Several default log retentions are considerably shorter than that, and the discovery usually happens at the worst moment. Check the retention on every source you depend on before the window opens, not when the auditor asks for March.

The failure mode nobody notices

A collector that breaks loudly gets fixed within the hour. The one that hurts is quiet: a credential expires, the integration starts returning nothing, the job is marked non-blocking, and the platform keeps displaying the last successfully collected state. Everything looks healthy. The evidence trail stopped weeks ago.

Two defences, both cheap. Alert on collection failure with the same seriousness as a failed deployment, because it is a compliance-affecting outage. And surface a last-collected timestamp per source in the interface people actually look at, so a stalled integration is visible to a human rather than only in a log.

What this buys you

The first audit is expensive whatever you do. What continuous collection changes is the second one: evidence already exists, controls have a documented history, and fieldwork becomes a review rather than a project. The same collection also serves ISO 27001 surveillance and the risk-management measures under NIS2, because the underlying questions overlap heavily.

If you want to see what evidence your own systems would produce, you can explore it at noru.tech.

Primary sources

FAQ

Continuous Compliance questions answered

Talk to us

What makes audit evidence acceptable?

That it identifies the control it supports, carries a timestamp from when the underlying state was observed, and traces back to an authoritative source rather than a summary someone typed. Format matters far less than these three properties.

Why can we not gather evidence just before the audit?

For a SOC 2 Type II you can not, because the examination tests whether controls operated throughout a period. Evidence produced after the window closes shows the control works now, which answers a different question. The window cannot be replayed.

Are screenshots acceptable evidence?

Sometimes accepted, always weak. They are typically undated, unattributable and easy to stage. Use them where no programmatic source exists, and treat that gap as something to fix rather than a steady state.

How long should evidence be retained?

Longer than most defaults. It has to survive the observation window, the audit, and any follow-up — comfortably over a year for an annual Type II. Verify retention on each source before the window opens.

What happens if a collector silently stops working?

That is the failure mode to design against. Alert on collection failure the way you would on a failed deployment, and show a last-collected timestamp per source in the interface, so a stalled integration is visible rather than hidden behind a dashboard still showing the last good state.