Evidence and testing
Evidence an examiner will actually accept.
An auditor does not grade your controls on how good they sound. It grades them on what you can show. Each item you hand over is judged on where it came from, when it was made, whether it is complete, who produced it and whether anyone could have changed it. Get those five right and most requests close on the first pass.
Back to SOC 2 services01 · Five questions
Five questions every item has to answer
If an item can't answer one of these, expect a follow-up request.
- SourceWhich system of record produced it: the identity provider, the code host, the ticketing tool, the HR platform.
- DateA timestamp the system wrote, inside the observation period, that matches when the control should have run.
- CompletenessWhether it shows every occurrence, or only the ones someone chose to show.
- ProducerWho ran the control and who extracted the evidence; the auditor may ask to watch the extraction.
- IntegrityWhether the item could have been edited after the fact. A PDF export from the source beats a retyped spreadsheet.
Auditors call anything your systems generate for them information produced by the entity, often shortened to IPE. Before relying on it, they check it is complete and accurate, typically by seeing how the report was run, what filters were applied and whether its totals agree with another source.
02 · Populations
Populations first, screenshots second
A screenshot shows a moment. A population shows the whole period.
Population export
A list of every occurrence
- Every pull request merged in the period
- Every account disabled after a leaver
- Generated by the system, with the query visible
- Lets the auditor pick the sample
Screenshot
One frame of one screen
- Useful for a configuration at a point in time
- Needs the clock, URL or user visible
- Can't show what happened on other days
- Easy to crop, hard to trust alone
Screenshots still have a place: a password policy setting, an encryption toggle, a branch protection rule. Pair them with a date and the account that took them.
The auditor, not you, chooses which items to test from a population. Offering a hand-picked handful of “good examples” invites the question of what the rest looked like. How samples are sized and drawn is covered in our guide on sampling and deviations.
03 · Evidence types
The kinds of evidence, and what each proves
Different controls leave different trails. Know which trail your control leaves.
- System-generated reports
- User lists, change logs, scan results. Strong when the query and run date are visible.
- Tickets
- Access requests, change requests, incident records. Show who asked, who approved and when, in order.
- Logs
- Authentication, admin actions, backup job output. Strong if retained long enough to cover the period.
- Approvals
- A recorded decision by a named role, before the action it approves. An approval dated after the change proves little.
- Signed documents
- Policy acknowledgements, vendor contracts, board minutes. Show intent and acceptance, not operation.
- Configuration evidence
- Settings exports or screenshots that show how a system was set up on a date.
Asking someone how a control works (inquiry) helps the auditor understand it, but inquiry on its own does not support an opinion that a control operated. Expect it to be paired with inspection, observation or re-performance.
04 · Good vs weak
Good and weak evidence, control by control
Illustrative. Your own control wording decides what counts.
| Control type | Good evidence | Weak evidence |
|---|---|---|
| Quarterly access review | Exported user list per system, reviewer's decisions, tickets for removals, all dated | A meeting invite titled “access review” |
| Removing leavers | HR termination list matched to account-disable timestamps | A checklist ticked by the person who left |
| Change approval | Merged pull requests with an approver other than the author, from the code host | A wiki page describing the review process |
| Vulnerability fixes | Scanner findings with open and close dates against the stated window | A current scan showing zero highs |
| Backup restore | Restore job output, the data checked, and who checked it | A backup schedule screenshot |
| Security awareness | Training platform completion report for the in-scope headcount | Slides from the training session |
| Vendor review | Each in-scope vendor's report reviewed, with notes and a date | A vendor list with no review record |
05 · Why items bounce
Why evidence gets sent back
Most rejections are about provenance, not about the control itself.
- Undated or out of period. No timestamp, or one that falls before the window opened.
- Recreated after the fact. A review “documented” months later. File metadata usually shows it.
- Partial population. A list filtered to one team, one region or one tool without saying so.
- Can't trace the producer. Nobody can say who ran the report or how.
- Evidence of policy, not practice. The document says what should happen; nothing shows it did.
- Doesn't match the control text. The control says monthly; the evidence shows quarterly.
06 · Habits
Habits that keep evidence clean all year
Evidence is cheapest to collect the day the control runs.
- A naming convention. Control ID, date and system in every file name, for example CC6.3_2026-Q2_idp-users.
- Retention set on purpose. Log and ticket retention long enough to cover the period plus fieldwork.
- An evidence calendar. Every recurring control on a shared calendar with an owner, not a team.
- One evidence home. A single restricted folder or platform, with edit rights limited after upload.
- Monthly self-check. A short internal look at what was due and what landed, before gaps grow.
Sources: AICPA attestation standards AT-C section 105 and AT-C section 205 (evidence and examination engagements); AICPA Guide, SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy; TSP section 100, 2017 Trust Services Criteria (revised points of focus, 2022).
Questions about SOC 2 evidence
Does a compliance platform's green tick count as evidence?
It points to evidence. The auditor still wants what sits underneath.
A dashboard status is a summary. The examiner usually asks for the underlying export, ticket or log, and may want to know how the platform collects it, because the platform's output becomes information produced by your entity.
Can we fix a missing record by writing it up now?
No. Back-dated evidence does more harm than a gap.
A control that did not run is a deviation the auditor evaluates. A record created later and presented as if it were made at the time is a far bigger problem, and timestamps usually reveal it. Disclose the gap and fix the process.
Should engineers send evidence straight to the auditor?
Better through one coordinator, from the source system.
One coordinator keeps requests tracked and avoids duplicates. The extraction itself should still come from the system of record, and the auditor may ask to watch it being run.
How long should we keep evidence after the report is issued?
At least until the next period's fieldwork is done; follow your own policy.
Your retention policy decides. In practice teams keep each period's evidence until the following examination is complete, so questions about prior exceptions or carried-over controls can be answered.
Is a photo of a whiteboard or a printed form ever acceptable?
Rarely, and only with a date and an owner.
Physical evidence can support physical controls, such as a visitor log. It needs a visible date, a named owner and a reason it can't come from a system. For anything digital, export from the system instead.
Collect evidence once, the right way.
A SOC 2 readiness assessment maps each control to the evidence it should leave and sets up the calendar that collects it.