Controls & Evidence
A SOC 2 audit evaluates your controls across multiple domains. For each domain, auditors look for evidence that controls are designed properly and operating effectively. Below are the 12 core control domains with minimum requirements and example evidence artifacts.
What auditors look for: Auditors don't just check that policies exist. They verify that controls are operating as described, that evidence is produced on schedule, and that gaps are tracked and remediated. The evidence examples below show what "operating effectiveness" looks like in practice.
Centralized identity, role-based access, documented provisioning, periodic review, and prompt deprovisioning.
Requirements
- Centralized identity provider for all in-scope systems
- Role-based access with documented provisioning workflows
- Periodic access reviews (quarterly preferred, annual minimum)
- Prompt deprovisioning on termination or role change
Evidence Examples
| Artifact | Owner | Frequency |
| User/permission export with review sign-off | Security lead or IT admin | Quarterly |
| Access request ticket with approver record | IT admin or app owner | Event-driven |
| Offboarding checklist with disable timestamps | HR + IT | Event-driven |
Separate privileged roles, least privilege enforcement, and MFA for administrative and production-sensitive access.
Requirements
- Separate privileged roles from standard user accounts
- Enforce least privilege across all in-scope systems
- MFA required for administrative and production-sensitive access
- Document and review privileged access grants periodically
Evidence Examples
| Artifact | Owner | Frequency |
| Admin role inventory with justification | Security lead | Quarterly |
| MFA enforcement configuration screenshot | IT admin | Annually or on change |
| Privileged access request and approval record | IT admin | Event-driven |
Peer review, testing, approval before production, emergency-change flow, and release traceability.
Requirements
- Peer review required for all code changes before merge
- Testing evidence linked to each release
- Approval documented before production deployment
- Emergency change process with post-hoc review
- Release traceability from ticket to deployment
Evidence Examples
| Artifact | Owner | Frequency |
| Branch protection settings and PR approval record | Engineering manager | Per change; settings reviewed annually |
| CI/CD test results linked to release | DevOps / Engineering | Per release |
| Change approval ticket with deployment record | Engineering manager | Per release |
Centralized audit logs, alert routing, threat monitoring, and incident escalation paths.
Requirements
- Centralized log collection for all in-scope systems
- Alert routing for security-relevant events
- Monitoring for threats, anomalies, and capacity
- Defined escalation path from alert to incident
Evidence Examples
| Artifact | Owner | Frequency |
| Log aggregation configuration and retention policy | SRE / Platform team | Annually or on change |
| Alert rule definitions and notification routing | SRE / Security | Quarterly review |
| Sample alert-to-incident escalation record | Security lead | Per incident |
Vulnerability scanning, patching and upgrade process, penetration testing, and tracked remediation.
Requirements
- Regular vulnerability scanning of in-scope systems
- Defined patching and upgrade process with SLAs
- Annual penetration testing (or after major changes)
- Tracked remediation with risk acceptance for exceptions
Evidence Examples
| Artifact | Owner | Frequency |
| Penetration test report with remediation tickets | Security lead | Annually |
| Vulnerability scan results and patch records | SRE / DevOps | Monthly or continuous |
| Risk acceptance documentation for deferred fixes | Security lead | As needed |
Defined roles, incident documentation, periodic tabletop exercises, and postmortem process.
Requirements
- Documented incident response plan with defined roles
- Incident classification and severity definitions
- Annual or periodic tabletop exercise or drill
- Postmortem process with documented lessons learned
Evidence Examples
| Artifact | Owner | Frequency |
| Incident response plan document | Security lead | Annually reviewed |
| Incident ticket with timeline and RCA | Incident manager | Per incident |
| Tabletop exercise record and findings | Security lead | Annually |
Vendor register, risk rating, pre-engagement due diligence, annual review, and reliance on vendor SOC reports.
Requirements
- Maintained vendor register with risk ratings
- Pre-engagement due diligence for critical vendors
- Annual review of critical vendor security posture
- Collection and review of vendor SOC reports or questionnaires
Evidence Examples
| Artifact | Owner | Frequency |
| Vendor register with risk ratings and review dates | Ops / Security | Annually |
| Vendor SOC report or security questionnaire | Security lead | Annually per critical vendor |
| Vendor contract with security requirements | Legal / Ops | Per engagement |
Accurate inventory of systems, data stores, endpoints, and privileged contexts.
Requirements
- Maintained inventory of all in-scope systems and applications
- Data store inventory with classification and ownership
- Endpoint inventory for company-managed devices
- Identification of privileged and administrative contexts
Evidence Examples
| Artifact | Owner | Frequency |
| System and application inventory with owners | IT / SRE | Quarterly or on change |
| Data store inventory with classification | Security lead | Annually |
| Endpoint management dashboard or export | IT admin | Quarterly |
Encryption in transit and at rest, secure secret storage, and key rotation process.
Requirements
- Encryption in transit (TLS) for all external communications
- Encryption at rest for sensitive data stores
- Secure secret storage (vault or managed service)
- Key rotation process where risk warrants it
Evidence Examples
| Artifact | Owner | Frequency |
| TLS configuration and certificate records | SRE / DevOps | Annually or on change |
| Secret management tool configuration | DevOps / Security | Annually |
| Key rotation log or policy | Security lead | Per rotation schedule |
Backup frequency and retention, failure monitoring, restore testing, and capacity monitoring.
Requirements
- Defined backup frequency and retention for critical data
- Monitoring for backup failures with alerting
- Periodic restore testing to validate recoverability
- Capacity and availability monitoring for production systems
Evidence Examples
| Artifact | Owner | Frequency |
| Backup configuration with frequency and retention | SRE / Platform | Annually or on change |
| Backup failure alert configuration | SRE | Continuous |
| Restore test report with results | SRE / Platform | Annually |
Data classification, customer data disposal, test-data restrictions, and confidentiality agreements.
Requirements
- Data classification policy with defined levels
- Documented customer data disposal process
- Restrictions on production data in test environments
- Confidentiality agreements for employees and contractors
Evidence Examples
| Artifact | Owner | Frequency |
| Data classification policy document | Security lead | Annually reviewed |
| Data disposal request and confirmation record | Ops / Engineering | Event-driven |
| Signed confidentiality agreements | HR | Per hire/engagement |
Privacy notice, data subject rights requests, consent handling, and privacy training.
Requirements
- Published privacy notice aligned with actual data practices
- Process for handling data subject rights requests
- Consent collection and management where applicable
- Privacy-specific training for relevant personnel
Evidence Examples
| Artifact | Owner | Frequency |
| Privacy notice/policy (public-facing) | Legal / Security | Annually reviewed |
| DSAR handling procedure and log | Security / Legal | Event-driven |
| Privacy training completion records | HR | Annually |
Evidence Naming Conventions
Organized, traceable evidence is critical for a smooth audit. While the AICPA does not prescribe a specific naming format, adopting a consistent convention makes evidence retrieval faster and reduces auditor friction.
Recommended format:
ControlID_System_ArtifactType_YYYY-MM-DD_Period_Owner_v# Example:
AC-01_Okta_AccessReview_2026-03-31_Q1_SecurityLead_v1 Key principles for evidence management:
- Centralized repository with access control and version history
- Consistent naming across all control domains and artifact types
- Defined cadence for each evidence type: event-driven, monthly, quarterly, or annual
- Immutable exports where possible to demonstrate evidence integrity
AI and data companies: Standard SOC 2 controls are the baseline. See our AI-specific advisory modules for additional controls addressing data governance, prompt logging, RAG security, and model vendor risk.