What a Regulated Firm Means by "Evidence" — and Why It Is Not a Log

You do not prove that an AI agent was allowed to release a payment by answering “the log says it happened.” Audit evidence is information gathered to support conclusions in an audit opinion, and the audit profession tests it by sufficiency and appropriateness.

A log may be part of the answer; it is not the answer.

Audit evidence definition in plain terms

A clean definition starts with purpose. CPCON states the point directly.

"Audit evidence is the information an auditor gathers to support the conclusions in an audit opinion."

— Audit Evidence: 8 Types, Examples & Definition, 1 January 2025

That definition does not say “logs.” It does not say “screenshots.” It does not say “documents saved in a compliance folder.” Those things may help, but only if they support the conclusion being tested.

The professional vocabulary then adds two filters. PCAOB Auditing Standard No. 15 describes sufficiency as the measure of quantity and appropriateness as the measure of quality. The same PCAOB wording explains that appropriateness means relevance and reliability.

"Sufficiency is the measure of the quantity of audit evidence."

— Auditing Standard No. 15

"Appropriateness is the measure of the quality of audit evidence, i.e., its relevance and reliability."

— Auditing Standard No. 15

This is where engineering teams often lose the thread. They hear “evidence” and produce a storage location. The audit question is different. It asks whether the material is enough, whether it is tied to the assertion, and whether a reviewer can trust it.

A transaction log can tell you that a record changed. It may not tell you whether the actor was entitled to make the change, whether the action matched the approved purpose, or whether an exception should have stopped it. The answer depends on what the log contains and what other material can be connected to it.

The distinction matters for AI agents because the disputed fact is rarely just “something happened.” The disputed fact is often that the system was allowed to do the thing at that time, on that account, under that policy, with no required escalation. A timestamped entry that says “success” is thin evidence for that conclusion.

A previous Crelis article on why enforcement is not evidence draws the same operational line from the other side: stopping or permitting an action is not the same as retaining an artefact that explains the decision. The useful audit evidence is not the act of enforcement. It is the inspectable support for the conclusion later reached about that act.

What is audit evidence in practice

In practice, the answer is not a catalogue first. It is a relationship between a conclusion and the material that supports it.

If the conclusion is that a payment release was authorised, a useful artefact should show more than the payment status. It should connect the attempted action to the actor, the rule or approval that allowed it, and the conditions known at the time. A bank statement may prove money moved; it does not, by itself, prove that the movement was within the authority granted to an AI agent.

If the conclusion is that a customer record was deleted correctly, the useful artefact is not merely a deletion event. It is the material that shows why deletion was permitted, which record was affected, and whether a retention or legal hold condition should have prevented it. The word “correctly” carries the burden.

If the conclusion is that a credit limit changed within policy, the useful artefact must speak to the policy question. A before-and-after value shows a change. It does not necessarily show that the change was within an approved band, based on approved data, or subject to the right approval path.

PCAOB Auditing Standard No. 15 also links the amount of evidence to risk: as risk increases, the amount of evidence the auditor should obtain also increases. That sentence is not a software architecture. It is an audit principle. It means a higher-risk action should not be defended with the same thin trace you would accept for a harmless notification.

There is also a reliability point. PCAOB AS 1105 says evidence obtained directly by the auditor is more reliable than evidence obtained indirectly. CPCON makes a similar point for evidence obtained directly by the auditor, including physical examination and observation. WallStreetMojo says external documents or third-party confirmations carry greater weight in the audit process.

None of that makes internal records useless. It does make the source and nature of the record part of the argument. A self-reported agent transcript may be useful context. It is weaker if it cannot be tied to the system that actually accepted the change.

That is why a log is a poor synonym for evidence. It names a format or a source. It does not answer sufficiency. It does not answer relevance. It does not answer reliability. A log line can be good evidence, weak evidence, or irrelevant noise.

The same discipline applies to AI audit material. The article on what Singapore’s agentic AI guidance requires firms to evidence is useful because it keeps the focus on the artefact a reviewer can inspect, not on a generic claim that governance exists. That is the right habit even outside that setting.

Audit evidence examples that are not just logs

Audit evidence examples should be read as candidates, not automatic answers. A screenshot, policy document or interview record can be useful. Each can also be stale, incomplete or unrelated to the assertion being tested.

Plurilock’s glossary gives a broad list of possible forms.

"Audit evidence can take many forms: system logs, configuration files, policy documents, interview records, screenshots, network traffic captures, vulnerability scan results, and physical observations."

— What is Audit Evidence?, 2 February 2026

That list makes the boundary clear. System logs can be audit evidence, but audit evidence is not synonymous with system logs. For a machine decision, the better question is which combination of materials supports the conclusion under review.

System logs. A system log may show that an action occurred, when it occurred, and which service reported it. Plurilock includes system logs among the forms audit evidence can take. The weakness is obvious. A log of occurrence may say little about authority.

Configuration files. A configuration file may show how a system was set up when the action was taken. Plurilock also lists configuration files as a possible form of audit evidence. The file is stronger when it can be connected to the relevant time and system, not merely produced as a current-state artefact.

Policy documents. A policy document may show the rule the organisation intended to apply. Plurilock lists policy documents as a possible form of audit evidence. The limit is that a policy does not prove it was applied to a particular attempted action.

Interview records. An interview record may explain a decision or control process. Plurilock lists interview records as a possible form of audit evidence. The weakness is that memory and explanation are not the same as a contemporaneous record.

Screenshots. A screenshot may preserve a screen state or approval view. Plurilock lists screenshots as a possible form of audit evidence. The hard question is whether it captures the point under review or only a nearby display.

Physical observations. Physical observation appears in Plurilock’s list of possible forms and CPCON says evidence obtained directly by the auditor, such as physical examination and observation, is the most reliable. That matters because some evidence is stronger when the auditor obtains it directly rather than through an internal narrative.

Written confirmations. WallStreetMojo gives written confirmations as an example of audit evidence. That is useful for claims where a third party can confirm the relevant fact. It is less useful where the real question is how an internal machine decision was authorised.

Accounting system material. ZenGRC says the accounting system may also act as the source of audit evidence. That does not mean every accounting record is enough. It means the system may be one source in the evidence set.

The examples point to a practical rule. Start with the assertion, not the artefact. If the assertion is “the agent could not delete a protected record,” a deletion log that contains no authority information is not a satisfying answer. If the assertion is “the agent had permission to update this field,” the artefact must support permission, not merely update.

The same problem appears in retention. A short-lived trace may be operationally convenient and still fail as audit evidence if it no longer exists when the question is asked. The article on log retention and statutory time is a useful companion because evidence that expires before review is often indistinguishable from evidence never collected.

What this means if you have to produce evidence

The person who has to produce evidence should resist the first easy answer. Exporting logs is fast. It may also produce a large bundle of material that does not answer the question.

A reviewer asking about a disputed action will usually care about a conclusion. Was the action allowed. Was it blocked. Was it escalated. Was the exception justified. The evidence package should be built around that conclusion.

PCAOB AS 1105 says the auditor should select items for testing to obtain evidence that, in combination with other relevant evidence, is sufficient to meet the objective of the audit procedure. The important phrase is “in combination.” One artefact may not carry the whole weight.

That is uncomfortable for teams that want one master log. It is also the honest answer. A payment release may need the payment event, the permission record, the policy in force, the approval artefact, and the business context that made the action eligible. If one of those pieces is missing, the bundle may still be useful, but the gap should be named rather than hidden.

Evidence also needs preservation discipline. Plurilock says auditors must document the collection process, maintain chain of custody, and ensure evidence integrity to support their findings. That does not prove any particular vendor tool is required. It does mean an after-the-fact screenshot pasted into a ticket should be treated with caution.

The hardest case is not a routine success. It is the near miss, the exception, or the action that should have escalated. A system that records only the final outcome forces the reviewer to infer the control decision from a residue. That inference may be wrong.

For AI agents, this is the central evidence gap. The model output is not the authority. The business action is not the authority. The record has to show why the action was permitted or refused at the moment it mattered.

Practical steps for evidence owners

1. Write the assertion first. State the conclusion the evidence must support. “The agent changed the credit limit” is weaker than “the agent was permitted to change this credit limit under the approved conditions.”
2. Separate occurrence from authority. Keep the event record, but do not pretend it proves permission. A log that records a successful update is evidence of occurrence before it is evidence of authorisation.
3. Map each artefact to relevance. For every screenshot, policy document or system entry, write the assertion it supports. If the mapping is vague, the artefact is probably padding.
4. Record the rule or approval in force. A later reviewer needs the rule that applied when the action happened, not only the current policy. This is especially important when limits, approvers or exception paths change.
5. Preserve enough context. PCAOB Auditing Standard No. 15 says the amount of evidence should increase as risk increases. Treat a record deletion, payment release or credit-limit change as needing more than a generic success event.
6. Show the collection path. Plurilock says auditors must document the collection process, maintain chain of custody, and ensure evidence integrity to support findings. The person reviewing the material should be able to see where it came from and why it can be relied on.
7. Name the gap. If the evidence proves that something happened but not why it was allowed, say that. A disclosed limitation is better than an overclaimed artefact.

Crelis’s position is narrow: GREENLIGHT treats sensitive agent actions as permissioned actions to be checked and recorded, and a demo should start from where agents touch money, customers, records or infrastructure.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• Enforcement Is Not Evidence — context for the distinction between a control action and proof.
• MAS SAFR evidence — a regulator-facing example of the same evidence problem.
• Log retention and statutory time — why evidence that disappears before review is a weak answer.