The SOC 2 common criteria, CC1 to CC9
Your auditor's request list is written in CC numbers. This page translates all nine families back into work you can assign to somebody.
There are 33 common criteria in the 2017 Trust Services Criteria, grouped into nine families numbered CC1 through CC9. Every SOC 2 report tests all 33, because the common criteria are the security category, and security is the only category you cannot opt out of. Availability, confidentiality, processing integrity and privacy add further criteria on top; they do not replace any of these.
33 Common criteria in a security-only SOC 2
CC6 Largest family, 8 criteria, mostly access
CC8 Smallest family, 1 criterion, all of change
All of change management sits under a single criterion, CC8.1, and it is still one of the two heaviest evidence loads in the audit, because CC8.1 covers authorization, design, development, configuration, documentation, testing, approval and implementation of every change to infrastructure, data, software and procedures. The criterion count tells you nothing about the work. The table below does.
What does each CC family ask for?
| Family | Criteria | What it asks | What you hand over |
|---|---|---|---|
| CC1 Control environment | 5 | That somebody is accountable, competent and overseen | Org chart, board or advisor minutes, job descriptions, background checks, code of conduct |
| CC2 Communication and information | 3 | That security expectations reach staff and customers | Policy acknowledgements, onboarding decks, status page, customer commitments in contracts |
| CC3 Risk assessment | 4 | That you have written down what could go wrong, including fraud | Risk register with owners and treatment decisions, dated and reviewed |
| CC4 Monitoring activities | 2 | That you check your own controls and act on what you find | Internal control review notes, deficiency log, management review minutes |
| CC5 Control activities | 3 | That controls are chosen deliberately and written into policy | Control matrix mapped to risks, approved policy set, procedure documents |
| CC6 Logical and physical access | 8 | Who can reach what, how they got it, and how it is taken away | Access reviews, joiner and leaver records, MFA enforcement, encryption config, asset disposal records |
| CC7 System operations | 5 | That you would notice a problem and know what to do | Scan reports, alert rules, incident log, tabletop notes, recovery records |
| CC8 Change management | 1 | That changes are reviewed, tested and approved before they ship | Pull requests, branch protection settings, pipeline runs, emergency change approvals |
| CC9 Risk mitigation | 2 | That disruption and vendors are both handled deliberately | Continuity plan, insurance where relevant, vendor register and reviews |
| Total, security category | 33 | Every SOC 2 report tests all of these | |
Which families does a first audit fail on?
Not the technical ones. Engineering-led companies arrive with CC6 and CC8 in reasonable shape, because access control and code review are things engineers already care about. The exceptions in first reports cluster in CC1, CC3 and CC4, which are the governance families: nobody wrote down who is accountable, there is no risk register, and nobody has ever reviewed whether the controls worked.
That changes where you spend your first month. If you are triaging, the ordered list below is the one to work, and the readiness scorecard will score you section by section against roughly the same shape.
- CC3 first. The risk register feeds CC5, CC9 and half of your policy set, and it takes an afternoon to start.
- CC1 next. An org chart, a written accountability statement and a code of conduct are documents, not projects.
- CC6 third, because it is the largest family and the access review cycle has to run inside your window.
- CC7 fourth. Log retention has to be extended before the window opens, since retention cannot be applied to logs already deleted.
- CC4 last, because you cannot review controls that do not exist yet, but do not skip it. A report with no monitoring evidence reads as a program nobody is running.
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.
How do I map my controls to these?
You do not need a one-to-one map. SOC 2 defines criteria and you choose the controls that meet them, so one control frequently satisfies several criteria and some criteria take three controls between them. What the auditor needs is a matrix with a row per control saying which criteria it addresses, who owns it, how often it runs and what artifact proves it ran. That matrix is the deliverable, not the mapping exercise.
Build it once from the checklist, which is organized by the work rather than by criterion, then add the criterion column last. Doing it the other way round produces a document that reads well and describes nothing you actually do. If you have not yet settled what is inside the boundary, the scope and system description page comes before all of this, because the criteria apply to the system you described and to nothing else.
Criteria are not controls, and the number is not fixed
There is no such thing as "the 33 SOC 2 controls". There are 33 criteria and an unbounded number of ways to meet them. A first audit against security alone usually ends up with sixty to a hundred controls depending on how finely you split them. If a vendor tells you their platform gives you the SOC 2 controls, they mean their opinionated control set, which your auditor is free to disagree with.
What if we added availability or confidentiality?
Additional categories add their own criteria on top of the 33. Availability adds three (A1.1 to A1.3), covering capacity, environmental protections and recovery testing. Confidentiality adds two (C1.1 and C1.2), covering identification and disposal of confidential information. Processing integrity and privacy add considerably more, and privacy in particular is a large undertaking that most first audits should skip.
Take a category only when a customer asked for it in writing or your contracts commit you to an uptime number you would rather have tested by somebody neutral. Adding availability because it sounds better on a sales call costs you three more criteria, a capacity monitoring control and a recovery test you now have to evidence every year. The criteria breakdown on GetSOC2 covers the choice from the report-buyer's side if you want the other half of the argument.
Track the nine families
0 of 9 done ·
Want a second opinion before fieldwork
Tell us your scope, your headcount and the date the report has to exist by, and we will put it in front of Canadian readiness firms.
Get matchedCommon questions
How many SOC 2 common criteria are there?
Thirty-three, across nine families numbered CC1 to CC9. That count covers the security category, which every SOC 2 report includes. Choosing availability, confidentiality, processing integrity or privacy on top adds further criteria specific to those categories.
Do we have to meet every common criterion?
Yes. The common criteria are not a menu. What varies is the control you use to meet each one, and how much a criterion costs you: CC6.4 on physical access is a short conversation for a fully remote company using a cloud provider whose own SOC 2 report covers the data centre, and a real project for a company with a server room.
What is the difference between CC criteria and the points of focus?
The criteria are what you must meet. The points of focus underneath each one are illustrations the AICPA added to explain what the criterion might look like in practice, and they are explicitly not requirements. An auditor who insists you satisfy every point of focus is applying their own house standard, which they are allowed to do, but you are allowed to ask why.
Which criteria need evidence across the whole observation window?
Anything with a cadence. Access reviews under CC6.3, scanning and monitoring under CC7.1 and CC7.2, change approvals under CC8.1 and vendor reviews under CC9.2 all have to show a run of evidence across the period rather than a single sample. Point-in-time criteria such as CC6.4 physical access can usually be evidenced once.
Can we use the same control for more than one criterion?
Yes, and you should. A single access review covering production, the cloud console, the code repository and the identity provider will be cited against several CC6 criteria at once. Splitting one real activity into four paper controls creates four evidence obligations for one piece of work.