In brief
A SOC 2 evidence checklist for SaaS teams: the records auditors sample for governance, access, change, security operations, availability and privacy.
A SOC 2 evidence checklist lists the dated records that prove each control existed and operated during the examination period: approved policies, access reviews, change approvals, scan results, incident records and supplier reviews. A policy alone rarely proves operating effectiveness. Auditors sample records that show a date, an owner, the source system and the control they support.
What does SOC 2 evidence have to prove?
SOC 2 evidence has to show that a control was designed as described and, for Type II, that it operated consistently across the whole period. The AICPA describes SOC 2 as an examination by a CPA firm of controls relevant to security, availability, processing integrity, confidentiality or privacy, assessed against the Trust Services Criteria. Security (the common criteria) is always in scope; the other categories depend on the system and the commitments you make to customers. A Type II period typically runs 3 to 12 months, and the AICPA sets no minimum, so evidence must exist for each point in that window the auditor chooses to sample.
What belongs in a SOC 2 evidence checklist?
The exact request list depends on the system description, control design, report type and the auditor's sampling approach. Most SaaS teams should be ready to produce evidence in these areas:
| Control area | Useful evidence | Typical source |
|---|---|---|
| Governance and risk | Approved policies, responsibilities, risk assessment, management review records | Document system, management meeting records |
| Access | User lists, access approvals, periodic access reviews, termination records | Identity provider, cloud IAM, HRIS |
| Changes | Pull requests, approvals, test results, deployment records | GitHub or GitLab, CI/CD, ticketing |
| Security operations | Alerts, vulnerability findings, remediation tickets | SIEM, scanners, endpoint tools |
| Incidents | Response plan, exercises, incident records | Ticketing, incident platform |
| Suppliers | Inventory, due diligence, contracts, reviews | Vendor management and legal records |
| Availability (if in scope) | Monitoring, backup results, restoration tests, continuity exercises | Monitoring and backup tools |
| Confidentiality and privacy (if in scope) | Data classification, encryption settings, retention and deletion records, notices, request handling | Data inventory, cloud configuration, privacy tooling |
What governance and risk evidence do auditors ask for?
Auditors ask for the current version of each policy with its approval date, owner and distribution record, plus risk assessment results, treatment decisions, assigned owners and management review records. They may also ask how leadership receives security information. A dashboard screenshot can support the answer, but meeting minutes or a recorded decision show better that someone considered the information and acted on it.
What access control evidence should you prepare?
Access testing usually crosses HR, identity, cloud and application systems, so prepare:
- A complete population of user and privileged accounts for each in-scope system.
- Access requests and approvals for sampled new users.
- Periodic access review results and the remediation that followed.
- Offboarding records tied to the date each account was removed.
- MFA and authentication configuration.
- Service account owners and credential rotation records.
The population matters: if the exported user list is incomplete, a clean sample does not prove the control covered every relevant account.
What change management evidence holds up in a sample?
For each sampled production change, keep the ticket or requirement, the code review, the test result, the approval, the deployment record and rollback information. The approver should be someone other than the person who made the change. Emergency changes need a defined path and a later review when the normal approval sequence cannot be followed. Configure source control and CI/CD to preserve these records as part of delivery; evidence created after the fact undermines the test.
What security operations and vulnerability evidence is useful?
Useful records include scan configuration, findings with severity and owner, remediation due dates and closure evidence, endpoint coverage, security alerts and incident escalation. When a finding is accepted rather than fixed, keep the risk decision and the approver. A pentest report supports assurance over a defined scope and date, but it does not replace continuous vulnerability management or evidence for unrelated controls.
How should a SaaS team organize SOC 2 evidence?
Organize evidence by control, with one owner and one source per control, and collect it on a schedule rather than when the auditor asks:
- Map each control to an owner and a source system.
- Define the evidence type and collection frequency, matching what your system description promises.
- Preserve the full population before samples are chosen.
- Record the review and approval, not only the extraction.
- Restrict auditor access to the agreed scope.
- Track exceptions through remediation or documented risk acceptance.
If the team still collects these records by hand, the seven manual compliance workflows worth automating and automated evidence collection show where tooling saves the most time.
How does pTrackly support SOC 2 evidence collection?
In pTrackly each evidence task has an assignee, a frequency (daily to yearly), a department, frameworks and a review date. When a period passes, tasks without integration checks reopen automatically; owners get reminders 7, 3 and 1 days before a review is due and a Monday digest of open tasks, and an approval records a signed copy of the exact version reviewed. For the audit itself, you create a SOC 2 Type I or Type II audit, invite the auditor to the Auditor portal, attach evidence tasks to each request and lock the set with SHA-256 fingerprints at the end. Scope, control operation and approvals remain your team's responsibility, and the report is issued by an independent CPA firm. See the SOC 2 framework workflow and managed compliance responsibilities.
Frequently asked questions
How much evidence does a SOC 2 Type II audit need?
Enough to cover every control for the whole examination period, which typically runs 3 to 12 months. The auditor picks samples from across the period, so each recurring control needs a record for each time it was supposed to run.
Can a policy document count as SOC 2 evidence?
A policy shows that a control was designed, which is enough for parts of a Type I report. For Type II, auditors also need records that the policy was followed, such as completed reviews, approvals and tickets.
Who decides how often SOC 2 evidence is collected?
Your organization does, through its policies and system description. The auditor tests whether controls ran at the frequency you committed to, so set frequencies your team can sustain.
Does a pentest report replace vulnerability scan evidence?
No. A pentest covers a defined scope on a specific date, while vulnerability management is a recurring control that needs its own scan results and remediation records across the period.
References
This checklist is general readiness information. The auditor determines the evidence required for a specific engagement.
