What Makes Good Audit Evidence? What Auditors Actually Look For

You can have hundreds of screenshots, spreadsheets, tickets, policies, and exports ready for an audit and still struggle to prove that a control actually operated.

The problem is usually not that you collected the wrong file type. It is that the artifact doesn't clearly answer the auditor's question.

Good compliance audit evidence needs to support the specific criterion or control being evaluated. That usually means the reviewer can understand what happened, where the information came from, when it happened, what it applies to, and who was involved where that matters.

Instead of asking, "Will the auditor accept this screenshot?" start with a more useful question: "What does this evidence actually prove?"

What makes audit evidence useful?

ISO defines audit evidence as records, statements of fact, or other information that are relevant to the audit criteria and can be verified.

Those two words, relevant and verifiable, are a useful starting point.

Evidence is relevant when it actually supports the control, requirement, or process being evaluated.

Evidence is verifiable when the reviewer has enough information to establish that what it represents is credible and applicable to the audit.

Consider an access-review control. A policy saying "access is reviewed every six months" is relevant to the organization's documented process. But if the auditor is evaluating whether the review actually took place, the policy alone does not demonstrate operation.

The supporting evidence may instead include a system export, ticket, approval trail, review record, or another artifact showing that the relevant access was reviewed.

The exact artifact depends on the environment and the audit criteria. That is why "acceptable evidence" lists can be misleading when treated as universal rules.

A screenshot is not automatically good evidence.

A spreadsheet is not automatically bad evidence.

A platform export is not automatically sufficient.

The right question remains: “Does it support the claim being tested, and can the reviewer understand and verify what it shows?”

Five questions to ask about any audit evidence

Before you send an artifact to an auditor, run it through five checks.

Is it relevant?

Start with the control, not the evidence folder.

If the auditor wants evidence that terminated users lose access promptly, a general screenshot showing your identity provider exists does not prove the termination process worked.

You need evidence that is tied to the activity being evaluated.

Evidence collection often becomes volume-driven. Teams export everything that seems related, hoping the reviewer will find what they need.

A better approach is to state the control claim first, then select the artifact that supports it.

Can you establish where it came from?

The reviewer should be able to understand the source of the evidence.

A report exported from a system usually carries useful context: system name, account, date, record history, or other metadata. A manually created document may still be useful, but the reviewer may need additional context to understand when and how it was produced.

This is where evidence provenance matters.

For example, if a spreadsheet records a periodic security review, ask whether anything independently supports when that review occurred. Depending on the process, that might be workflow history, an email record, meeting documentation, a ticket, or another source.

The point is not that every record requires "immutable" evidence. That would be too broad. The point is that the artifact should give the auditor enough confidence to understand its origin.

Does it establish the relevant time or period?

Timing matters when the control is time-dependent.

If a policy says a review happens every six months, the evidence should allow the reviewer to determine whether the activity occurred during the relevant period.

That does not mean every screenshot needs a visible timestamp in the corner. It means the evidence package should establish the timing where timing is material to the control.

For system-generated activities, this may already be part of the record. For manual processes, other corroborating evidence may be useful.

Does it show the right scope and context?

Screenshots are particularly vulnerable to context problems.

A cropped screenshot might show that MFA is enabled for one account, but not which environment the account belongs to, whether the configuration covers all relevant users, or whether the setting is current.

More context is not always better. The goal is enough context to understand what the artifact demonstrates.

Look for identifiers relevant to the control: system, environment, user population, configuration scope, review period, control owner, or other applicable information.

Can ownership or action be traced where necessary?

Some controls depend on somebody reviewing, approving, or acting.

In those cases, good evidence should let you connect the activity to the responsible role.

If a risk was accepted, who accepted it?

If an access review was performed, who reviewed it?

If a change required approval, where is that approval recorded?

This also allows you to check another source of audit friction: “Does the evidence show the same owner the policy assigns?”

How do auditors corroborate a document or screenshot?

Audit evidence does not have to exist in isolation.

An auditor or assessor may compare several sources to determine whether the control environment is consistent.

NIST SP 800-53A provides a useful example. Its assessment methodology uses three methods (examine, interview, and test) for obtaining evidence. That is NIST terminology, not a universal rule for every certification or attestation, but the underlying concept is useful.

Suppose the organization has a quarterly access-review control. The evidence picture might include:

• A policy describing the review;
• Records showing reviews were completed;
• An interview with the owner explaining the process;
• System information supporting the population or configuration being reviewed.

Those pieces should not contradict one another.

If the policy says the CTO performs the review quarterly, the interview says Security performs it annually, and the only evidence is an undated spreadsheet, the auditor has several reasons to ask more questions.

The problem is not simply that one file is weak. The overall story is inconsistent.

That is why evidence preparation should not be treated as a document-upload exercise.

Strong vs. Weak audit evidence: Practical examples

The same file type can be weak in one situation and useful in another.

These are not universal acceptance rules. The appropriate evidence depends on the specific audit criteria, period, scope, and control being evaluated.

The practical lesson is simpler: don't submit an artifact just because it looks like audit evidence. Check whether someone outside the process can understand what it demonstrates.

How should teams prepare evidence before the audit?

Evidence preparation should be a validation exercise, not a scavenger hunt. A simple process is:

1. Map each evidence request to the exact control or activity. Know what you are trying to prove before selecting the artifact.
2. Check source and context. Make sure the reviewer can identify the system, process, scope, or population where relevant.
3. Check the relevant time period. If frequency or operating period matters, confirm the evidence supports it.
4. Ask the control owner to validate the evidence. The person who runs the process can often spot gaps that the GRC team cannot.
5. Compare evidence with the policy. Make sure what happened matches what the organization says should happen.
6. Resolve contradictions before fieldwork. Do not wait for the auditor to discover that the policy, owner, and records disagree.
7. Collect evidence through normal operations. Reconstructing an entire year's activity immediately before an audit is both inefficient and more likely to expose gaps.

This approach usually produces a cleaner evidence package because teams stop asking, "What else can we upload?" and start asking, "What is still unproven?"

Validate your audit evidence before formal review with GRSee

The hard part of audit evidence isn't collecting more files. It is connecting each control to information that clearly demonstrates what your organization actually does.

GRSee's Managed Compliance service combines evidence tracking with gap assessment, implementation support, and pre-audit validation so teams can identify missing or contradictory evidence before formal review.

For organizations preparing for an ISO 27001 certification audit or SOC 2 examination, we can help review the control environment, clarify evidence expectations, connect documentation to operational practice, and resolve readiness gaps before they create unnecessary audit friction.

If your evidence folder is full but you are still unsure whether it proves what your controls say, start by testing the evidence against the control, not by collecting more.