SOC 2 Compliance Cheat Sheet
Explains the SOC 2 Trust Services Criteria, audit types, and common control evidence needed to prepare for a SOC 2 examination.
2 PagesIntermediateFeb 20, 2026
Trust Services Criteria
The five categories a SOC 2 report can be scoped against.
- Security (required)- Protection against unauthorized access; the only mandatory criterion for every SOC 2 report
- Availability- Systems are available for operation and use as committed or agreed (uptime, DR)
- Processing integrity- System processing is complete, valid, accurate, timely, and authorized
- Confidentiality- Information designated as confidential is protected as committed or agreed
- Privacy- Personal information is collected, used, retained, and disposed of per the entity's privacy notice
Type I vs Type II Reports
The two flavors of SOC 2 report and what they attest to.
- Type I- Assesses whether controls are suitably designed at a single point in time
- Type II- Assesses operating effectiveness of controls over a period, typically 3-12 months
- Observation period- Type II auditors sample evidence throughout the period, not just at the end
- Auditor- Must be an independent licensed CPA firm following AICPA attestation standards
Common Control Areas
Typical control domains auditors examine for the Security criterion.
- Access control- Least-privilege provisioning, periodic access reviews, and timely deprovisioning
- Change management- Code changes require review, approval, and testing before production deployment
- Logging and monitoring- Centralized logs, alerting on anomalies, and log retention policies
- Vendor management- Due diligence and monitoring of third-party/subprocessor security posture
- Incident response- A documented, tested plan for detecting, responding to, and reporting incidents
- Encryption- Data encrypted in transit (TLS) and at rest (e.g. AES-256)
- Risk assessment- Periodic formal assessment of threats and vulnerabilities to the environment
Automating Evidence Collection
Example script pulling access review evidence for an audit.
bash
#!/bin/bash# Export IAM users and their last activity for quarterly access review evidenceaws iam generate-credential-reportaws iam get-credential-report \ --query 'Content' --output text | base64 -d > credential_report.csv# Flag users inactive for more than 90 days for offboarding reviewawk -F',' 'NR>1 && $5=="false" {print $1, $11}' credential_report.csv \ | while read user last_used; do echo "Review: $user last used $last_used" done
Access Review Policy Definition
Documenting an access review control for audit evidence.
yaml
control: CC6.1-access-reviewdescription: Quarterly review of user access to production systemsfrequency: quarterlyowner: security-teamevidence: - iam_access_report.csv - access_review_signoff.pdfremediation_sla_days: 5 # time to revoke unneeded access after review
COSO Framework Underlying the Common Criteria
SOC 2's Common Criteria (CC1-CC5) are built on the five components of the COSO Internal Control Framework.
- Control environment (CC1)- Tone at the top: integrity, ethics, board oversight, organizational structure, and accountability
- Communication and information (CC2)- Relevant information is identified, captured, and communicated internally and externally
- Risk assessment (CC3)- Objectives are specified clearly enough to identify and analyze risks to achieving them
- Monitoring activities (CC4)- Ongoing and separate evaluations confirm controls are present and functioning
- Control activities (CC5)- Policies and procedures that help ensure management directives are carried out
Common Criteria Reference (CC1-CC9)
Auditors cite control gaps by CC number; knowing the map speeds up evidence requests during fieldwork.
- CC1-CC5- The five COSO-derived components (environment, communication, risk assessment, monitoring, control activities)
- CC6- Logical and physical access controls: provisioning, authentication, encryption, and physical security
- CC7- System operations: vulnerability management, monitoring, and incident detection/response
- CC8- Change management: authorization, testing, and approval of system changes
- CC9- Risk mitigation: business continuity, disaster recovery, and vendor risk management
Policy-as-Code Check for CC6.1 (Access Control)
Continuously enforce and evidence a control rather than relying on a point-in-time manual review.
bash
#!/bin/bash# CC6.1 evidence: fail CI if any IAM user lacks MFA or has console access# without a recent access review sign-off on fileaws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read -r user; do mfa_count=$(aws iam list-mfa-devices --user-name "$user" --query 'length(MFADevices)' --output text) if [ "$mfa_count" -eq 0 ]; then echo "FAIL: CC6.1 violation - $user has no MFA device" >&2 exit_code=1 fidone# Evidence artifact for the auditor: timestamped pass/fail log per runecho "$(date -u +%FT%TZ) access-control-check exit=${exit_code:-0}" >> cc6_1_evidence.logexit "${exit_code:-0}"
CUECs and Subservice Organizations
Two concepts auditors probe when your own control environment depends on customers or vendors.
- Complementary User Entity Controls (CUECs)- Controls your customers must implement on their side (e.g. managing their own user access) for your controls to be effective; listed explicitly in the report
- Subservice organization- A vendor whose controls are relevant to your service (e.g. AWS for infrastructure)
- Carve-out method- Subservice org's controls are excluded from your report scope; you instead document monitoring of their SOC report
- Inclusive method- Subservice org's controls and testing are included directly within your own SOC 2 report
- Bridge letter- A gap-period attestation from a vendor covering the time between their last report's end date and your reliance date
Continuous Control Monitoring with OPA
Encode a control as a policy rule evaluated on every infrastructure change, closing gaps before the audit window samples them.
yaml
# rego-backed OPA policy check wired into CI, referenced as CC8.1 evidencepackage soc2.change_managementdeny[msg] { input.pull_request.approvals_count < 1 msg := "CC8.1 violation: change merged without required approval"}deny[msg] { input.resource.type == "aws_s3_bucket" input.resource.encryption == false msg := "CC6.1 violation: S3 bucket provisioned without encryption at rest"}# CI pipeline step:# opa eval --data policy.rego --input pr_metadata.json "data.soc2.change_management.deny"# Non-empty output blocks the merge and is archived as audit evidence
Pro Tip
Start collecting audit evidence continuously from day one of the observation period rather than scrambling before the audit — a Type II auditor will sample multiple months, and gaps in evidence for early months cannot be recreated retroactively.
Was this cheat sheet helpful?
Explore Topics
#SOC2Compliance#SOC2ComplianceCheatSheet#Cybersecurity#Intermediate#TrustServicesCriteria#TypeIVsTypeIIReports#CommonControlAreas#AutomatingEvidenceCollection#CheatSheet#SkillVeris
