SOC 2 Compliance — Trust Services Criteria¶
What This Skill Does¶
This skill guides you through SOC 2 Type 1 and Type 2 readiness: understanding the Trust Services Criteria (TSC), identifying the minimum required policy set, collecting evidence for auditors, and mapping SOC 2 controls to NIST 800-53. It covers common gaps in SaaS and cloud environments and provides actionable audit preparation checklists.
Framework Overview¶
SOC 2 is an AICPA (American Institute of Certified Public Accountants) framework for reporting on the internal controls of service organizations. It is NOT a certification — it is an audit-based attestation report.
Types of SOC 2 reports: - Type 1: Point-in-time assessment. The auditor opines that controls are suitably designed as of a specific date. Faster (2-4 months); lower cost; limited assurance. - Type 2: Period-based assessment (typically 6-12 months). The auditor opines that controls are suitably designed AND operated effectively over the audit period. Higher assurance; required by most enterprise customers and regulated industries.
Who needs SOC 2: - SaaS companies that handle customer data - Cloud infrastructure and managed service providers - Any B2B technology company responding to enterprise security questionnaires - Companies handling healthcare, financial, or government data (often required)
The report is: - Issued by a licensed CPA firm (not a consultant or certifying body) - Scoped to specific Trust Service Categories elected by management - Shared under NDA with customers and prospects
The Five Trust Service Categories (TSC)¶
Security (CC — Common Criteria) — ALWAYS REQUIRED¶
The foundational category. Every SOC 2 report must include Security. The Common Criteria (CC) covers logical and physical access controls, change management, risk management, and monitoring.
Security is organized into CC1–CC9 subcriteria:
CC1: Control Environment - Commitment to integrity and ethical values (tone at the top) - Board/management oversight of security program - Organizational structure and reporting lines
CC2: Communication and Information - Internal communication of security responsibilities - External communication to relevant parties about security obligations
CC3: Risk Assessment - Identify and analyze risks to achieving security objectives - Fraud risk assessment - Changes to systems/processes that create new risks
CC4: Monitoring Activities - Ongoing and separate evaluations of controls - Deficiency identification and remediation
CC5: Control Activities (Policies) - Selection and development of controls - Technology controls (general IT controls) - Policy deployment and enforcement
CC6: Logical and Physical Access Controls - User access provisioning, de-provisioning, and reviews - Principle of least privilege - Multi-factor authentication - Physical facility access controls - Encryption of data at rest and in transit - Network security and segmentation
CC7: System Operations - Detection and monitoring of new vulnerabilities - System monitoring and anomaly detection - Incident identification and response - Change management and infrastructure reliability
CC8: Change Management - Controlled change process (development → testing → production) - Software development lifecycle controls - Infrastructure change controls - Emergency change procedures
CC9: Risk Mitigation - Risk treatment and mitigation strategies - Vendor/third-party risk management (subservice organizations) - Business disruption risk
Availability (A) — Optional¶
The system is available for operation and use as committed or agreed.
Covers: uptime SLA commitments, redundancy and failover, backup and recovery, capacity management, incident response for availability events, DR testing.
Include if: You have SLA commitments to customers; customers depend on uptime for their operations; you are a SaaS platform where downtime = customer revenue loss.
Processing Integrity (PI) — Optional¶
System processing is complete, accurate, timely, and authorized.
Covers: Input validation, processing controls, error handling, output accuracy, transactional completeness, anomaly detection in processing.
Include if: You process financial transactions, payroll, healthcare data processing, or any workflow where processing errors have material consequences.
Confidentiality (C) — Optional¶
Information designated as confidential is protected as committed or agreed.
Covers: Data classification, confidentiality agreements (NDAs), encryption of confidential data, access restrictions to confidential information, secure disposal.
Include if: You handle customer-designated confidential data, IP, trade secrets, or regulated data categories where confidentiality is a contractual or regulatory obligation.
Privacy (P) — Optional¶
Personal information is collected, used, retained, disclosed, and disposed of in conformity with the entity's privacy notice and GAPP.
Covers: Notice and consent, data collection limitation, use/retention/disposal, access to personal data, disclosure to third parties, security of personal data.
Include if: You collect or process personal information and have made privacy commitments (GDPR alignment, CCPA compliance, etc.).
Minimum Policy Set for SOC 2 Type 2¶
The following policies are required to satisfy the Common Criteria and any additional TSC categories elected. These come from the SOC2-Type2 Minimum Policy Set documentation.
1. Information Security Policy¶
The overarching policy defining the organization's approach to information security. - Roles and responsibilities for information security - Acceptable use rules for systems and data - Consequences for policy violations - Annual review and update process - Executive sign-off and communication to all personnel
2. Access Control Policy¶
Defines who has access to what information and the procedures for granting and revoking access. - User provisioning and de-provisioning process - Principle of least privilege requirements - Access review frequency (quarterly for privileged; semi-annual for standard) - Segregation of duties requirements - Privileged access management rules - Remote access controls
3. Data Encryption Policy¶
Outlines how and when data is encrypted, both at rest and in transit. - Encryption standards (AES-256 at rest; TLS 1.2+ in transit) - Key management and rotation schedule - Encryption requirements for portable devices and storage media - Certificate management procedures
4. Incident Response Policy¶
Details how to respond to a security incident. - Incident classification and severity definitions - Roles and responsibilities (IR team) - Incident detection and reporting procedures - Containment, eradication, and recovery steps - Communication plan (internal; customer notification) - Post-incident review and lessons learned - Retention of incident records
5. Disaster Recovery and Business Continuity Plan (BCP/DRP)¶
Outlines how the organization recovers from a disaster or significant event. - Business impact analysis (BIA) with RTO/RPO for critical systems - Recovery procedures per system/service - Backup strategy and verification - DR testing schedule (annual minimum for Type 2) - Communication and escalation tree
6. Change Management Policy¶
Controls how changes to the IT environment are requested, approved, tested, and deployed. - Change request and approval workflow - Separation of duties: developers cannot deploy to production unilaterally - Testing requirements before promotion to production - Emergency change procedures - Rollback procedures - Change log maintenance
7. Risk Assessment Policy¶
Outlines how risks are identified, evaluated, and mitigated. - Risk assessment methodology and frequency (annual minimum) - Risk scoring criteria (likelihood × impact) - Risk acceptance criteria - Risk treatment options (accept, mitigate, transfer, avoid) - Risk register ownership and maintenance
8. Vendor Management Policy¶
Governs evaluation and monitoring of third-party vendors. - Vendor risk tiering (critical, significant, standard) - Security due diligence requirements by tier - Contract requirements (security obligations, audit rights, breach notification) - Annual review of critical vendors - Subservice organization monitoring (for SOC 2 carve-out or inclusive reports)
9. Data Backup Policy¶
Outlines how and when data is backed up, and how it can be restored. - Backup frequency per data classification/criticality - Backup storage location (offsite/cloud) - Encryption of backups - Restoration testing frequency (quarterly recommended) - Retention periods
10. Network Security Policy¶
Documents network protection controls. - Firewall and network segmentation requirements - Intrusion detection/prevention systems - Wireless network controls - Network monitoring and alerting - Remote access VPN requirements
11. Data Retention and Disposal Policy¶
Governs how long data is kept and how it is securely disposed of. - Retention periods by data category - Legal hold procedures - Secure disposal methods (shredding, NIST 800-88 media sanitization) - Records of destruction
12. Privacy Policy (if Privacy TSC selected)¶
Covers collection, use, retention, disclosure, and disposal of personal information. - Data subject rights (access, deletion, correction) - Cookie and tracking disclosures - Third-party sharing disclosures - Data breach notification commitments
Control Mapping: SOC 2 Common Criteria to NIST 800-53¶
SOC 2 auditors increasingly expect organizations to be able to map their controls to established frameworks. The mapping from TSC to NIST 800-53 is published by the AICPA.
| SOC 2 Criteria | NIST 800-53 Control Families |
|---|---|
| CC1 (Control Environment) | PM (Program Management), AT (Awareness & Training) |
| CC2 (Communication) | PL (Planning), PM |
| CC3 (Risk Assessment) | RA (Risk Assessment), PM |
| CC4 (Monitoring) | CA (Assessment), AU (Audit) |
| CC5 (Control Activities) | PL, SA (System Acquisition), PM |
| CC6.1 (Logical Access — Identification) | IA (Identification & Authentication) |
| CC6.2 (Logical Access — Provisioning) | AC (Access Control) |
| CC6.3 (Role-Based Access) | AC |
| CC6.6 (External Threats — Boundary) | SC (System & Comms Protection), SI |
| CC6.7 (Encryption) | SC, MP (Media Protection) |
| CC6.8 (Malware Protection) | SI |
| CC7.1 (Vulnerability Management) | RA, SI, CA |
| CC7.2 (Monitoring) | AU, SI, IR |
| CC7.3–CC7.5 (Incident Response) | IR (Incident Response) |
| CC8 (Change Management) | CM (Configuration Management), SA |
| CC9 (Risk Mitigation / Vendors) | SA-9, PM |
| A1 (Availability) | CP (Contingency Planning), SC |
| PI1 (Processing Integrity) | SI, AU |
| C1 (Confidentiality) | AC, SC, MP |
| P1–P8 (Privacy) | PT (PII Processing) |
Evidence Collection for Auditors¶
SOC 2 auditors (for Type 2) will request evidence of control operation over the entire audit period. Evidence must be dated to show it occurred during the period under review.
Access Control Evidence¶
- [ ] User access list with roles — point in time + evidence of periodic review
- [ ] Terminated employee access revocation records (show prompt deprovisioning)
- [ ] MFA enrollment confirmation for all users
- [ ] Privileged access request and approval tickets
- [ ] Access review documentation (reviewer sign-off, date, actions taken)
- [ ] New employee access provisioning records
Change Management Evidence¶
- [ ] Git commit history and pull request approvals showing peer review
- [ ] Deployment records (who deployed what, when, from which environment)
- [ ] Change tickets with approvals and test results
- [ ] Separation of duties evidence: developers cannot merge their own PRs
- [ ] Production deployment approvals (separate from development team)
Security Monitoring Evidence¶
- [ ] Vulnerability scan reports with dates (quarterly minimum)
- [ ] Penetration test report (annual)
- [ ] SIEM/log monitoring screenshots showing active alerting
- [ ] Alert investigation records
- [ ] Patch deployment records aligned to vulnerability reports
Vendor Management Evidence¶
- [ ] Vendor inventory with tier classifications
- [ ] SOC 2 reports or security questionnaire responses from critical vendors
- [ ] Vendor contracts with security clauses
- [ ] Annual review documentation
Incident Response Evidence¶
- [ ] Incident log (even if no major incidents — log minor events)
- [ ] Tabletop exercise record (scenario, attendees, findings, actions)
- [ ] IRP document with version history
- [ ] For any incidents during period: incident ticket, timeline, resolution, notifications
Business Continuity / DR Evidence¶
- [ ] BCP/DRP document with RTO/RPO definitions
- [ ] DR test results (restore from backup, failover test)
- [ ] Backup job success logs
- [ ] Restoration test records (did the backup actually restore?)
Common SOC 2 Gaps in SaaS/Cloud Environments¶
No Formal Access Review Process (CC6.2, CC6.3)¶
Gap: User access is provisioned but never reviewed; departed employees may retain access. Fix: Implement quarterly access reviews in Jira, Vanta, Drata, or a spreadsheet. Document who reviewed, when, what changes were made. Automate deprovisioning via HRIS-SSO integration.
Developers Can Deploy to Production (CC8)¶
Gap: Engineers have direct production deployment access; no separation of duties. Fix: Require pull request approval from a second engineer. Restrict production deployments to CI/CD pipeline with approvals. Even for small teams, document the control: "Engineer A writes code; Engineer B reviews and approves before merge; CI/CD deploys."
No Documented Incident Response Testing (CC7.3–CC7.5)¶
Gap: IRP exists on paper but has never been tested. Fix: Conduct a tabletop exercise (even 1 hour with 3 people). Document scenario, participants, walk-through, and action items. Auditors want evidence of testing, not just the plan.
Monitoring Without Investigation Records (CC7.2)¶
Gap: SIEM generates alerts but no records of alert investigation. Fix: Create a simple alert log: date, alert type, who investigated, finding, action taken. Even "investigated, false positive, no action required" counts.
Vendor SOC Reports Not Collected (CC9.2)¶
Gap: Critical cloud providers (AWS, Stripe, Salesforce) not included in vendor management program. Fix: Download SOC 2 reports for critical subservice organizations annually (most are available via their trust portals). Document where you reviewed them and what you found.
Backup Restoration Not Tested (A1, if Availability in scope)¶
Gap: Backups run but restoration is never verified. Fix: Perform a documented restoration test at least annually. Restore to a non-production environment and confirm data integrity. Record date, what was restored, results.
Readiness Assessment Checklist¶
Before engaging a SOC 2 auditor, verify:
Governance - [ ] Information Security Policy approved and distributed - [ ] All minimum policies exist (12 policies above) - [ ] Risk assessment completed in last 12 months - [ ] Security awareness training completed by all personnel
Access Controls - [ ] MFA enabled for all systems in scope - [ ] Privileged access documented and reviewed - [ ] Terminated employees removed from all systems (documented process) - [ ] Access provisioning follows documented approval process
Change Management - [ ] Code review/PR approval process enforced in version control - [ ] CI/CD pipeline has approval gates before production - [ ] Change log maintained for infrastructure changes
Monitoring - [ ] Security alerts configured and investigated - [ ] Vulnerability scans running and documented - [ ] Log retention meets audit period (12 months)
Availability (if in scope) - [ ] Backup policy defined and implemented - [ ] Restoration test completed and documented - [ ] DR/BCP plan tested in last 12 months
Vendors - [ ] Critical vendor list maintained - [ ] SOC 2 reports collected for critical SaaS/cloud vendors
Plugin: compliance-frameworks · View SKILL.md on GitHub