Audit evidence

Information collected by an auditor to determine whether a specific control objective or regulatory requirement has been met. To be valid, it must be both sufficient in quantity and appropriate in quality and relevance. Examples include system-generated logs, signed policy documents, or observed demonstrations of a technical process.

Why it matters

Without verifiable proof, an auditor cannot validate that a security control is functioning regardless of verbal assurances. A lack of evidence leads to "exceptions" or "non-conformities" in the final audit report. These failures can cause an organization to lose critical certifications like SOC 2 or face regulatory fines under frameworks such as GDPR. Ultimately, the CISO or Compliance Officer is held accountable for these gaps during executive board reviews.

In practice

During the fieldwork phase of an engagement, an external auditor requests specific artifacts from a control owner via a Request List (RL). These typically include screenshots of user access lists, timestamped change tickets from Jira, or signed onboarding checklists. This process produces a testing worksheet where the auditor maps each piece of evidence to a specific control requirement. In first-year engagements, auditors request larger sample sizes and comprehensive documentation to establish a baseline of trust. Repeat audits usually focus on delta changes and smaller samples based on the historical reliability of the controls.

Worked example

CloudScale Inc. underwent an ISO 27001 audit in October 2023 to verify their Access Control policy. The auditor requested evidence that all terminated employees had their system access revoked within 24 hours for the period between January and September 2023. CloudScale provided a CSV export from Active Directory and corresponding HR termination dates. However, the auditor found three users whose accounts remained active for five days post-termination. This resulted in a "Minor Non-conformity," requiring CloudScale to implement a corrective action plan within 30 days.

Common mistakes

Providing screenshots without system timestamps or date headers, which prevents the auditor from verifying when the evidence was captured.
Relying on verbal walkthroughs as primary proof, which auditors reject because there is no permanent record of the control's operation.
"Data dumping" irrelevant information to overwhelm the auditor, often increasing the risk that the auditor discovers unrelated errors in the larger dataset.
Creating documentation after the audit begins to cover a gap (backdating), which can be flagged as fraudulent and lead to a total loss of trust.

Frequently asked questions

What is the difference between an audit artifact and audit evidence?

An artifact is any raw object, such as a policy document or a log file. It becomes evidence only when it is specifically mapped to a control requirement to prove that a process was followed.

How many samples of evidence are usually required for a SOC 2 audit?

Sample sizes depend on the frequency of the control; for example, a daily control might require a sample of 25 items. Auditors typically follow standard sampling tables based on the total population size.

Can an email be used as valid audit evidence?

Yes, provided it demonstrates authorization or communication relevant to the control. An example is an approval email from a manager for a high-risk firewall change request.

When should a company start collecting evidence for their annual audit?

Collection should be continuous throughout the year rather than performed as a one-time event. Practitioners should maintain "compliance folders" monthly to ensure all required logs and approvals are archived.

What happens if we cannot produce the logs requested by an auditor?

The auditor will mark the control as "not tested" or "ineffective." This typically results in a finding because the organization cannot prove the control operated consistently throughout the entire audit period.