Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What evidence will a SOC 2 auditor request?
Last verifiedExpect complete populations plus sampled artefacts per control area: access provisioning and removal records, periodic access reviews, change approvals, deployment records, vulnerability findings with remediation dates, incident tickets, vendor reviews, training completions, and policy acknowledgements — all dated inside the period.
SOC 2 auditor evidence requests, last verified 10 September 2026 against the AICPA Trust Services Criteria (TSP section 100 — 2017 criteria with the 2022 revised points of focus) and the AICPA attestation standards SSAE 18, AT-C sections 105 and 205. SOC 2 is an attestation examination performed by a licensed CPA firm and delivered as an opinion — a report, not a certification. This page is not legal advice, does not determine that YOU need SOC 2, and does not issue a SOC 2 report.
This is a catalogue, not YOUR request list
Audience: an engineering lead, IT owner, or compliance owner who wants to gather artefacts before the request list lands. Your firm's actual list depends on your scope, your criteria categories, and their risk assessment. This page does not determine that YOU need SOC 2, does not replace the firm's list, and does not issue a SOC 2 report.
What counts as sufficient appropriate evidence is the practitioner's judgement under SSAE 18 — AT-C sections 105 and 205. You cannot argue an artefact into sufficiency, and no tool can certify one. Only a licensed CPA firm can perform a SOC 2 examination and issue the report; compliance-automation tooling, including this product, is not the attestor.
Type I addresses the design of controls at a point in time; Type II addresses operating effectiveness over a review period. That distinction is the whole reason a screenshot taken today is weak evidence for a period that started nine months ago. SOC 2 is market and contractual, not statutory: no statute requires a SOC 2 report. "SOC 2 certified" is a misnomer — there is no SOC 2 certificate. Last verified 10 September 2026. Not legal advice.
- The Trust Services Criteria are proprietary AICPA material. This page cites criteria series references — CC1 through CC9 — and paraphrases subject areas. It never reproduces the licensed criterion text.
- Two categories of request exist and are often confused: the complete population of events, and the specific sampled items. Failing to distinguish them is the most common source of rework.
Evidence by criteria series
For each area: the population the practitioner will ask for, the artefacts sampled from it, and what makes an artefact weak. Labelled by kind of text so recommendations are not mistaken for requirements.
| Series | Population requested | Sampled artefacts | What makes it weak |
|---|---|---|---|
| CC1 — control environment | All personnel active during the period, with hire dates; the training programme roster. | Signed policy acknowledgements, training completion records, background-check records where lawful, evidence of leadership or board oversight. | Training "available" but not completed; acknowledgements without dates; an oversight claim with no record of any discussion. |
| CC2 — communication and information | Policy versions published during the period; reports raised through the security channel. | Policy version history with effective dates, the channel itself, examples of concerns raised and their disposition. | A policy folder nobody can find; a channel with no traffic and no evidence anyone knows about it. |
| CC3 — risk assessment | Risk assessments performed during the period; the risk register with its change history. | The dated assessment, ratings and owners, treatment decisions, evidence of who accepted residual risk. | An undated document; a register that has not changed all period; risks with no named owner. |
| CC4 — monitoring | All internal control reviews and self-assessments during the period; the deficiency log. | Review records with reviewer and date, deficiencies with remediation dates, escalation evidence. | Reviews performed in one burst just before fieldwork; deficiencies logged and never closed or explained. |
| CC5 — control activities | The control register as it stood during the period; approvals for controls requiring separation of duties. | Control-to-risk mapping, evidence each control ran, approvals showing requester and approver are different people. | Self-approval; a control register written after the period it describes. |
| CC6 — logical and physical access | All joiners, movers, and leavers; all privileged accounts; all access reviews; all in-scope systems and their authentication configuration. | Provisioning tickets with timestamps, deprovisioning evidence showing access actually removed, completed access reviews with reviewer names and outcomes, single sign-on and multi-factor configuration exports, encryption settings, the cloud provider's own report where facilities are carved out. | Deprovisioning "done" with no timestamp; an access review with no evidence anything was changed; a configuration screenshot taken after the period ended. |
| CC7 — system operations | All production incidents; all vulnerability findings and their status; alerting configuration and alert volume for the period. | Incident tickets with timeline and post-incident review, findings with severity and remediation dates, sampled alerts with their disposition, evidence the incident plan was exercised. | Incidents recorded only in chat; a scan run once at the end; alerts nobody triaged. |
| CC8 — change management | The complete population of production changes for the period, including infrastructure and emergency changes. | Pull requests with independent approval, pipeline records for tests and deployment, change tickets, evidence the emergency path was followed and reviewed afterwards. | Changes deployed outside the pipeline with no record; approvals by the change author; a population that visibly omits a system. |
| CC9 — risk mitigation | All vendors and business partners in scope; all vendor reviews during the period; continuity or recovery tests. | Vendor inventory with tiering, review records, subservice organisation reports obtained and read, contract security terms, recovery test results. | A vendor list with no review dates; a subservice report downloaded but never read; a recovery plan never tested. |
What good evidence looks like
The practitioner decides sufficiency, but the attributes below are what commonly separates a smooth request cycle from a long one. Best practice throughout, not requirements you can point at in a standard.
- Dated at creation, not at collection. An artefact whose only date is when you exported it proves the export.
- Sourced from a system of record with a reproducible query or export path, so completeness can be demonstrated.
- Attributable to a named person for controls that require human action — a review with no reviewer is not a review.
- Self-contained: a ticket that references a decision made in a private message forces the practitioner to chase it.
- Consistent with your policy. Evidence showing a quarterly review performed twice a year contradicts the policy that promised four.
- Complete across the period for a Type II, not clustered in the final weeks. Clustering is visible and invites questions about whether the control operated throughout.
Two ways to lose a report
Both of these are avoidable, and one of them is unrecoverable. Stated bluntly because the temptation is real under deadline.
- Fabricated or back-dated evidence. Do not create an artefact to represent an event that did not happen, and do not adjust a date. It is a misrepresentation to the practitioner, it can invalidate the engagement, and it converts a control problem — which is survivable and common — into a question about management integrity, which is not.
- Point-in-time evidence offered for a period. A single screenshot showing multi-factor authentication enabled today says nothing about the nine months before it. For a Type II the practitioner is testing operating effectiveness across the period, so evidence has to span it. A Type I is the report type where point-in-time evidence is the right answer.
- If evidence for part of the period genuinely does not exist, say so. A disclosed gap becomes an exception the practitioner evaluates. A concealed gap becomes a credibility problem, and management responses in the report are read closely by exactly the people you are trying to convince.
Kinds of text on this page
Different sentences here carry different weight. The table labels which is which, so a recommendation is never handed to an auditor as an obligation.
| Kind of text | What it means | What it is not |
|---|---|---|
| Attestation-standard requirement | SSAE 18 — AT-C sections 105 and 205 — including that the practitioner obtain sufficient appropriate evidence and that populations support the testing. | Not a statute, and it binds the practitioner rather than you. |
| Trust Services Criteria reference | A pointer to a criteria series (CC1–CC9 or an optional category) in TSP section 100. | Not the criterion text. The Trust Services Criteria are proprietary AICPA material; every description here is paraphrase. |
| Best practice | Evidence habits that make a request cycle short — dating, attribution, reproducible exports. | Not required by any attestation standard. Skipping it is not an exception. |
| Market observation | What request lists and firms are commonly observed to include. | Not a rule, and not a prediction of YOUR firm's list. |
| SRM recommendation | Something this product suggests doing, including how to collect evidence continuously. | Not a legal requirement, not an attestation requirement, and not an audit opinion. |
What to do now
Work populations first. Sampled artefacts are easy once the population behind them is complete and reproducible.
- For each criteria series in the table, write down the system of record and the export that yields the complete population. Run it today and look at the output.
- Check the two highest-volume areas — access and change — before anything else, and confirm every production change and every access removal is captured.
- Turn on dated evidence capture now, even mid-period. Partial coverage disclosed honestly beats a reconstruction.
- Read your policies and reconcile the cadences they promise with what your evidence shows. Change whichever is wrong.
- Obtain and actually read the reports of subservice organisations you carve out, and note the complementary controls they push back to you.
- Do a dry run: pick five items yourself from each population and try to produce the evidence. The gaps you find are the exceptions you avoid.
- Never fabricate or back-date. If it does not exist, disclose it.
Checklist
An evidence-readiness list, labelled by kind of text. Not the firm's request list.
- Every population has a named system of record and a reproducible export. Attestation-standard requirement for completeness; the export path is best practice.
- Access provisioning, removal, and review records exist with dates and named reviewers. Trust Services Criteria reference CC6.
- Change population is complete, including infrastructure and emergency changes, with independent approvals. Trust Services Criteria reference CC8.
- Vulnerability findings carry severity and remediation dates across the period. Trust Services Criteria reference CC7.
- Incident records include timeline and post-incident review. Trust Services Criteria reference CC7.
- Vendor reviews and subservice reports obtained and read. Trust Services Criteria reference CC9.
- Evidence spans the whole period rather than clustering before fieldwork. Attestation-standard requirement in effect for Type II.
- Nothing has been fabricated or back-dated, and known gaps are written down for disclosure. Best practice, and non-negotiable.
Where this shows up in ShipReady Metrics
The bundled framework key soc2 is customer-visible, labelled against the 2017 Trust Services Criteria with the 2022 revised points of focus, with a starter control-set that is an illustrative readiness mapping to be tailored by a compliance owner.
If you already have a session: evidence collection is where artefacts accumulate with their dates, which is the difference between a period that is evidenced and one that is reconstructed. Evidence review with the met-verdict overlay records a named human's judgement that an item supports a control — a judgement, never an opinion. Connector-sourced evidence covers part of the CC7 and CC8 rows directly: dependency findings, code-scanning results, and secret-scanning results ingest continuously with their own timestamps. The policies library holds the documents the CC1 and CC2 rows need. The 24-framework crosswalk maps SOC 2 to canonical controls by criteria series reference only, never reproducing Trust Services Criteria text, and mapped coverage is not a count of criteria met. ShipReady Passport and the auditor share token hand a reviewer a scoped view. The cyber risk register under the security area supports CC3 and CC4.
This product does not decide whether evidence is sufficient, does not sample, and does not form an opinion. Readiness in this product is not an attestation opinion. This product does not issue a SOC 2 report and does not replace a licensed CPA examination. There is no public SOC 2 demo URL.
Primary sources (last verified 10 September 2026)
Evidence and population requirements come from the AICPA attestation standards. Criteria series references come from TSP section 100, paraphrased because the criterion text is licensed.
AICPA attestation standards SSAE 18, AT-C section 105 and AT-C section 205, including the requirement that the practitioner obtain sufficient appropriate evidence. AICPA Trust Services Criteria, TSP section 100 — 2017 criteria with the 2022 revised points of focus, organised into the common criteria series CC1 through CC9 plus optional categories. Proprietary AICPA material: cited by reference and paraphrased, never reproduced. AICPA SOC 2 guidance for service organisations. These are not a complete list, and none of them is legal advice.
The SOC 2 framework guide on this site is the education page under frameworks; this cluster does not reuse that slug. The SOC 2 readiness checklist template on this site is live. The SOC 2 versus ISO 27001 comparison on this site is live. A dedicated ISO 27001 docs cluster is not on this site yet — naming ISO 27001 in prose is not a link to it.