From the auditor's side of the table: the evidence that passes first time, and the gaps that trigger findings.
Auditors look for evidence that is owned by a named person, dated within the audit period, produced independently rather than self-reported, and clearly traceable back to the specific control it supports. For SOC 2 and ISO 27001, an auditor is not scoring how much evidence you have collected. They are checking whether each item actually proves the control operated as described, for the right period, without needing to take your word for it. Evidence that is generic, undated or self-attested is the single most common cause of audit findings.
Audit-ready evidence has five attributes, and an auditor checks for all five before accepting a control as proven. Missing any one of them turns solid work into a finding, even when the underlying control is genuinely in place.
| Attribute | What it means | Example |
|---|---|---|
| Owned | A named person is accountable for the evidence, not "the team" | Access review signed off by the IT manager, not an anonymous export |
| Dated | The evidence falls inside the specific audit or observation period | MFA report timestamped within the SOC 2 Type II window, not from last year |
| Scope-matched | It covers the system, control or population actually in scope | User list from the production identity provider, not a test environment |
| Independent | Produced by a system or a second person, not a self-written claim | Ticketing system export of change approvals, not a written summary |
| Traceable | Clearly linked to the specific control it is meant to prove | Filed against A.8.24 or the relevant Trust Services Criterion, not a shared folder |
SOC 2 auditors want evidence mapped to the AICPA Trust Services Criteria that shows a control operating over the audit period, not just existing on the day of the review. For a Type I report, evidence needs to prove the control was designed and in place at a single point in time. For a Type II report, the more common request from enterprise buyers, evidence needs to cover an observation window typically running three to twelve months, so auditors sample multiple dates across that window rather than accepting one snapshot. Typical SOC 2 evidence includes access review logs with a named reviewer, screenshots or exports confirming MFA is enforced, onboarding and offboarding records tied to HR system dates, vendor risk assessments and signed data processing agreements, change management tickets showing approval before deployment, and an incident log with detection and resolution timestamps.
ISO 27001 auditors want evidence that ties directly back to the Annex A controls in ISO/IEC 27001:2022 listed in your Statement of Applicability, cross-referenced against your risk assessment and risk treatment plan. An auditor working through an ISO 27001 audit typically samples a handful of controls from each of the four Annex A themes, organisational, people, physical and technological, and asks for the specific record proving that control was operating, not a policy describing how it should work. Typical ISO 27001 evidence includes the risk register and risk treatment plan themselves, training completion records with dates and attendance, the incident register, minutes from management review meetings, and internal audit reports showing findings were tracked to closure. A Statement of Applicability with no matching evidence behind an "implemented" control is one of the fastest ways to turn a routine audit into a nonconformity, which is why writing a Statement of Applicability an auditor will accept matters as much as the underlying controls.
| Control area | What auditors ask for | Where it usually lives |
|---|---|---|
| Access control | A signed-off user access review with named reviewer and date | Identity provider export plus an approval record |
| Change management | Change tickets showing approval before deployment | Ticketing system export |
| Security awareness | Training completion records with dates and pass rates | Learning management system export |
| Vendor management | Vendor risk assessments and signed data processing agreements | Vendor register |
| Incident response | An incident log with detection-to-resolution timestamps | Incident tracker |
| Business continuity | Test results for the BCP or DR plan, with date and outcome | Test report on file |
Good evidence and weak evidence often describe the exact same control, which is why auditors reject far more evidence than they reject controls. Take a quarterly access review, a control almost every SOC 2 and ISO 27001 audit will sample. Good evidence for that control is a dated export from the identity provider, a named reviewer, a record of which accounts were flagged, and proof that flagged accounts were actually revoked or justified. Weak evidence for the same control is an undated screenshot of a user list with no reviewer named and no sign that anyone acted on what they found. Both look like "an access review happened." Only one of them survives an auditor asking a follow-up question.
Every one of these is fixable before an audit starts. None of them are fixable once an auditor has already flagged the gap in a draft report.
Enough evidence is one clean, dated, owned example per control per sampled period, not a folder full of duplicates. Auditors sample; they do not review every record in your environment, so volume does not substitute for consistency. A control with one well-documented instance across every sampled month passes more reliably than a control with a hundred unlabelled screenshots and no clear owner. The practical target is coverage across the full audit period, not exhaustiveness within any single point in time.
Evidence stays organised when it is filed against the specific control it proves from the moment it is collected, rather than gathered retroactively in the weeks before an audit. Most teams that struggle with evidence are not missing controls, they are missing a system for capturing proof as the control runs, so a scramble happens right before the auditor's request list arrives. A simple habit fixes most of this: whenever a control produces a natural artefact, an access review, a signed change ticket, a training completion export, file it against that control the same day, with the date and owner attached, instead of promising to "go back and pull it together later."
The other common failure is evidence living in five different places: a shared drive for policies, a spreadsheet for the risk register, a chat thread for approvals, and someone's inbox for vendor assessments. An auditor reviewing evidence scattered across systems has to trust that nothing was left out, which is a harder sell than an auditor who can open one place and see every control mapped to its proof. CertAssist keeps every control, whether SOC 2, ISO 27001 or one of the other frameworks it supports, on one board with an evidence field attached to each item, so your auditor gets read-only access to a single tidy workspace instead of a shared drive assembled the week of the audit. That will not write your evidence for you. It removes the friction that causes teams to fall behind on capturing it in the first place.
ISO 27001 auditors look for evidence that each Annex A control in your Statement of Applicability is actually operating, not just documented. That means a dated record, a named owner, and a clear link back to the specific control and the risk it addresses, sampled against your risk assessment and risk treatment plan.
IT auditors look for evidence that technical controls, such as access provisioning, patching, logging and backups, operated consistently over the audit period, not just that they exist today. They typically sample specific dates or user accounts and ask you to produce the underlying system export or ticket, not a description of the process.
SOC 2 evidence is the documentation that proves a control mapped to the Trust Services Criteria was designed and, for a Type II report, operated effectively over the observation window. Examples include access review logs, MFA enforcement settings, onboarding and offboarding records, vendor risk assessments and incident tickets.
Reliable audit evidence is produced independently of the person whose work is being checked, dated within the audit period, and traceable to a specific control. A signed-off access review pulled from the identity provider is more reliable than a self-written statement claiming the review happened.
Auditors obtain evidence by requesting system exports, screenshots, tickets, logs and signed documents directly tied to a control, then sampling a subset rather than reviewing everything. For SOC 2 Type II and ISO 27001 surveillance audits, they pick specific dates or transactions within the period and ask you to produce the matching record.
CertAssist gives every control an editable evidence field from the start, so nothing gets assembled in a scramble the week of the audit. Launch price US$225 a month.
See pricing FrameworksFlat $225 a month during the launch, normally $375, or $3,999 a year (12 months for the price of 11). All prices in USD.
CertAssist