SOC 2 evidence is the record that a control was designed, implemented and operated. A policy says that access reviews happen quarterly; evidence shows the review population, reviewer, date, decisions and follow-up. A change-management policy says production changes are approved; evidence connects a real deployment to a ticket, reviewer, test result and release. Auditors need enough reliable evidence to understand and test the control for the scope and period in the engagement.
Use this as a working list, not a dumping ground. Store source evidence in the system where the work happens, link it to a control, record the period and owner, and redact secrets or unnecessary personal data. A large folder of screenshots is not stronger evidence than a small, traceable record.
Before collecting: define the evidence rules
Start with the system boundary and selected Trust Services Criteria. Security is required in every SOC 2 report. Availability, Processing Integrity, Confidentiality and Privacy are optional and should reflect the service and customer requirement. Evidence for an out-of-scope system can distract the auditor, while missing evidence for an in-scope subprocessor can create a gap. The SOC 2 guide explains how the criteria shape scope.
Create a control matrix with a plain-language control statement, owner, frequency, source system, evidence location, reviewer and exception path. Agree naming and retention conventions before the Type II observation window starts. Include the control period in each export; an access list without an “as at” date is difficult to test. Keep immutable or access-controlled copies where the source system can change.
Evidence should be sufficient, appropriate and attributable. “Sufficient” means enough examples or population data for the auditor’s sampling approach. “Appropriate” means it actually demonstrates the control rather than a related activity. “Attributable” means the reviewer, date and source are clear. A screenshot with no URL, timestamp or account identity rarely answers all three.
Cross-cutting evidence every SOC 2 programme needs
Scope and system description
- System boundary diagram covering application, cloud accounts, data stores, repositories, CI/CD, support tools and offices.
- System description: services provided, principal service commitments, data types, infrastructure, software, people and relevant procedures.
- List of in-scope locations, production environments, subservice organisations and complementary user entity controls.
- Data-flow diagram showing collection, processing, storage, backup, access and deletion.
Governance and risk
- Approved information-security policy, security objectives and named control owners.
- Current risk assessment and risk register with likelihood, impact, treatment, owner and review date.
- Management or board security review minutes showing decisions, metrics, incidents and open risks.
- Organisation chart, role descriptions, security responsibilities and evidence of security awareness training.
Keep customer-facing answers consistent with these records. If your security questionnaire says all production changes require approval but the deployment system allows direct pushes, an auditor or customer will find the contradiction. Readiness support should reconcile the control description, configuration and evidence before fieldwork.
Security: the required Common Criteria evidence
Security, sometimes called the Common Criteria, is mandatory. It covers the broad control environment, communication, risk assessment, monitoring, logical and physical access, system operations, change management and risk mitigation. The exact evidence request depends on the auditor’s control mapping, but the following list is a realistic starting point.
CC1–CC2 · Control environment and communication
- Information-security policy approval, version history and annual review record.
- Security roles and responsibilities, segregation of duties and escalation contacts.
- Code of conduct, acceptable-use acknowledgement and security training completion.
- Internal and customer security communications, policy distribution and acknowledgement records.
CC3–CC4 · Risk assessment and monitoring
- Annual and event-driven risk assessments, including changes to systems, suppliers and threats.
- Risk register treatment decisions, risk acceptance approvals and remediation tickets.
- Security metrics, vulnerability trends, alert review and management review minutes.
- Internal control review, self-assessment or readiness testing, including follow-up of findings.
CC5–CC6 · Access and logical security
- Current user and privileged-account listings for identity provider, cloud, production, code and support systems.
- Joiner, mover and leaver tickets showing timely provisioning, role changes and access removal.
- Quarterly access-review exports with reviewer, decisions, revoked accounts and exceptions.
- MFA and password configuration, SSO enforcement, service-account ownership and key rotation records.
- Physical-access or hosting-provider assurance records where offices or data centres matter to scope.
CC7 · System operations and incident response
- Vulnerability scan results, penetration-test report, remediation tickets and documented risk exceptions.
- Monitoring and alert configuration, on-call rota, alert review records and escalation evidence.
- Incident register, severity assessment, investigation notes, customer notifications and post-incident reviews.
- Tabletop exercise plan, attendance, lessons learned and tracked corrective actions.
CC8–CC9 · Change and risk mitigation
- Sample of application, infrastructure and configuration changes with ticket, approval, test, deployment and rollback result.
- Emergency-change records showing retrospective approval and review.
- Business continuity and disaster-recovery plans, dependency analysis, test results and corrective actions.
- Supplier inventory, risk tiering, due diligence, contracts, security reviews and offboarding records.
For Type II, auditors sample these records across the entire observation period. A single screenshot of a current configuration does not prove it remained unchanged for six months. Preserve recurring exports or use a source system that retains history. If a platform captures evidence automatically, validate that it captures the right account, date and scope.
Availability evidence
Availability is relevant when your service commitments include uptime, recovery or capacity. It is not a promise of perfect availability; it evaluates controls designed to meet stated commitments. Include only what you can measure and operate.
- Service-level commitments, availability objectives and customer-facing status or incident process.
- Architecture and redundancy diagrams, capacity planning, health checks and monitoring dashboards.
- Uptime and incident reports for the observation period, with root cause and corrective action.
- Backup schedules, completion logs, restore-test results, recovery time and recovery point objectives.
- Disaster-recovery test plan, participants, failover evidence, lessons learned and remediation tickets.
- Cloud-provider assurance report and review of relevant complementary controls.
Do not claim resilience solely because a cloud provider is resilient. Show how your configuration, backup, alerting and recovery process uses that infrastructure and meets your own service commitments. A customer may also ask for a business continuity plan even when Availability is not in the report; keep the evidence available.
Processing Integrity evidence
Processing Integrity applies when customers depend on complete, valid, accurate, timely and authorised processing. It is common for transaction, reporting, billing, data transformation or workflow services, and less relevant to a simple file store. Define what “correct processing” means for your service before selecting this criterion.
- Documented processing requirements, validation rules, approval rules and error-handling procedures.
- Input and output reconciliation reports, failed-job queues, retry logs and exception resolution.
- Test cases and release evidence for processing logic, including boundary and negative tests.
- Monitoring for data-quality errors, duplicate or missing records, latency and unauthorised processing.
- Customer support tickets or incident records showing investigation of processing errors.
A code review alone is not processing-integrity evidence. Connect the control to the business outcome: what was checked, who reviewed the exception and how the customer was protected. Keep personal data in evidence to the minimum necessary and apply your retention and access rules.
Confidentiality evidence
Confidentiality is useful when the service handles information customers classify as confidential, commercially sensitive or restricted. It extends security evidence into commitments about identifying, protecting, retaining and disposing of confidential information.
- Data classification policy and inventory of confidential data types and repositories.
- Encryption configuration for transport, storage and backups, including key ownership and rotation.
- Access rules tied to classifications, customer tenant isolation and privileged-access monitoring.
- Retention schedule, deletion requests, disposal certificates and media sanitisation records.
- Confidentiality clauses, employee agreements, supplier contracts and offboarding attestations.
- Data-loss prevention alerts, export approvals and investigation records where applicable.
Describe tenant isolation accurately. Encryption at rest does not prove that an employee cannot query another customer’s data. Evidence should connect design, configuration and monitoring to the confidential information in the system description.
Privacy evidence
Privacy covers personal information and the organisation’s privacy commitments. For UK and EU SaaS companies, it sits beside UK GDPR or EU GDPR responsibilities rather than replacing them. If Privacy is in scope, auditors will expect evidence that the stated privacy notice, contracts and procedures operate in practice.
- Privacy notice, data inventory, processing purposes, lawful-basis analysis and records of processing activities.
- Controller/processor contracts, data-processing agreements, subprocessor list and transfer safeguards.
- Data-subject request register, identity verification, response evidence and deletion or access completion.
- Consent records and preference-management evidence where consent is the lawful basis.
- Privacy impact or data-protection impact assessments for higher-risk processing.
- Personal-data incident register, breach assessment, notification decisions and post-incident action.
- Retention and deletion job logs, backup deletion position and approvals for exceptions.
Do not claim that a SOC 2 Privacy report is GDPR certification; it is not. Keep the privacy control description aligned with your real role, jurisdictions and contracts. A US customer may ask for SOC 2 while your European regulator obligations remain governed by GDPR.
How to package evidence for the auditor
- Map each file to a control: use a stable control ID, evidence title, owner, source and period.
- Preserve context: include export date, system name, population, reviewer and any filtering or redaction.
- Separate evidence from explanation: a short readme can explain a record, but do not rewrite the source to hide an exception.
- Protect secrets and personal data: redact API keys, passwords and unnecessary employee information; use a controlled auditor workspace.
- Review recurring controls monthly: identify missed cadences while there is time to correct process, not at report close.
- Keep change history: store the policy version, system description and control mapping that applied to the period under examination.
Evidence is a product of operating the control, not a separate writing exercise at audit time. Our SOC 2 readiness service helps assign owners and build the collection workflow. For sequencing and report dates, see the SOC 2 audit timeline; for report-type decisions, see Type I vs Type II.
Evidence checklist FAQs
Do auditors need every ticket?
Usually no. Auditors define a population and select samples, but you must be able to produce complete population data and source records. Keep all relevant records according to your retention policy rather than guessing which sample will be chosen.
Can screenshots count as evidence?
They can support a walkthrough when they show source, account, date and relevant configuration, but exports and system records with history are often stronger. Never include credentials or secrets in a screenshot.
What if we missed a control?
Record the miss, assess impact, document remediation and tell the auditor. Backdating or deleting evidence creates a more serious integrity issue than a transparent, isolated exception.
Do we need a compliance platform?
No. Platforms can make collection and mapping easier, but a well-controlled combination of identity, ticketing, cloud, HR and document systems can work. Choose technology after defining scope, controls and owners.
Not sure whether your evidence will stand up?
Bring your control matrix, customer request or current evidence folder. We will identify the gaps and the first practical fixes in a 45-minute working session.
Book a 45-minute working session →