The SOC 2 common criteria, CC1 to CC9
Security is the only mandatory Trust Services category, and it contains 33 criteria across nine series. This is what each series asks and what you have to produce to satisfy it.
The Security category of the Trust Services Criteria contains 33 criteria, numbered across nine series from CC1 to CC9. They are called the common criteria because every SOC 2 report includes them regardless of which optional categories you add. They describe outcomes, not controls: the criterion says what must be true, and you write the control that makes it true in your system.
33 Criteria in the Security category
CC6 and CC7 Where most evidence requests and most exceptions land
There is no AICPA list of SOC 2 controls, and any download that claims to be one is somebody's control set for somebody else's system. The criteria overview covers how the five categories fit together, and this page goes down a level into the one you cannot avoid.
CC1: the control environment
CC1 comes from the COSO internal control framework, which is why a security standard opens by asking about your board, your hiring and your code of conduct. Engineering-led companies find it the most surprising and the least technical series. It is also the fastest to satisfy: most of it is documentation you can write in an afternoon and then have to follow.
What the auditor asks for
An organization chart, a code of conduct signed by everybody, background check records for new hires, evidence that security responsibilities are assigned to named people, and security awareness training completion records for the period. Where there is no board, an advisor or the founding team performing documented oversight is accepted. Background checks are a common Canadian sticking point, since provincial privacy rules and employment practice vary. What an auditor accepts is a consistent, documented policy rather than any particular check.
CC2: communication and information
CC2 asks whether the right information reaches the right people, inside and outside the company. Externally that means your published security commitments, your terms, and a way for a customer or a researcher to report a problem. Internally it means policies that were distributed and acknowledged rather than written and filed.
A security page on your website, a security contact address that is monitored, policy acknowledgement records, and evidence that incidents or concerns can be raised without going through the person responsible for the problem. If you publish a vulnerability disclosure address, the auditor may ask what happened to the reports.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
CC3: risk assessment
CC3 wants a risk assessment that happened, was written down, produced decisions, and was revisited. The most common failure is not the absence of a risk register but a register created two weeks before fieldwork with no evidence anyone looked at it since.
A dated risk register with owners, likelihood and impact, treatment decisions including accepted risks, and minutes or a document showing the annual review. Fraud risk gets its own criterion and is usually satisfied by considering insider misuse and financial fraud explicitly rather than by a separate exercise.
CC4: monitoring of controls
CC4 is about whether you check that your own controls are working, separately from the auditor checking. Internal control reviews, vulnerability scanning with remediation tracked to closure, and evidence that deficiencies found internally were communicated and fixed.
This is where a compliance platform earns its subscription: continuous monitoring output is this evidence. It is also satisfiable manually with a scan schedule and a ticket queue. The platform page covers when the subscription is worth it and when it is not.
CC5: control activities
CC5 is the bridge between policy and configuration. It asks whether you selected and developed control activities that address the risks in CC3, including controls in technology, and whether policy has been turned into something operating. In practice auditors test CC5 through the other series, and it rarely produces its own evidence pile.
CC6: logical and physical access
CC6 is the largest series and produces more requests than any other. It covers identity, authentication, authorization, provisioning and deprovisioning, periodic access review, encryption in transit and at rest, key management, physical access to facilities, and the disposal of media and hardware.
The requests that arrive under CC6
0 of 0 ready ยท
Two of those consistently produce exceptions. Access reviews get skipped in a busy quarter, and offboarding runs late because HR told IT after the fact. Both are on the list of exceptions Canadian companies actually collect.
CC7: system operations
CC7 covers monitoring, detection, vulnerability management and incident response. The auditor wants alerting that exists, evidence somebody responded to alerts, vulnerabilities identified and remediated inside your own stated timeframes, and an incident response plan that has been exercised.
Write your remediation timeframes as something you can meet. The criterion is measured against your own policy, and a policy promising critical fixes in 24 hours produces exceptions that a 7 day policy would not. If you had no incidents in the period, run a tabletop exercise and keep the notes. "No incidents" is not evidence that the plan works. Your auditor will also expect a penetration test in this area, which GetPentest covers in detail.
CC8: change management
CC8 asks whether changes to infrastructure, data, software and procedures are authorized, designed, tested and approved before they go live. For most software companies this is tested straight out of the version control system: a sample of pull requests, the approval on each, the link to a ticket, and evidence that tests ran.
The recurring problem is emergency changes. Every company has them, few document a path for them, and a merged pull request with no second approver becomes an exception. Write an emergency change procedure that says who can authorise a bypass and what gets recorded afterwards, then follow it.
CC9: risk mitigation
CC9 covers business disruption and vendor risk. It is where your vendor management program, your subservice organization reviews and your business continuity arrangements are tested. Evidence is a vendor register with risk ratings, records of reviewing each significant vendor's own SOC 2 report, and a continuity or disaster recovery plan with evidence it was tested.
Vendor reviews are the classic year one exception: the register gets built during readiness and then nothing happens to it for eleven months. Running the program properly takes an hour a quarter and removes a finding.
Where to put readiness effort
| Series | Relative evidence volume | Chance of a first-year exception |
|---|---|---|
| CC1 control environment | Low | Low, unless training was missed |
| CC2 communication | Low | Low |
| CC3 risk assessment | Low | Moderate, if the register is stale |
| CC4 monitoring | Moderate | Moderate |
| CC5 control activities | Low | Low |
| CC6 access | High | High |
| CC7 operations | High | High |
| CC8 change management | Moderate | Moderate to high |
| CC9 vendor and continuity | Moderate | High |
Points of focus are examples, not requirements
Each criterion carries AICPA points of focus illustrating what meeting it might look like. They are not a checklist and you are not required to implement each one. An auditor who treats them as mandatory is applying the framework more strictly than it is written, and it is fair to ask which criterion a requested control is meant to satisfy.
Find out where your gaps are
A gap assessment against these 33 criteria is a fixed-scope piece of work. Get it priced by Canadian firms.
Get matchedCommon questions
How many common criteria are there in SOC 2?
There are 33 criteria in the Security category, spread across nine series numbered CC1 to CC9. The number of controls you write to satisfy them is a different question entirely and depends on your system. Companies commonly end up with somewhere between 60 and 130 controls.
Is Security the same thing as the common criteria?
Yes. The Security category and the common criteria are two names for the same set. They are called common because they appear in every SOC 2 report whether or not you include Availability, Confidentiality, Processing Integrity or Privacy.
Which series causes the most trouble?
CC6, logical and physical access. It is the largest series, it generates the most evidence requests, and the two controls most likely to fail in a first year sit inside it: periodic access reviews and timely removal of departed users. CC7 and CC9 are the next most likely to produce exceptions.
Do we need a board to satisfy CC1?
No. The criterion asks for oversight of internal control by people independent of day to day operations. A small company satisfies it with a founding team or an advisor performing documented reviews. What auditors will not accept is nothing, or a single person overseeing their own work with no record.