SOC 2 Evidence:
What Auditors Actually Accept

A SOC 2 auditor accepts an artefact as evidence when it is attributable to a named actor or system, complete against a population they can bound, timely with respect to the period, and produced by a source whose reliability they can establish. Those four properties are not one firm’s house style. They fall out of the attestation standards a SOC 2 examination runs under — AT-C sections 105 and 205, together with the AICPA’s SOC 2 guide — which require the practitioner, where the evidence is information you produced, to evaluate whether it is sufficiently reliable, including by obtaining evidence about its accuracy and completeness. That requirement is why your spreadsheet came back with questions attached while the raw export beside it went into the workpapers, and it is also why sample design cannot begin until the population is settled.

Almost everything on this page describes a Type 2. That distinction has to be made early, because the two report types ask for genuinely different artefacts. A Type 1 opines on the fairness of the description and the suitability of the design of controls as of a specified date. The subject matter is state at a date, so state-at-a-date evidence is the right evidence: a defensible screenshot of the enforced MFA policy, taken on or near the as-of date, is often sufficient and appropriate. Nothing is being asserted about March.

A Type 2 opines on operating effectiveness throughout a period. Now every artefact needs a date inside the period and a population standing behind it, because the auditor is sampling occurrences rather than observing a configuration. The same MFA control that passed on one screenshot in the Type 1 now needs the enrolment report for the full user population, plus the change history proving the policy was not relaxed in month seven.

The trap is predictable and expensive: a team passes the Type 1 on screenshots, keeps the same evidence habits, and discovers in month ten that the source logs behind the last nine months were never retained. Moving from a Type 1 to a Type 2 is mostly a change in evidence discipline, and it should start on day one of the period, not at the end of it.

AT-C 205 requires that when a practitioner uses information produced by the entity, they evaluate whether it is sufficiently reliable — obtaining evidence about its accuracy and completeness, and judging whether it is, in the standard’s phrase, sufficiently precise and detailed. AT-C 320 illustrates the same requirement for a service organisation, listing what it bites on: population lists used to select samples, exception reports, user access lists, reconciliations and system-generated reports. Almost everything you are asked for.

A hand-built spreadsheet is not rejected because anyone doubts your integrity, but because it carries no independent evidence of its own completeness — forcing the auditor to test the compilation before testing the control.

The last is the cheapest control in the exercise: the count in the console must equal the rows in the file. Where manual compilation is unavoidable, declare it early and supply the underlying exports alongside the compiled view. The table below is where those exports actually live in the tools most engagements run on — naming a product is not an endorsement of it, it is the difference between a principle and an instruction.

One rule sits underneath every row: export, do not re-save. Opening a CSV in a spreadsheet application and saving it again strips the provenance that made it acceptable, and an auditor who sees a modified timestamp after the run date will ask what changed between the two.

The most avoidable failure in a first Type 2 is not a missing control. It is a control that operated perfectly and left an artefact since deleted: ninety-day log retention against a twelve-month period; a chat tier that discards the only record of an escalation; a leaver’s mailbox purged, taking a change approval with it.

The sixty-person company above ran exactly into this. Its chat tier discarded messages after ninety days, and two of its three recorded incidents had been escalated and coordinated in chat. By the time fieldwork opened on 2 November 2026, the only surviving record of those two escalations was the incident ticket itself — which is why the ticket, not the conversation, has to be the system of record.

The rule: evidence must survive from the day the control operated to the day the auditor tests it — the period, plus the weeks to fieldwork, plus the firm’s review before release. Period end plus six months is a floor; thirteen months is what we recommend, which for a period ending 30 September 2026 means nothing is deleted before 31 October 2027.

Note where the obligation sits. AT-C 105 requires the CPA firm to assemble its final engagement file within sixty days of releasing the report, and the firm then retains that file for years afterwards under the AICPA’s quality-management and peer-review requirements. Nothing in the attestation standards tells a service organisation how long to keep the logs that file was built from — which is why a ninety-day retention setting survives three audits before it costs someone a Type 2.

Two columns do more work than they look like they should. The owner is a role, never a person, because people leave mid-period and a register that names them goes stale the same week. The retain-until date is a single date across the whole register — period end plus thirteen months — so that retention becomes one decision rather than forty.

This is also the answer to the security objection below. A readiness partner can specify the export and check the reconciliation; it cannot run your production systems, and neither can the CPA firm. Independence is a precondition of the examination, not a preference.

The end-of-period scramble has a calendar, and for the sixty-person company it looked like this: period closed 30 September 2026, request list issued 12 October, populations due 19 October, the auditor’s selections returned 26 October, fieldwork 2–13 November. That gives a small team seven days to produce twelve months of populations, and a further week to locate the specific items selected from them — while also running the business. It produces exactly the evidence described above as weak.

That asymmetry is the whole argument. The continuous model is four commitments: every control has a named owner and a defined artefact, confirmed against the CPA firm’s expected request list before the period starts; every artefact has a capture cadence matched to its frequency; every population is reconciled to its source before it leaves the building; and everything lands in one repository with retention past period end plus six months. The register above is what those four commitments look like written down.

Tranquility Cybersecurity does the readiness half: mapping controls to artefacts, building the evidence register, testing populations for completeness before the CPA firm sees them, and coordinating the examination with independent licensed CPA firms for clients in India, USA, UK, Australia and UAE. The opinion always comes from the CPA firm — we never certify, attest or sign. Readiness starts at a fixed fee from $4,000 for early-stage startups, quoted after scoping. The CPA firm’s attestation fee is separate and billed by the firm.