What Is Audit Evidence?

Where does the definition of audit evidence come from?

The definition above is from PCAOB Auditing Standard 1105, which governs audits of public companies in the United States. The AICPA's AU-C 500 uses nearly identical wording for private company audits. SOC 2 examinations are attestation engagements under AICPA standards rather than financial statement audits, but auditors apply the same evidence concepts when they test controls.

The key idea is that evidence exists to support a conclusion. An auditor testing whether access is removed at termination needs evidence that connects a list of terminated employees to the timing of their account deactivation. A folder of unrelated screenshots does not support that conclusion, no matter how large it is.

Evidence always attaches to a specific security control and its objective. That is why the frameworks you are audited against, such as SOC 2 or ISO 27001, shape what evidence you need to produce.

What are the types of audit evidence?

AS 1105 lists the audit procedures that generate evidence. Each one produces a different kind of evidence with a different level of strength.

In practice, inquiry alone rarely supports reliance on a control. Auditors pair it with inspection or reperformance. Reperformance is the strongest procedure for automated controls, which is one reason engineered evidence holds up well: an auditor can rerun the same script and get the same answer.

What makes audit evidence sufficient and appropriate?

Sufficiency is quantity. AS 1105 says the amount needed depends on the risk involved and on the quality of the evidence: higher quality evidence means less of it is needed. Appropriateness is quality, and it has two parts. Relevance is the evidence's relationship to the assertion or control objective being tested. Reliability depends on the nature and source of the evidence and the circumstances under which it was obtained.

AS 1105 describes several reliability patterns that apply directly to security evidence:

• Evidence from a knowledgeable source independent of the company is more reliable than evidence from internal sources only.
• Company-generated information is more reliable when the controls over it are effective.
• Evidence the auditor obtains directly is more reliable than evidence obtained indirectly.
• Original documents are more reliable than copies or converted versions, whose reliability depends on the controls over the conversion.

The standard also addresses information produced by the company, often called IPE. When an auditor relies on a report you generated, they must test its accuracy and completeness, or test the controls over it, including IT general controls. This is where many automated evidence programs stumble. If your script only queries one AWS region, the output is accurate but incomplete, and the auditor cannot rely on it.

What is an example of weak versus strong audit evidence?

The same control can be supported by very different evidence. The difference usually comes down to population coverage, timestamps, and whether the auditor can reproduce the result.

For a longer treatment of why the left column fails under scrutiny, read why screenshots are weak audit evidence.

How do you automate audit evidence collection?

Automated evidence starts with a script or pipeline that pulls data straight from the system of record, then records enough metadata for an auditor to trust and reproduce it: what was collected, from where, when, by what identity, and a hash proving it was not altered. The Python example below collects the AWS IAM credential report, which lists every IAM user with password and MFA status:

import hashlib
import json
import time
from datetime import datetime, timezone

import boto3

iam = boto3.client("iam")

# Ask AWS to build the credential report, then wait for it
while iam.generate_credential_report()["State"] != "COMPLETE":
    time.sleep(2)
report = iam.get_credential_report()
content = report["Content"]  # CSV bytes covering every IAM user

metadata = {
    "control": "IA-2",
    "source": "iam:GetCredentialReport",
    "account": boto3.client("sts").get_caller_identity()["Account"],
    "collected_at": datetime.now(timezone.utc).isoformat(),
    "report_generated_at": report["GeneratedTime"].isoformat(),
    "sha256": hashlib.sha256(content).hexdigest(),
}

with open("iam-credential-report.csv", "wb") as f:
    f.write(content)
with open("iam-credential-report.meta.json", "w") as f:
    json.dump(metadata, f, indent=2)

Run on a schedule and written to storage with object lock or versioning, this turns a once-a-year scramble into a continuous record. Loop it across every account in your organization and the completeness question is answered by design. The same pattern extends to identity providers, code repositories, and ticketing systems.

AI now helps here as well, from summarizing evidence to mapping it to controls. The tradeoffs are covered in AI for compliance evidence. For the monitoring layer that keeps evidence current, see continuous compliance monitoring. If you sit on the auditor side, the CGE-AUD auditor specialty covers how to evaluate engineered evidence.

Frequently Asked Questions