Teams preparing for a first audit tend to treat evidence as anything that shows a control ran. Auditors do not. They grade evidence, and the grading is not a matter of taste: it is written into the professional standards they work under.
For a SOC 2 engagement, those are the AICPA's attestation standards. For an ISO 27001 certification audit, they are ISO/IEC 17021-1, which governs certification bodies, and the guidance in ISO 19011 on auditing management systems. The vocabulary differs. The logic is close enough that one mental model serves both.
This article covers the methods auditors use to gather evidence, what makes one piece more reliable than another, and how that should change what you keep.
The four methods auditors use
Almost every test in a SOC 2 report, and most of what happens in an ISO audit, is one of four procedures.
Inquiry. The auditor asks someone how a control works. It is the starting point for nearly every test and the weakest form of evidence on its own. The AICPA standards are explicit that inquiry alone is not enough to conclude a control operated effectively. It has to be corroborated.
Observation. The auditor watches the control being performed, in person or on a screen share. It is stronger than inquiry because the auditor sees the thing happen. Its limit is time: it proves the control ran while someone was watching, and says nothing about the other days of the period.
Inspection. The auditor examines a record: a ticket, an approval, a configuration, a log, a signed policy, a report. Most SOC 2 testing is inspection of samples. Its strength depends on where the record came from and whether it could have been altered.
Reperformance. The auditor carries out the control independently and compares the result with yours. They might rerun the query behind an access review, or check terminations against account deactivations themselves. Reperformance is generally the strongest evidence of operating effectiveness, because it does not depend on your account of what happened.
ISO 19011 describes the same ground in its own terms: interviews, observation, and review of documented information, with the requirement that audit evidence be verifiable. Financial auditors add procedures such as confirmation and analytical review. Those appear less often in a security audit.
What makes evidence more reliable
The AICPA's standards set out a set of reliability principles, and ISO auditors apply very similar judgment. In plain terms:
Independent sources beat internal ones. A record produced by a system your team cannot edit is stronger than a spreadsheet your team maintains.
Evidence the auditor obtains directly beats evidence handed to them. A query the auditor watches you run is stronger than its output emailed later.
Documents beat recollection. A dated approval in a ticket beats someone's memory of approving it.
Originals beat copies. A screenshot is a copy of what a system showed. An export, or the system itself, is closer to the original.
Internal records are stronger when the process that produces them is controlled. A change log is worth more when nobody can deploy without generating an entry.
None of these is absolute. A weak form of evidence can still be sufficient when it is the only kind a control can produce, and the auditor pairs it with something else. A strong form can still fail if it does not address the control as you described it.
The methods side by side
| Method | Example | What it proves | Main limit |
|---|---|---|---|
| Inquiry | Asking the IT lead how laptops are encrypted | How people believe the control works | Never sufficient alone |
| Observation | Watching a new hire's account being provisioned | The control ran at that moment | Covers one moment only |
| Inspection | Reviewing a sample of change tickets and approvals | The control ran for each sampled item | Only as reliable as the record |
| Reperformance | Rerunning the access review query and comparing results | The control produces the right result | Not every control can be rerun |
Auditors almost always combine these. A typical test of a SOC 2 change management control is inquiry of the engineering lead, inspection of the branch protection setting, and inspection of a sample of merged changes for approval. Each method covers a weakness in the others.
How the mix changes with the report type
The mix also depends on what the auditor has to conclude. In a SOC 2 Type I, which covers design and implementation as of one date, inquiry, observation and inspection of a single instance can carry most of the testing. In a Type II, the auditor has to conclude the control operated across the whole period, so inspection of samples and reperformance do most of the work. An ISO 27001 auditor sits somewhere between: they interview widely, observe processes, and inspect records selected by judgment from the period since the last audit.
When the methods disagree, the auditor follows up. If the engineering lead says every change is reviewed and the sample shows two self-merged pull requests, the records carry the weight. The explanation still matters, because it decides whether the auditor sees an isolated miss or a control that does not work.
Relevance is a separate test
Reliability asks whether evidence can be trusted. Relevance asks whether it addresses the control at all.
The most common relevance failure is evidence of the wrong thing. A list of users with MFA enabled is reliable, but it does not show MFA is enforced. A user could disable it tomorrow. The relevant evidence is the policy setting in the identity provider that requires it. Your control description decides what is relevant, which is why loose wording in a control description creates evidence problems later. The SOC 2 security criterion is a useful reference for what each control is meant to show.
Sufficiency is a third question again: how much evidence is enough. For controls that operate many times in a period, that is a matter of sampling, and it deserves its own treatment.
What this means for the records you keep
The ranking above translates into a few habits that make evidence stronger without making it more expensive.
Keep approvals in the system of record. An approval on the pull request or the ticket is inspectable and dated. An approval in a chat thread is a copy of a conversation.
Prefer what systems generate over what people assemble. An export from the identity provider beats a list someone typed up from it.
Capture at the time. A record made when the control ran is stronger than one reconstructed for the auditor, and an auditor will treat a reconstructed record with suspicion.
Keep the context. Who performed the control, when, in which system, and against what population. Evidence without context tends to generate a follow-up request.
Expect to demonstrate. For many controls, the strongest evidence is the auditor watching you produce it, so know how to get each record live.
If you are still working out which controls apply to you, the SOC 2 framework page and the glossary cover the terms your auditor will use.
How TrustLynce helps
Evidence collection pulls records on a schedule from your cloud, identity, HR and code systems, timestamped and attributed, so what you hand the auditor is generated by the system rather than assembled by hand. The records sit alongside the controls they support, ready for sampling.