By Editorial team · Published · Last updated
The full SOC 2 common criteria (CC1–CC9) explained, plus the additional criteria for Availability, Processing Integrity, Confidentiality, and Privacy.
This is a structured walkthrough of the AICPA's 2017 Trust Services Criteria — the framework every SOC 2 audit evaluates against. The Security category (CC1–CC9) is required. The other four categories add criteria on top when their scope is in play.
The common criteria are required for every SOC 2. They are organized into nine series: CC1 through CC9.
The foundation. Auditors look for a written code of conduct, a board or equivalent governance body that meets, defined roles and responsibilities, and evidence that the company holds people accountable for security responsibilities. For startups, CC1 evidence often includes the employee handbook, the offer letter language about confidentiality, and board minutes.
How security expectations and incidents move through the organization. Internal communication: security training, policy distribution, incident reporting channels. External communication: how customers learn about incidents, security commitments, and changes that affect them.
A documented, periodic process that identifies risks to your service commitments and system requirements, including fraud and risks introduced by significant change (new products, new vendors, new infrastructure). The risk register and the meeting minutes that show it being reviewed are typical evidence.
Continuous and periodic evaluations that confirm your controls are still working. This is where logging, alerting, vulnerability scanning, internal audits, and management review meetings live. Deficiency communication — how identified issues escalate to the right people — also belongs here.
Selection and development of controls, including IT general controls. Policies that turn objectives into action. CC5 is broad; many specific controls (segregation of duties, technology selection, baseline configuration) live here.
The largest series for most SaaS companies. Provisioning and deprovisioning, MFA, role-based access control, privileged access management, network segmentation, encryption in transit and at rest, physical access to facilities and assets. Most commonly-cited controls (MFA on production, access reviews quarterly, encryption keys managed by KMS) sit in CC6.
Detection and response. Vulnerability management programs, threat detection (SIEM, EDR, behavioral analytics), incident response plans and runbooks, post-incident analysis, recovery procedures. The plans matter, but so does evidence of incidents being handled per plan.
Changes to production systems are authorized, designed, tested, and approved before deployment. For modern engineering organizations, CC8 evidence is typically pull request reviews, CI/CD test gates, change tickets, and emergency change procedures. Infrastructure-as-code and database migration approvals often need separate consideration.
Risk mitigation activities not covered elsewhere — primarily business continuity, disaster recovery, and vendor risk management. The vendor risk management piece is often where CSOC (complementary subservice organization control) discussions land.
The P series is the longest, with criteria across notice, choice and consent, collection, use and retention, access, disclosure to third parties, quality, and monitoring and enforcement (P1–P8). When in scope, Privacy roughly doubles the size of the controls matrix.
There's no AICPA-mandated control count. Real reports for early-stage SaaS Security-only often run 60–100 controls. Mid-market reports adding Availability and Confidentiality typically run 100–150. Reports including Privacy and Processing Integrity routinely exceed 200. Compliance platforms (Vanta, Drata, Secureframe, Sprinto) ship pre-built control libraries that provide a starting point, but every organization's actual controls reflect its own architecture and operating model.