A SOC 2 auditor asks for your system description and policies, then for dated records showing each control actually ran: access reviews, change approvals, onboarding and offboarding tickets, training completion, vulnerability management and incident records. Your auditor's request list governs, so treat the examples here as a guide to what is typical.
What is SOC 2 evidence measured against?
SOC 2 is an attestation done by a licensed CPA firm. The AICPA's description criteria are the benchmarks for describing your system, and the examination covers the trust services categories of security, availability, processing integrity, confidentiality and privacy. Most companies start with security alone, and add the others when customers ask. The AICPA's SOC page says SOC services should be thoroughly evaluated by service organizations and CPA firms, and links to a Journal of Accountancy article titled "Promises of 'fast and easy' threaten SOC credibility." Choose your auditor on professional standing, not speed.
Evidence is what you hand over to prove each control exists and, in a report covering a period, that it worked throughout. Commonly, a point-in-time report looks at whether controls are designed and in place on one date, while a period report looks at whether they operated over time. Confirm the exact scope with your auditor.
What do auditors typically ask for?
Governance and scope. A system description, an organization chart, policies approved by management with dates and owners, and a risk assessment with treatment decisions.
People. Background check records, signed policy acknowledgments, security training completion by date, and a list of employees with hire and leave dates.
Access. The list of users for in-scope systems, evidence that access was approved when granted, removed on leaving, and reviewed on a schedule. Multi-factor authentication settings, shown as configuration exports, not claims.
Change management. A population of changes for the period, with a sample showing request, review, test and approval before release. Code review settings and protected branches in your source control.
Vulnerability and patch management. Scan results over time, tickets showing how findings were triaged and fixed, and how quickly. For software you ship or run, an inventory of dependencies and records that known issues were handled.
Monitoring and incident response. Alerting configuration, logs and their retention, the incident response plan, and records of real incidents or a tabletop exercise, with lessons recorded.
Vendors. A register of vendors, the due diligence you did, and their own assurance reports where relevant.
Availability and backups, if in scope. Backup configuration, restore test results, and disaster recovery test records.
What makes evidence strong?
Auditors value records that are dated, generated by a system, and complete. A screenshot taken the week before the audit shows less than a system export with timestamps. A sample is only useful if you can show the full list it was drawn from. And a control that ran for eleven months of twelve reads as a gap, so catch lapses as they happen.
Where do software supply chain records help?
If your auditor looks at secure development and vulnerability management, records from your pipeline are direct evidence: scan results on each release, the time findings took to fix, and the SBOM for each version. Safeguard's compliance automation can collect evidence like this continuously. Tooling does not make anyone compliant, though. It reduces the labor of gathering records.
What to do
- Agree scope and categories with your auditor before you start.
- Get the auditor's request list early and map each item to a system and an owner.
- Turn on automatic evidence collection for access, change and scan data.
- Run a monthly check that controls ran and records exist, and fix lapses at once.
- Keep policy approvals dated and reviewed on a fixed schedule.
- Run an incident tabletop and write down what changed afterward.
- Review your vendor register and collect their assurance reports.
- Do a dry run of a sample request a month before fieldwork.
Quick check
Who issues a SOC 2 report?
A licensed CPA firm performing an attestation engagement under AICPA standards. Software tools can collect evidence, but they do not issue the report.
Is a screenshot acceptable evidence?
Sometimes, but system generated exports with timestamps are stronger, and your auditor decides what they accept. Ask early.
Sources
- AICPA and CIMA: SOC 2 description criteria
- AICPA and CIMA: System and Organization Controls, SOC Suite of Services
Last reviewed: 18 October 2026.
