SOC 2 evidence requirements: what auditors expect for Common Criteria controls

SOC 2 auditors evaluate whether evidence is sufficient, relevant, and reliable to support their opinion. Sufficient means enough quantity to test a control; relevant means it addresses the criterion; reliable means it was generated by the system or process under test without undue manual alteration. Understanding these standards shapes how your team collects artifacts year-round.

Type I examinations focus on design evidence: policies, configuration screenshots, system descriptions, and samples showing controls existed at the point-in-time date. Type II adds population lists and samples across the audit period demonstrating consistent operation. A access review conducted once satisfies Type I design but fails Type II if quarterly reviews were described.

Auditors prefer system-generated evidence over manual attestations. An export from your identity provider outweighs a spreadsheet an engineer compiled from memory. Build collection habits that favor automated exports on a recurring schedule.

Access control evidence includes the access management policy, role definitions, provisioning and deprovisioning tickets, MFA configuration exports, quarterly access review records, and privileged access logs. Auditors sample new hires and terminations against HR records to verify timely provisioning and deprovisioning.

For MFA, provide configuration showing enforcement on all workforce and privileged accounts, not just admin users. Sample login logs demonstrating MFA challenges for selected accounts during the audit period close common gaps.

Service accounts and break-glass credentials need explicit documentation: inventory, approval records, password rotation evidence, and monitoring logs. Undocumented service accounts are a recurring finding in SaaS environments.

• Policy plus procedure for joiner-mover-leaver
• MFA enforcement configuration and sample auth logs
• Quarterly access review tickets with remediation records
• Privileged account inventory with approval documentation

System operations evidence includes vulnerability scan reports with remediation tracking, intrusion detection or SIEM alert configurations, incident tickets with resolution notes, capacity monitoring dashboards, and backup job success logs. Incidents need documented timelines even when no breach occurred; auditors test process adherence, not just catastrophic events.

Change management evidence spans application and infrastructure: pull request reviews, deployment pipeline logs, change tickets for production modifications, emergency change procedures with retrospective reviews, and segregation between development and production environments.

Provide a population of production changes during the audit period and expect samples. Each sampled change should trace from ticket to approval to deployment log without gaps. Undocumented hotfixes are a frequent source of operating effectiveness exceptions.

Vendor management evidence includes a maintained vendor inventory, risk tiering methodology, security review records at onboarding and annually, executed contracts with security and confidentiality clauses, and sub-processor SOC reports or equivalent attestations.

Auditors sample vendors with access to customer data or critical infrastructure. Each sample should show review date, reviewer name, findings, and remediation if applicable. Missing annual re-reviews for top-tier vendors generate findings even when initial onboarding was thorough.

Track sub-processor changes and customer notification obligations if your contracts require them. Privacy and Confidentiality criteria increase scrutiny on data processing agreements and cross-border transfer mechanisms.

Governance criteria require board or leadership meeting minutes referencing security oversight, organizational charts showing reporting lines for security functions, published policies with version control and employee acknowledgment records, risk assessment documents with dated conclusions, and internal audit or assessment reports with tracked findings.

Employee acknowledgment can be HR system exports showing policy acceptance timestamps. Annual refresh is expected. New hire acknowledgments should occur within thirty days of start per most auditor interpretations.

Risk assessments should reference actual assets and threats, not generic boilerplate. Include cloud services, third-party dependencies, and data classification schemes your team actually uses.

Common failures include undated screenshots, policies without version history, samples outside the audit period, incomplete populations excluding relevant systems, and evidence collected after fieldwork started without explanation of timing integrity.

Prevent failures with continuous collection schedules tied to control frequencies. Monthly tasks produce monthly artifacts stored immediately in mapped repositories. Waiting until audit season compresses quality and invites backdating pressure that auditors detect.

Teams that maintain evidence mapping throughout the year report fifty percent less fieldwork stress than teams that batch collection in the final month. The investment in continuous habits pays back in every subsequent audit cycle.

Auditors select samples from populations you provide. Populations must be complete lists of events during the audit period: user provisioning tickets, production deployments, vendor reviews, security incidents, and vulnerability scan cycles. Incomplete populations force scope expansion or qualified opinions.

Understand sample size logic. Small populations may be tested entirely. Large populations use statistical or haphazard sampling. Ensure each item in a population links to retrievable evidence within minutes.

Document exceptions transparently. When a sampled change lacks approval evidence, explain whether it was an isolated deviation with remediation or a systemic gap. Auditors distinguish one-off process slips from control design failures when you provide context and corrective action records.

Maintain population source system exports with timestamps showing when lists were generated. Auditors question populations created manually at fieldwork start without system-of-record linkage.

Version-control policy documents with visible approval dates and distribution records. Evidence packages should include the exact policy version in effect during each month of the audit period, not only the current version.