Evidence Source

What Evidence Source Means in Practice

An evidence source is the authoritative record or system that demonstrates a control is actually operating, rather than merely documented. In practice, that means the proof comes from the live environment, such as configuration state, logs, identity reports, or workflow history, so the control statement reflects what is happening now, not what was once approved.

The key idea is that the evidence source should be tied to the control objective itself. If the control claims access is reviewed, the evidence should show a recent review outcome. If the control claims a configuration is enforced, the evidence should come from the system state that enforces it.

Why Live Evidence Matters for Governance

Live evidence matters because governance breaks down when controls are supported by stale screenshots, exported summaries, or manually maintained documents that drift from production. A control can look correct on paper while the environment has changed, which is why mature governance prefers evidence that can be regenerated from current state.

This is especially important where controls are affected by change, automation, or delegated administration. When the evidence source is part of the operating system of record, the control claim remains testable after each change instead of becoming a one-time attestation.

Good evidence sources also reduce argument over ownership. They make it clearer which team controls the source, how often it is updated, and whether the evidence can be reproduced consistently during review or audit.

Common Evidence Source Types

Evidence sources usually fall into a few practical categories: system-generated reports, configuration snapshots, security logs, ticketing or approval history, and policy or control outputs from cloud or identity platforms. The best choice depends on what the control is supposed to prove, because the source should match the control claim rather than the convenience of collection.

• Configuration state shows whether a setting is currently enforced.
• Logs show whether an action occurred, who performed it, and when.
• Reports show aggregated status, but only if they are generated from current system data.
• Ticket history shows process execution, but not always the technical result unless it is linked back to the live control.

The same control may need more than one source. For example, a change approval ticket can prove authorisation, while a system snapshot proves the change actually landed in the environment.

What Makes an Evidence Source Reliable

A reliable evidence source is timely, reproducible, and specific to the control being tested. It should be hard to edit after the fact, easy to trace back to the underlying system, and narrow enough that it proves the control rather than a broader or weaker claim.

Reliability also depends on whether the source can survive operational change. If a dashboard depends on manual refreshes or a spreadsheet copied out of band, the evidence may be useful for orientation but weak for assurance. The strongest evidence source is usually the one that a reviewer can independently regenerate from the live platform.

In practice, the quality test is simple: can another practitioner use the same source and reach the same conclusion without relying on personal interpretation?

Risk and Threat Considerations

Evidence sources become risky when they are stale, incomplete, or easy to manipulate, because the organisation may believe a control is effective when the live environment has already drifted. That creates assurance failure, weakens audit confidence, and can hide real exposure for longer than expected.

Failure mechanism: The control evidence is detached from the current state of the environment, so configuration drift, missed reviews, or unauthorised changes are not visible in the source being used to prove the control.

Impact: The organisation can overstate control effectiveness, miss emerging weaknesses, and discover the gap only after an audit finding, incident, or failed verification exercise.

Related resources from NHI Mgmt Group

• What breaks when investigators rely on cryptocurrency alone as the only source of evidence?
• What breaks when software inventories rely on manifests instead of source-built evidence?
• What should security teams do first when a breach claim includes source code and internal credentials but the evidence is still uncertain?
• Source Evidence