What the Common Criteria are
The Common Criteria, CC1 through CC9, are the control criteria that make up the Security category. They appear in every SOC 2 report regardless of which optional criteria you scope in — which makes them the only part of SOC 2 nobody gets to skip.
One thing to understand before the detail: SOC 2 defines criteria, not controls. There is no official list of "the SOC 2 controls" and no fixed number. You design controls that meet each criterion in your environment, and two companies can satisfy the same criterion with entirely different implementations. That is why SOC 2 scoping is a conversation rather than a form.
| Series | Name | The question it asks |
|---|---|---|
| CC1 | Control Environment | Does anyone actually own security here? |
| CC2 | Communication & Information | Do people know what is expected of them? |
| CC3 | Risk Assessment | Do you know what could go wrong? |
| CC4 | Monitoring Activities | Do you check that controls still work? |
| CC5 | Control Activities | Did you design controls against those risks? |
| CC6 | Logical & Physical Access | Who can reach what, and how do you know? |
| CC7 | System Operations | Do you detect and handle what happens? |
| CC8 | Change Management | Do changes go through a process? |
| CC9 | Risk Mitigation | What happens when something breaks or a vendor fails? |
CC1 — Control Environment
Governance. Someone senior is accountable for security, roles and reporting lines are defined, people are screened before hire, everyone acknowledges a code of conduct, and security awareness training happens and is tracked.
What small companies get wrong: assuming CC1 needs a committee. It does not. A ten-person company evidences CC1 with documented founder oversight and a training completion export. What it cannot do is evidence nothing.
CC2 — Communication and Information
Policies exist where people can find them, there is a channel to raise security concerns including anonymously, and commitments made to customers are communicated in writing.
The quiet failure: policies that live in a folder nobody has opened. Auditors ask employees where the policy is, not whether it exists.
CC3 — Risk Assessment
A formal risk assessment runs at least annually, risks are rated and owned and tracked to closure, fraud risk is considered explicitly, and third-party risk is assessed before onboarding a vendor.
The one people forget: fraud risk. It is explicitly called out, and a risk register with no fraud consideration draws a question every time.
CC4 — Monitoring Activities
Control performance is reviewed on a defined cadence, and deficiencies are logged, escalated and remediated. This is the criterion about checking your own homework.
The trap: CC4 requires evidence of review, not just evidence of the control. A quarterly access review satisfies CC6. Evidence that someone checked the access reviews were happening satisfies CC4.
CC5 — Control Activities
Controls are selected and documented against each identified risk, and technology controls are configured to policy and reviewed. CC5 is the bridge between CC3's risks and everything operational that follows.
How it differs from CC7: CC5 is design — deciding what controls should exist. CC7 is running — detecting what actually happens. Teams conflate them and end up documenting operations twice while designing nothing.
CC6 — Logical and Physical Access
The largest series and the source of most findings. Access granted on least privilege and approved, multi-factor authentication enforced on all production access, access reviews run quarterly and evidenced, offboarding revoking access within a defined SLA, data encrypted in transit and at rest, and physical access restricted.
The two controls that fail most often, across every SOC 2 we see:
MFA on production. Usually enforced for staff SSO and quietly absent on a service account, a legacy admin panel, or a database accessed through a bastion. Auditors look specifically for the exception.
Quarterly access reviews. Frequently run once, in the quarter before fieldwork. A Type 2 samples the whole window, so three missing quarters are three exceptions and no amount of catching up fixes them retroactively.
CC7 — System Operations
Vulnerability scanning on a defined schedule, logging and alerting across production, an incident response plan that has actually been tested, and incidents logged, classified and reviewed afterwards.
"Tested" is load-bearing. An incident response plan nobody has exercised is a document, not a control. A dated tabletop record with participants and findings is what satisfies this.
CC8 — Change Management
Changes reviewed and approved before release, development and staging separated from production, and a documented exception path for emergency changes.
Good news for engineering teams: if you already require pull request review before merge, your version control history is the evidence. CC8 is often the cheapest series to satisfy because the control already exists — it just was never described as a control.
The gap: emergency changes. Every team has a break-glass path; few have documented it, and undocumented exceptions are what auditors sample for.
CC9 — Risk Mitigation
Business continuity and disaster recovery plans exist, and vendor agreements include security and confidentiality terms.
Vendor terms are the sleeper. CC9 sends you back through every subprocessor contract looking for security clauses that may not be there. Start it early — it depends on counterparties responding, which is the one part of SOC 2 you cannot accelerate.
Where the findings actually cluster
| Series | Finding frequency | Most common cause |
|---|---|---|
| CC6 | Highest | MFA gaps on non-SSO paths; access reviews missing quarters |
| CC7 | High | IR plan never tested; scan cadence not maintained |
| CC4 | Moderate | No evidence of reviewing the controls themselves |
| CC9 | Moderate | Vendor agreements lacking security terms |
| CC1–CC3, CC5, CC8 | Lower | Usually documentation, quickly closed |
The pattern is consistent: the criteria that fail are the ones requiring something to happen repeatedly over time, not the ones requiring a document to exist. That is the difference a Type 2 is built to detect.
FAQs
What are the SOC 2 Common Criteria?
The Common Criteria, CC1 through CC9, are the control criteria that make up the Security category. They appear in every SOC 2 report regardless of which optional criteria you scope in, and they cover the control environment, communication, risk assessment, monitoring, control activities, access, operations, change management and risk mitigation.
How many controls are in SOC 2?
There is no fixed number. SOC 2 defines criteria, not a prescriptive control list, so you design controls that meet each criterion for your environment. Two companies can both satisfy CC6 with entirely different control sets. That flexibility is why SOC 2 scoping conversations matter more than in a standard with a fixed control count.
Which Common Criteria cause the most audit findings?
CC6, logical and physical access, by a wide margin. Within it, multi-factor authentication on production access and quarterly access reviews are the two controls most often found either missing or evidenced for only part of the observation window.
What is the difference between CC5 and CC7?
CC5 is about selecting and developing control activities — deciding what controls exist and documenting them against risks. CC7 is about system operations — detecting and responding to what actually happens, through monitoring, vulnerability management and incident response. CC5 is design; CC7 is running.
Do all nine Common Criteria apply to every company?
Yes, all nine apply to every SOC 2 report. What varies is how you satisfy them. A ten-person company and a five-hundred-person company both need CC1 governance, but one evidences it with documented founder oversight and the other with a security steering committee.
Where to go next
Work the controls in the SOC 2 compliance checklist, see what proves each one in SOC 2 evidence, decide your scope in the five criteria, or read SOC 2 compliance for the whole picture.