Is there an official SOC 2 evidence list?

No. The AICPA publishes the Trust Services Criteria, not a list of documents. The auditor decides what to request based on the controls you describe, so the evidence list for your examination comes from your own control set. The checklist on this page is a starting point mapped to the criteria, not a request list from any CPA firm.

What is the difference between Type I and Type II evidence?

A Type I report covers the design of your controls at a single date, so the evidence shows that a control exists and is set up as described: an approved policy, a configuration screenshot, a walkthrough. A Type II report covers whether the controls operated over a period, so the evidence has to show the control running throughout that period: dated tickets, review records and logs from across the whole window.

Can I create evidence after the fact?

No. Evidence has to be produced when the control runs. A quarterly access review written up months later, or a training record backdated to fit the period, is not evidence that the control operated. If a control did not run, the honest answer is to say so; the auditor will treat it as an exception either way.

Do I need a compliance platform to collect evidence?

Not necessarily. Many small companies keep evidence in a shared folder organized by criterion or control, with a spreadsheet that tracks owner, cadence and where each item lives. A platform can automate collection from your tools, but the auditor tests the evidence, not the system it is stored in.

Who should own evidence collection?

Each control should have an owner who produces its evidence as part of running it, for example the engineering lead for change review or the person who runs onboarding for access requests. One person usually coordinates the folder and the auditor's requests, but evidence collected by someone who does not run the control tends to arrive late and incomplete.

SOC 2 evidence checklist

A SOC 2 examination is decided by evidence: the records your controls leave behind when they run. This page lists 130 evidence items across the 38 criteria this site maps, grouped by series and linked to the policy that documents each one. Download the whole list as a CSV and use it as the skeleton of your evidence folder.

130 rows, built in your browser. Opens in Excel, Numbers or Google Sheets.

What counts as evidence

Evidence is anything that shows a control was designed as described and, for a Type II report, that it actually ran. In practice that means tickets, dated exports, configuration screenshots, signed forms, review records, logs and meeting notes. A policy is evidence that a control was defined and approved; it is not evidence that the control operated.

The useful split is between design evidence and operating evidence:

Design evidence (Type I and Type II). Shows the control exists and is set up the way you say it is: the approved policy, the branch protection setting, the MFA enforcement rule, the backup schedule. A Type I report is an opinion on design at a single point in time, so this is most of what it needs.
Operating evidence (Type II). Shows the control ran throughout the observation period: the access reviews for each quarter, the pull requests with approvals, the onboarding tickets, the restore tests. It has to come from inside the period and be dated, which is why it cannot be assembled at the last minute.

See Type I vs Type II for what else changes between the two report types.

How auditors sample

For a Type II examination the auditor rarely looks at every instance of a control. They ask for a population, pick a sample from it, and request evidence for each item in the sample. The terms are worth knowing because the requests are phrased in them:

Population. The complete list of times a control should have run during the period: every new hire, every leaver, every production change, every quarterly review. You produce it, usually from the system of record, and it has to be complete, because the sample is only meaningful if nothing was left out.
Sample. The items the auditor selects from the population. For each one you provide the evidence that the control operated: the approval, the deactivation timestamp, the reviewer sign-off.
Period. The window the report covers. Evidence dated outside it does not count, and a control that runs less often than the period, such as an annual risk assessment, still has to have run inside it.

Sample sizes depend on how often a control runs and on the CPA firm’s own methodology, so ask your auditor rather than relying on a number from the internet. Controls that run rarely, such as an annual review, are often tested in full. Automated controls, such as an enforced configuration, are usually tested by inspecting the setting and how changes to it are controlled, rather than by sampling occurrences.

How to organize an evidence folder

The structure matters less than being able to find any item in a minute when the auditor asks. A layout that works for most small teams:

One folder per criterion or per control. Using the criterion ids, for example CC6.2, keeps the folder aligned with the checklist and the auditor’s request list. If one control covers several criteria, file it once and reference it from the others.
Dated file names. Put the date the evidence was produced at the start of the name, for example 2026-07-01 access review production.pdf, so the period coverage is visible without opening anything.
A tracking sheet. One row per evidence item with the owner, the cadence, the location and the date last collected. The CSV on this page has the first columns; add the owner and cadence for your company.
Populations kept next to samples. Store the full list of hires, leavers or changes for the period alongside the evidence for the sampled items, so you can show the population was complete.
Restricted access. Evidence often contains employee names, system configuration and customer details. Share the folder only with the people who need it and the audit team.

Common evidence gaps

The same problems come up in most first examinations, and almost all of them are about timing rather than missing tools:

Controls that only exist in the policy. The policy says access is reviewed quarterly, but the first review happens during fieldwork. A written commitment your own records contradict is worse than no commitment.
Undated screenshots. A screenshot with no date or system name cannot be tied to the period. Capture the URL, the account and the date in the image, or export from the system instead.
Incomplete populations. An offboarding list that misses contractors, or a change list that misses infrastructure changes made outside the main repository.
Approvals recorded after the fact. A ticket approved after the access was granted shows the control did not run in the order the policy describes.
Annual controls that never happened. Risk assessment, vendor review, policy review, security training and restore tests are easy to forget because they come around once a year.
Missing acknowledgments. Staff who joined mid-period without signing the policies; see policy acknowledgment for how to close this one.
No vendor reports on file. Critical vendors with no SOC 2 report or questionnaire collected; see where to get vendor SOC 2 reports.

The evidence checklist, by series

Each table lists the criteria in one series, the evidence a small SaaS company can realistically produce for each, and the policies that document the control. The rows come from the same crosswalk the generator and the Audit Kit use. Follow a criterion for its own page, or a policy for the section an auditor would read. The evidence items are examples: your controls decide what your auditor will actually request.

CC1 Control environment

Criterion	Evidence to collect	Policies
CC1.1 Integrity and ethical values	Signed Acceptable Use Policy acknowledgment forms for every employee and contractor Employee handbook or code of conduct section referenced by the Information Security Policy Approved Information Security Policy with the approver's name and effective date on the revision table	P01 Information Security Policy, P02 Acceptable Use Policy, P18 Human Resources Security Policy
CC1.2 Oversight by leadership	Leadership or board meeting notes showing a security update as an agenda item at least twice a year Memo or email appointing the Security Owner, signed by the approver Annual risk assessment summary presented to leadership with the date it was reviewed	P01 Information Security Policy, P17 Risk Assessment and Management Policy
CC1.3 Structure, reporting lines and authority	Current org chart exported from the HR or identity system Roles and Responsibilities section of the Information Security Policy naming the Security Owner, Engineering Lead and approver Policy owner column of the Policy Review Calendar showing one named owner per policy	P01 Information Security Policy, P17 Risk Assessment and Management Policy
CC1.4 Competent people	Job descriptions for security-relevant roles listing security responsibilities Background check completion records or vendor confirmations for hires in the audit period Security awareness training completion report for all staff within 30 days of hire and annually	P18 Human Resources Security Policy
CC1.5 Accountability	Enforcement sections of the approved policies describing the disciplinary process Performance review template that includes adherence to company policies Signed policy acknowledgment forms collected at onboarding and after each annual review	P01 Information Security Policy, P02 Acceptable Use Policy, P18 Human Resources Security Policy

CC2 Communication and information

Criterion	Evidence to collect	Policies
CC2.1 Quality information	Asset inventory export (MDM device list plus cloud resource inventory) with owner and classification columns Log retention configuration screenshot from the logging tool showing retention of at least 12 months for security logs Risk register spreadsheet with last-updated date and Security Owner sign-off	P05 Asset Management Policy, P12 Logging and Monitoring Policy, P17 Risk Assessment and Management Policy
CC2.2 Internal communication	Onboarding checklist showing policy distribution and security training as required steps Signed policy acknowledgment forms for every active employee Screenshot of the internal incident reporting channel or address referenced in the Incident Response Policy Announcement to staff when a policy is updated (email or chat message with date)	P01 Information Security Policy, P13 Incident Response Policy, P18 Human Resources Security Policy
CC2.3 External communication	Public security page or trust page URL and a dated screenshot Published privacy notice with the date it was last updated Customer incident notification template from the Incident Response Policy procedures Contract or DPA clause stating customer breach notification timelines	P13 Incident Response Policy, P16 Vendor and Third-Party Risk Management Policy, P22 Privacy and Data Protection Policy

CC3 Risk assessment

Criterion	Evidence to collect	Policies
CC3.1 Objectives for risk assessment	Risk assessment scope statement naming the in-scope product, environments and Trust Services Categories Information Security Policy section listing the company's security objectives and commitments System description or architecture diagram used as the input to the annual risk assessment	P01 Information Security Policy, P17 Risk Assessment and Management Policy
CC3.2 Identifying and analyzing risks	Completed annual risk register with likelihood, impact, treatment and owner columns Vendor risk assessment records for critical vendors (SOC 2 report review notes or security questionnaire) Meeting notes or ticket showing leadership approval of the risk treatment plan	P16 Vendor and Third-Party Risk Management Policy, P17 Risk Assessment and Management Policy
CC3.3 Fraud risk	Risk register entries tagged as fraud or insider-threat risks with their treatments Segregation-of-duties statement in the Access Control Policy and a screenshot showing production deploys require a second approver Background check policy statement and completion records for roles with privileged access	P03 Access Control Policy, P17 Risk Assessment and Management Policy, P18 Human Resources Security Policy
CC3.4 Changes that affect risk	Risk register revision history showing an update tied to a major change in the period Change ticket for a significant architecture change with a risk review field completed Policy Review Calendar entry showing an out-of-cycle review triggered by a change	P09 Change Management Policy, P17 Risk Assessment and Management Policy

CC4 Monitoring activities

Criterion	Evidence to collect	Policies
CC4.1 Ongoing and separate evaluations	Annual internal control self-assessment using the Evidence Checklist, signed by the Security Owner Most recent penetration test report and remediation tracker Vulnerability scan reports from the last quarter showing scan dates and findings Quarterly access review spreadsheet signed by the Security Owner	P01 Information Security Policy, P11 Vulnerability and Patch Management Policy, P17 Risk Assessment and Management Policy
CC4.2 Communicating deficiencies	Remediation tracker (spreadsheet or issue board) with owner, due date and status for each open finding Incident post-mortem documents with action items and their completion dates Leadership update summarizing open security findings and their status	P01 Information Security Policy, P13 Incident Response Policy, P17 Risk Assessment and Management Policy

CC5 Control activities

Criterion	Evidence to collect	Policies
CC5.1 Selecting control activities	TSC Crosswalk mapping each criterion to the policy section that addresses it Risk register treatment column linking each risk to a control or policy Approved policy set with version numbers and effective dates	P01 Information Security Policy, P17 Risk Assessment and Management Policy
CC5.2 Technology controls	Cloud IAM configuration export showing role-based groups rather than individual grants Branch protection settings export for production repositories Infrastructure-as-code repository with pull request history for infrastructure changes	P03 Access Control Policy, P09 Change Management Policy, P20 Network and Infrastructure Security Policy
CC5.3 Policies and procedures	Complete policy set with approver, version and effective date on every revision history table Policy Review Calendar with owner and next review date for each policy Signed policy acknowledgment forms for all staff Record of the last annual policy review (meeting notes or approval email)	P01 Information Security Policy, P18 Human Resources Security Policy

CC6 Logical and physical access controls

Criterion	Evidence to collect	Policies
CC6.1 Logical access security	Identity provider MFA enforcement policy screenshot (for example the Okta or Google Workspace admin console) Cloud IAM role and group listing for the production account Encryption-at-rest settings screenshot for the production database and object storage Password manager admin report showing enrollment of all staff	P03 Access Control Policy, P04 Authentication and Password Policy, P08 Encryption and Key Management Policy, P20 Network and Infrastructure Security Policy
CC6.2 User registration and deprovisioning	Onboarding access request tickets showing manager approval before account creation Offboarding checklist and identity provider deactivation timestamp for each leaver in the period Quarterly access review spreadsheet comparing active accounts to the HR roster, signed by the Security Owner	P03 Access Control Policy, P18 Human Resources Security Policy
CC6.3 Role-based access and least privilege	Role-to-permission matrix for production systems (identity provider groups, cloud IAM roles, source control teams) Quarterly access review spreadsheet with removals noted and Security Owner sign-off Identity provider admin role listing showing a small named set of administrators Access change tickets for privilege escalations in the period with approval recorded	P03 Access Control Policy
CC6.4 Physical access	Cloud provider SOC 2 Type II report (or bridge letter) covering data center physical security Office access badge or key holder list reconciled against the HR roster Remote work security statement acknowledged by remote staff	P21 Physical and Remote Work Security Policy
CC6.5 Disposal of physical assets	MDM remote-wipe confirmation for laptops returned by leavers in the period Asset inventory entries marked disposed with the wipe date and method Certificate of destruction from the recycling or ITAD vendor, where used	P05 Asset Management Policy, P07 Data Retention and Disposal Policy, P21 Physical and Remote Work Security Policy
CC6.6 Protection from external threats	Cloud security group or firewall rule export for production showing no unrestricted inbound admin ports WAF or edge protection configuration screenshot MFA enforcement screenshot for the identity provider, source control organization and cloud console MDM compliance report showing disk encryption and firewall enabled on all managed devices	P04 Authentication and Password Policy, P19 Endpoint and Workstation Security Policy, P20 Network and Infrastructure Security Policy
CC6.7 Data in transit and on removable media	TLS configuration scan result for public endpoints (for example an SSL Labs report) showing TLS 1.2 or higher only Data handling matrix from the Data Classification Policy listing approved sharing channels per classification MDM policy screenshot restricting USB storage or requiring encrypted external drives	P06 Data Classification and Handling Policy, P08 Encryption and Key Management Policy, P19 Endpoint and Workstation Security Policy
CC6.8 Malicious software	Endpoint protection or EDR console report showing coverage of all managed devices MDM configuration restricting software installation to approved sources Dependency scanning configuration and recent results from the source control platform Patch compliance report from MDM for operating system updates	P10 Secure Software Development Policy, P11 Vulnerability and Patch Management Policy, P19 Endpoint and Workstation Security Policy

CC7 System operations

Criterion	Evidence to collect	Policies
CC7.1 Detecting vulnerabilities and configuration changes	Vulnerability scanner configuration and last quarter's scan reports Remediation tracker showing critical and high findings closed within the policy's SLA Cloud configuration monitoring alerts (for example AWS Config or GCP Security Command Center) export Infrastructure-as-code drift detection output or pull request history for the period	P11 Vulnerability and Patch Management Policy, P12 Logging and Monitoring Policy, P20 Network and Infrastructure Security Policy
CC7.2 Monitoring for anomalies	Logging tool alert rules export (for example Datadog monitors) covering authentication failures, privilege changes and production errors Sample alert notification with timestamp and the on-call response Centralized logging dashboard screenshot showing production log sources On-call rotation schedule or escalation configuration	P12 Logging and Monitoring Policy, P13 Incident Response Policy
CC7.3 Evaluating security events	Incident severity classification table from the Incident Response Policy Incident log for the period showing triage decisions, including events that were closed as non-incidents Ticket or chat thread for a sample security alert showing the evaluation and outcome	P12 Logging and Monitoring Policy, P13 Incident Response Policy
CC7.4 Responding to incidents	Approved Incident Response Policy with contact details and severity levels Incident record for at least one real or tabletop incident showing detection, containment, communication and closure Annual tabletop exercise notes with attendees, scenario and lessons learned Customer notification template and record of any notifications sent	P13 Incident Response Policy
CC7.5 Recovering from incidents	Post-mortem document for each significant incident with root cause and follow-up actions Remediation tracker entries created from post-mortem action items and their closure dates Backup restore test record used as part of incident recovery or recovery testing	P13 Incident Response Policy, P14 Business Continuity and Disaster Recovery Policy, P15 Backup and Recovery Policy

CC8 Change management

Criterion	Evidence to collect	Policies
CC8.1 Change management	Branch protection settings export requiring pull request review and passing checks before merge Sample of merged pull requests from the period showing reviewer approval and CI status CI/CD pipeline configuration file showing automated tests and the production deploy step Emergency change record showing after-the-fact review, if any occurred	P09 Change Management Policy, P10 Secure Software Development Policy

CC9 Risk mitigation

Criterion	Evidence to collect	Policies
CC9.1 Mitigating business disruption risk	Business continuity and disaster recovery plan with recovery time and recovery point objectives per system Risk register entries for availability and disruption risks with treatments Cyber insurance policy summary or documented decision not to carry it	P14 Business Continuity and Disaster Recovery Policy, P15 Backup and Recovery Policy, P17 Risk Assessment and Management Policy
CC9.2 Vendor and business partner risk	Vendor inventory with data access level, criticality tier and review date for each vendor SOC 2 report review notes or completed security questionnaire for each critical vendor Signed vendor DPA or contract with security and confidentiality clauses Annual vendor review record signed by the Security Owner	P16 Vendor and Third-Party Risk Management Policy, P22 Privacy and Data Protection Policy

A1 Availability

Criterion	Evidence to collect	Policies
A1.1 Capacity management	Capacity or utilization dashboard screenshot from the monitoring tool (CPU, memory, storage, database connections) Alert rules for capacity thresholds with the person or channel they notify Autoscaling configuration export or documented capacity review notes	P12 Logging and Monitoring Policy, P14 Business Continuity and Disaster Recovery Policy, P20 Network and Infrastructure Security Policy
A1.2 Environmental protections, backups and recovery infrastructure	Backup configuration screenshot showing schedule, retention and encryption for production data Cloud provider SOC 2 report covering environmental controls for the regions in use Architecture diagram showing multi-availability-zone or multi-region deployment for critical services Backup job success report for the last 90 days	P14 Business Continuity and Disaster Recovery Policy, P15 Backup and Recovery Policy, P21 Physical and Remote Work Security Policy
A1.3 Recovery testing	Backup restore test record with date, dataset restored, time taken and who performed it Annual disaster recovery exercise report with scenario, results and follow-up actions Ticket showing remediation of any issue found during recovery testing	P14 Business Continuity and Disaster Recovery Policy, P15 Backup and Recovery Policy

C1 Confidentiality

Criterion	Evidence to collect	Policies
C1.1 Identifying and protecting confidential information	Data classification matrix listing the classification levels and handling rules for each Data inventory or data map showing where confidential and personal data is stored Retention schedule listing each data category and its retention period Sample customer contract confidentiality clause	P06 Data Classification and Handling Policy, P07 Data Retention and Disposal Policy, P22 Privacy and Data Protection Policy
C1.2 Disposing of confidential information	Customer offboarding or deletion request records with completion dates Database or object storage lifecycle policy screenshot enforcing the retention schedule Backup retention configuration showing when deleted data ages out of backups Disposal log entries for decommissioned systems or devices	P05 Asset Management Policy, P07 Data Retention and Disposal Policy, P22 Privacy and Data Protection Policy

The common criteria, CC1 through CC9, apply to every SOC 2 report. Availability (A1) and Confidentiality (C1) only apply if you put those categories in scope. For the controls that produce this evidence, see the SOC 2 controls list; for the questions that come up when the auditor walks through your policies, see what auditors ask about policies.

130 rows, built in your browser. Opens in Excel, Numbers or Google Sheets.

Frequently asked questions

Is there an official SOC 2 evidence list?: No. The AICPA publishes the Trust Services Criteria, not a list of documents. The auditor decides what to request based on the controls you describe, so the evidence list for your examination comes from your own control set. The checklist on this page is a starting point mapped to the criteria, not a request list from any CPA firm.
What is the difference between Type I and Type II evidence?: A Type I report covers the design of your controls at a single date, so the evidence shows that a control exists and is set up as described: an approved policy, a configuration screenshot, a walkthrough. A Type II report covers whether the controls operated over a period, so the evidence has to show the control running throughout that period: dated tickets, review records and logs from across the whole window.
Can I create evidence after the fact?: No. Evidence has to be produced when the control runs. A quarterly access review written up months later, or a training record backdated to fit the period, is not evidence that the control operated. If a control did not run, the honest answer is to say so; the auditor will treat it as an exception either way.
Do I need a compliance platform to collect evidence?: Not necessarily. Many small companies keep evidence in a shared folder organized by criterion or control, with a spreadsheet that tracks owner, cadence and where each item lives. A platform can automate collection from your tools, but the auditor tests the evidence, not the system it is stored in.
Who should own evidence collection?: Each control should have an owner who produces its evidence as part of running it, for example the engineering lead for change review or the person who runs onboarding for access requests. One person usually coordinates the folder and the auditor's requests, but evidence collected by someone who does not run the control tends to arrive late and incomplete.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.