SOC 2 Audit Checklist: The Evidence Your Auditor Will Request

How Auditors Use Evidence

SOC 2 auditors do not evaluate intent — they evaluate evidence. For a Type I engagement, auditors examine documentation at a point in time. For a Type II engagement, auditors sample evidence across the entire observation period, typically selecting specific date ranges to test whether controls operated consistently throughout, not merely at the beginning or end. A control that functioned in months one and six but failed in month three is not a passing control. Evidence must be continuous, complete, and accessible.
The checklist below organizes evidence requirements by control domain, aligned to the Trust Services Criteria. It is not exhaustive — your specific system description and service commitments determine the precise scope — but it covers the evidence categories that appear in the majority of mid-market SOC 2 engagements.

Governance and Control Environment (CC1–CC5)

Organizational chart documenting reporting lines and security responsibilities. Documented roles and responsibilities for personnel with security-relevant functions. Board or leadership meeting minutes or reports demonstrating security receives governance attention. Security awareness training records including completion dates, content versions, and attendance by employee. An information security policy that is version-controlled, reviewed on a defined cycle, and communicated to staff with documented acknowledgment. A risk assessment methodology document and an active risk register with scoring and treatment decisions. Evidence that risk assessment results are communicated to leadership.

Logical and Physical Access Controls (CC6)

User access provisioning records: documentation of the process for granting access, including approvals, and a sample of provisioning tickets from across the observation period. User access de-provisioning records: evidence that access is removed when employees depart, with records showing the timing between separation and access revocation. Quarterly or semi-annual access reviews: documentation that access rights are reviewed, owners confirm continued need, and excess access is revoked. Multi-factor authentication configuration screenshots or reports demonstrating coverage across critical systems, administrator accounts, and remote access pathways. Privileged access management controls: evidence that administrative accounts are managed separately, reviewed regularly, and access to elevated privilege requires documented justification. Physical access controls for data center or server room environments: badge access logs, visitor records, and evidence of periodic review.

System Operations (CC7)

Security monitoring configuration: evidence that your logging and alerting infrastructure is active, covering the systems in scope. Alert investigation records: documentation that alerts are triaged, investigated, and that investigation outcomes are recorded. Incident log: a record of security incidents during the observation period, including detection date, classification, response actions taken, and resolution. Vulnerability scanning results and evidence of remediation for identified findings. Penetration testing report from the observation period or preceding twelve months, with evidence that findings were tracked and remediated.

Change Management (CC8)

Change management policy documenting the process for requesting, approving, testing, and deploying changes to systems in scope. Change tickets from across the observation period demonstrating that the process was followed: evidence of request, technical review, approval by an authorized reviewer distinct from the implementer, and post-deployment validation. Emergency change procedures and evidence that they were invoked with appropriate retroactive approval. Software development lifecycle documentation if your service includes custom-developed software: code review records, testing evidence, and deployment approvals.

Risk Mitigation (CC9)

Vendor management documentation: inventory of subservice organizations and third-party vendors with access to systems or data in scope. SOC 2 reports or equivalent assurance documentation obtained from key subservice organizations. Vendor contracts with security and confidentiality provisions. Evidence of periodic vendor risk reviews.

Availability Controls (A1) — If In Scope

Documented uptime commitments and service level agreements. System availability monitoring records demonstrating measurement against commitments across the observation period. Business continuity and disaster recovery plans. Evidence of BCP/DR testing: tabletop exercise records, failover test results, recovery time measurements. Capacity management records demonstrating that system resources were monitored and scaled as needed.

Confidentiality Controls (C1) — If In Scope

Data classification policy defining what constitutes confidential information and how it must be handled. Encryption configuration records for confidential data in transit and at rest. Data handling and retention procedures with evidence of consistent application. Secure disposal records for media or systems that handled confidential information.

Privacy Controls (P1–P8) — If In Scope

Current privacy notice that accurately reflects your data collection, use, retention, and disclosure practices. Consent records where applicable. Data subject request procedures and records of requests handled during the observation period. Data retention schedule and evidence that retention limits are enforced. Third-party data sharing agreements with privacy protections. Breach notification procedures and log of any privacy incidents during the observation period.

Building an Audit-Ready Evidence Repository

The difference between an organization that moves through fieldwork efficiently and one that scrambles is almost always evidence organization. Auditors request evidence through a Prepared by Client (PBC) list — a structured request for specific artifacts. Organizations that maintain a continuously updated evidence repository respond to PBC requests in hours rather than days, compress fieldwork timelines, and reduce auditor fees for extended information-gathering.
Armorstack’s SENTRY practice generates many of these evidence artifacts automatically through continuous monitoring: alert logs, investigation records, vulnerability scan results, access monitoring. Our VERITY advisory practice maintains the governance documentation and access review cadences. That integration means your evidence repository is built and maintained as a byproduct of operational security — not assembled under audit pressure.
Complete the SOC 2 readiness assessment to identify which items on this checklist require attention before your observation period begins. Understand the Trust Services Criteria to determine which sections of this checklist apply to your engagement scope. Review the timeline and cost guide for program planning. Return to the SOC 2 pillar or the full compliance hub.