SOC 220 April 2026 10 min read

SOC 2 Security Criteria: CC1–CC9 Explained Simply

A practical breakdown of all nine SOC 2 Security Common Criteria groups — what each covers, which are hardest to satisfy, and where most exceptions occur.

Key Takeaways

CC1–CC9 form the mandatory Security TSC with 33 criteria — all must be addressed in every SOC 2 engagement.
CC6 (Logical Access, 8 criteria) generates more evidence and more exceptions than any other group.
CC3 (Risk Assessment) and CC9 (Vendor Management) are routinely underimplemented by engineering-focused teams.
CC7 (System Operations) requires a penetration test at least annually — this is non-negotiable.
CC4 (Monitoring) rewards companies that use automated control monitoring — auditors view continuous monitoring evidence more favorably than periodic manual checks.

In this guide

CC1–CC2: Control Environment and Communication
CC3–CC4: Risk Assessment and Monitoring
CC5: Control Activities
CC6: Logical and Physical Access — The Hardest Group
CC7: System Operations
CC8: Change Management
CC9: Risk Mitigation and Vendor Management

CC1–CC2: Control Environment and Communication

CC1 (5 criteria) establishes the governance foundation of your security program. It covers leadership commitment to integrity, board oversight of security risk, organizational accountability, HR processes ensuring competence, and performance management. For most startups, CC1 evidence comes from HR documentation (offer letters, handbooks, training records) and leadership meeting records showing security is on the agenda.

CC2 (3 criteria) covers information flows — internal communications about security and external communications with customers and regulators. Evidence includes internal security communications (policy distribution emails, all-hands security updates) and external communications (privacy policy, security page, customer breach notifications). CC2 is rarely the source of exceptions because evidence is plentiful in normal business operations.

CC3–CC4: Risk Assessment and Monitoring

CC3 (3 criteria) requires a formal risk assessment process. Many startups don't have one — security discussions happen in engineering standups but are never captured in a risk register. Implementing CC3 requires: creating a risk register, conducting an annual risk assessment meeting with leadership, documenting risk treatment decisions (mitigate, accept, transfer), and assigning risk owners. The risk register doesn't need to be elaborate — a well-maintained spreadsheet with 15–30 identified risks satisfies CC3 for most early-stage companies.

CC4 (2 criteria) requires monitoring that controls are working and that deficiencies are corrected. This is where automated control monitoring pays off — if your compliance platform continuously checks AWS Config rules, GitHub branch protection settings, and Okta MFA status, you have real-time evidence for CC4.1. Manual periodic reviews are acceptable but require more documentation effort.

CC5: Control Activities

CC5 (3 criteria) requires that controls are selected, designed, and deployed through policies and procedures. This group is primarily evidenced through your policy set and control documentation framework. CC5.1 requires that you select and develop controls to address risks identified in CC3. CC5.2 requires that technology general controls are selected. CC5.3 requires that controls are deployed through documented policies and procedures.

CC5 is where your control framework documentation is evaluated. Auditors want to see that your controls are intentional — that you identified risks, selected controls to address them, and documented those controls in policies. A company that has good technical controls but no written documentation connecting those controls to specific risks will struggle with CC5.1.

CC6: Logical and Physical Access — The Hardest Group

CC6 contains 8 criteria and is consistently the source of the most SOC 2 exceptions. CC6.1 covers logical access security controls (SSO, MFA, network access controls, encryption). CC6.2 covers access provisioning and de-provisioning. CC6.3 covers role-based access and segregation of duties. CC6.4 covers physical access to data centers (satisfied by AWS's SOC 2 for cloud companies). CC6.5 covers authorized logical access. CC6.6 covers access management for personnel changes. CC6.7 covers network access restrictions. CC6.8 covers malware prevention.

The most exception-prone CC6 criteria are CC6.2 (access removal not timely after termination), CC6.3 (developers with production database write access violating segregation of duties), and CC6.5 (access review not conducted on schedule). All three are operational failures rather than technical gaps — the controls exist but aren't consistently executed.

Automating CC6 compliance is the highest-ROI investment in any SOC 2 program. An automated access review workflow (quarterly trigger, manager approval routing, completion tracking) eliminates CC6.5 exceptions entirely. An automated off-boarding checklist in your HRIS eliminates CC6.2 exceptions. A compliance platform that continuously monitors user access lists for terminated employees eliminates both.

CC7: System Operations

CC7 (5 criteria) covers ongoing security operations: vulnerability management (CC7.1), environmental threat detection (CC7.2), incident identification and response (CC7.3), incident communication (CC7.4), and incident recovery (CC7.5).

CC7.1 requires vulnerability monitoring throughout the observation period. Auditors want to see: automated vulnerability scanning (Snyk, Dependabot, AWS Inspector) configured and running; scan reports from multiple points in the observation period; a process for prioritizing and remediating vulnerabilities; evidence that high/critical vulnerabilities were remediated within your stated SLA.

A penetration test is expected under CC7.1 at least annually. The pen test doesn't need to be exhaustive — a focused application pen test by a qualified firm addressing OWASP Top 10 and relevant infrastructure is sufficient for most B2B SaaS companies. The cost is $5,000–$15,000. The report and remediation tracking are key evidence items.

CC8: Change Management

CC8 has a single criterion (CC8.1) but it is broad and evidence-intensive: all changes to infrastructure, data, software, and procedures must be authorized, designed, developed, tested, and approved. The auditor samples production deployments and traces each through the change management process.

For code changes: evidence is GitHub PRs with required approvals and passing CI checks. For infrastructure changes: Terraform PRs with the same review requirements, or AWS Systems Manager Change Manager records. For emergency changes: post-incident change records with retroactive approval.

CC8.1 exceptions are almost always one of: (1) a developer with direct push-to-main access who bypassed the PR process, (2) an infrastructure change made through the AWS console without a corresponding ticket, or (3) an emergency change with no retroactive review. All three are preventable with branch protection policies and an IaC-first infrastructure practice.

CC9: Risk Mitigation and Vendor Management

CC9 (2 criteria) covers risk mitigation planning (CC9.1) and third-party risk management (CC9.2). CC9.1 requires that identified risks have documented mitigation plans. CC9.2 requires that third-party vendors are assessed and monitored.

CC9.2 is the classic gap for engineering-led companies. The typical startup has 20–40 SaaS vendors with access to customer data or critical systems and has never formally assessed any of them. Implementing CC9.2 requires: creating a vendor inventory, defining what qualifies as a "critical" vendor, establishing a vendor risk assessment process (typically reviewing the vendor's SOC 2 report or completing a security questionnaire), and conducting annual re-assessments.

For large, well-known vendors like AWS, Stripe, and Okta, downloading their SOC 2 report and noting the review date in your vendor inventory is sufficient. For smaller or less mature vendors, a security questionnaire (using a standard like the SIG Lite or CAIQ) is appropriate. Critical vendors without SOC 2 reports require a more detailed assessment — or a decision to accept the risk with documented justification.

Frequently Asked Questions

Which CC group has the most evidence requirements?

CC6 (Logical Access) has the most ongoing evidence requirements because access management is a continuous operational activity. Every quarterly access review, every onboarding and offboarding event, and every role change generates evidence. Across a 12-month observation period, a 50-person company might generate 200+ CC6 evidence items. Automating this collection is essential for managing the volume.

Can CC3 be satisfied without a dedicated risk management team?

Yes — for startups and small companies, the CTO or Head of Engineering can own the risk assessment process. The requirement is for a structured annual process, not a dedicated team. A well-facilitated 2-hour risk assessment workshop with the leadership team, producing a documented risk register with owner assignments and treatment decisions, satisfies CC3 for companies under 50 employees.

Is a pen test required for SOC 2?

Penetration testing is not explicitly named in the AICPA criteria, but CC7.1 requires that vulnerabilities in system components are detected and monitored. Auditors universally interpret this as requiring periodic penetration testing. In practice, "annually" is the standard expectation. A company that has never had a pen test will not receive a clean SOC 2 opinion on CC7.1.

Does CC6.4 apply to companies using cloud hosting?

CC6.4 covers physical access to data centers. For cloud-hosted companies, this is addressed through the carve-out method: AWS's physical security is covered by AWS's own SOC 2 report, which you reference in your system description as a complementary subservice organization control. You don't need to personally audit AWS data centers. You do need to have AWS's SOC 2 report in your vendor management review (CC9.2).

What is segregation of duties and why does CC6.3 require it?

Segregation of duties (SoD) is the principle that no single individual should have both the ability to authorize a transaction and the ability to execute it — preventing both accidental errors and fraud. In a development context, CC6.3 requires that developers cannot both write code and deploy it to production without another person's approval. Branch protection with required reviewers is the standard technical control for code SoD. For sensitive data operations (production database writes, financial transactions), similar review requirements apply.