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
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
Advertisement
Sri Hayavadhana Info-Tech
Professional Web Designing Services
- Responsive Websites
- E-commerce Solutions
- SEO Friendly Design
- Fast & Secure
- Support & Maintenance
