DataSecureMap each control to its owner, systems and records. Agree with your auditor on the examination scope, period, evidence and sampling approach before treating any checklist as complete.
Start with scope, not screenshots
SOC 2 examines a service organization’s system and controls against applicable trust services criteria. The AICPA trust services criteria cover security, availability, processing integrity, confidentiality and privacy. Your selected categories, system boundaries, control design and auditor’s approach determine the evidence required.
A policy states what should happen; a record can help show what actually happened. For Type II, evidence needs to support operation during the period under examination. Learn more about Type I versus Type II, or use the broader SOC 2 compliance checklist to plan readiness.
SOC 2 evidence checklist
Use these examples to begin conversations with control owners. They are not a prescribed universal list.
Access and identity
- Current inventories of in-scope systems, privileged accounts and users, with access owners.
- Joiner, role-change and termination records showing approvals and access changes.
- Periodic access reviews, reviewer decisions and follow-up for exceptions.
- Configuration records for authentication, including MFA where applicable.
Change management and development
- Change-management policy and a list of changes deployed during the relevant period.
- For selected changes: request, approval, testing, code review and deployment records.
- Branch protection and release configuration, together with evidence of exceptions and remediation.
Risk, vendors and people
- Risk assessments, owners, treatment decisions and tracking of identified risks.
- Vendor inventory, due diligence, review records and assigned responsibilities.
- Security training assignments and completion records, plus relevant onboarding and offboarding records.
Operations, incidents and recovery
- Monitoring configuration and a record of alerts, investigation and resolution.
- Incident response plan, exercises and incident tickets where applicable.
- Backup configuration, review records and results of restoration or recovery tests.
- Vulnerability scan results, triage and evidence of remediation or risk acceptance.
Example evidence matrix
Filter by control area to see how a team might organize its work. These are illustrative examples, not required controls or auditor-approved mappings. Set owners and frequencies for your own environment and confirm evidence with your auditor.
Download the editable evidence worksheet (CSV)
Open in a spreadsheet, replace the example with your own controls, and store it securely. Avoid putting passwords or access tokens in the worksheet.
Showing 4 examples
Access
Review access to in-scope systems
- Evidence source
- Identity provider user export, review decisions and removal tickets
- Possible owner
- IT or system owner
- Cadence
- At the frequency your policy specifies
- Review
- Check the population is complete, reviewers are authorized and removals are followed through.
- Limitation
- An export alone does not show that a review occurred.
Changes
Approve and review production changes
- Evidence source
- Change population, pull request reviews, approvals and deployment records
- Possible owner
- Engineering or change owner
- Cadence
- For each change, as the control specifies
- Review
- Reconcile deployed changes to approvals and investigate exceptions or emergency changes.
- Limitation
- Branch settings alone do not prove every change was reviewed.
Operations
Investigate security alerts
- Evidence source
- Alert inventory, investigation tickets, escalation and closure records
- Possible owner
- Security operations owner
- Cadence
- As defined in the monitoring procedure
- Review
- Check alert coverage and follow a sample from detection through resolution.
- Limitation
- A monitoring dashboard alone may not show investigation or closure.
Recovery
Test restoration of backups
- Evidence source
- Backup configuration, test plan, restoration results and follow-up actions
- Possible owner
- Infrastructure owner
- Cadence
- At the frequency your recovery plan specifies
- Review
- Check the restored system, test date, outcome and resolution of failures.
- Limitation
- A successful backup status does not demonstrate restoration.
What makes evidence useful?
Useful records identify the system, control, owner, source and date or period. Preserve enough context to understand who performed an action and what resulted. Where a population is relevant, retain a complete, time-bounded export so the auditor can select samples; individual screenshots alone may not establish completeness or operation over time.
Protect sensitive records: use least-privilege access, secure transfer and appropriate retention. Redact secrets and unnecessary personal information while preserving the details needed for review. Agree on redactions and formats with your auditor.
Collect throughout the period
Assign each control an owner and a collection cadence. Record the source and collection time, review missing or failed checks, and keep historical snapshots and remediation records. Automated exports can reduce manual work, but they do not replace assessment of completeness, control operation or auditor judgment.
Questions to ask your auditor
- Which systems, services and categories are in scope?
- What period does the examination cover, and which populations are needed?
- What formats, date ranges, sample selections and redactions are acceptable?
- How should exceptions, changes to controls and missing historical records be handled?
Educational guidance, not an audit opinion or a substitute for advice tailored to your organization. Evidence requests vary by engagement.
Make your evidence easier to manage.
Talk with DataSecure365 about your readiness and evidence collection.
Book a demo ↗