SOC 2 controls list
There is no official list of SOC 2 controls. The AICPA publishes criteria that describe what has to be achieved; you write the controls that achieve them. This page shows the 38 criteria this site maps, sixteen example controls a small SaaS company actually runs, and the evidence each one leaves behind.
Criteria come from the AICPA, controls come from you
Every list of “the SOC 2 controls” you find online is somebody else’s control list. The standard itself does not contain one. What it contains is the Trust Services Criteria: 33 common criteria that appear in every SOC 2 report, plus optional categories for availability, confidentiality, processing integrity and privacy that only apply if you put them in scope.
This matters when you are preparing. A criterion such as CC6.2 says that access is granted to authorized people and removed when it is no longer needed. It does not say which ticket system to use, how many approvers you need, or whether offboarding runs from a script or a checklist. Those are your decisions, and they become your controls. The auditor then tests the controls you described, not a generic list.
The practical consequence: copying another company’s control list gives you controls you do not operate. It is faster to write down what you already do, check it against the criteria, and close the gaps that are left.
Criterion, control, policy, evidence
Most of the confusion around this topic comes from treating four different things as one. Keeping them apart makes the work much easier to plan:
- Criterion. Published by the AICPA and numbered, for example CC6.1 or A1.2. Identical for every company; not something you write.
- Control. What your company does about that criterion. You write it, and it should name a system, a frequency and an owner.
- Policy. The document that states the control is required and describes the procedure behind it. Documentation, not operation.
- Evidence. What the control leaves behind when it runs: a ticket, a dated export, a signed form, a reviewer attestation, a test record.
These are not interchangeable, and the gap that causes trouble is between the third and the fourth. A policy saying access is reviewed quarterly is not a review; the completed review is. A well-written policy set with nothing behind it is a common and avoidable problem, because it is a written claim your own records contradict.
The 38 criteria, by series
The crosswalk behind this site maps each criterion to the policies that document it and to the evidence an auditor typically samples. Follow any criterion for its own page.
| Series | What it asks for | Criteria |
|---|---|---|
| CC1 Control environment | Who is accountable for security, and the expectations set for staff and contractors | CC1.1, CC1.2, CC1.3, CC1.4, CC1.5 |
| CC2 Communication and information | That people inside and outside the company are told what they need to know | CC2.1, CC2.2, CC2.3 |
| CC3 Risk assessment | Naming the risks to the service and deciding what to do about each one | CC3.1, CC3.2, CC3.3, CC3.4 |
| CC4 Monitoring activities | Checking that the controls are still working, routinely and periodically | CC4.1, CC4.2 |
| CC5 Control activities | Choosing and operating the controls that address the risks | CC5.1, CC5.2, CC5.3 |
| CC6 Logical and physical access controls | Identity, authorization, encryption, network boundaries and physical access | CC6.1, CC6.2, CC6.3, CC6.4, CC6.5, CC6.6, CC6.7, CC6.8 |
| CC7 System operations | Running the system day to day: detection, alerting and incident handling | CC7.1, CC7.2, CC7.3, CC7.4, CC7.5 |
| CC8 Change management | Authorizing, reviewing and tracking changes to software and infrastructure | CC8.1 |
| CC9 Risk mitigation | Reducing risk from disruptions and from vendors that touch your data | CC9.1, CC9.2 |
| A1 Availability | Capacity, backups and recovery, if you commit to availability | A1.1, A1.2, A1.3 |
| C1 Confidentiality | Identifying confidential data and protecting it for as long as you hold it | C1.1, C1.2 |
CC6 is the largest series by some distance, which is why access control, authentication and encryption take the most preparation time at a small company. CC8 is a single criterion, and for most engineering teams it is already satisfied by the pull request workflow they use every day.
Example controls for a small SaaS company
These sixteen are the ones that come up in almost every first examination. Treat them as a starting point to edit, not a list to adopt: if you do not operate a control, deleting it is the honest move.
| Control | Criterion | Policy that documents it | Evidence the auditor samples |
|---|---|---|---|
| MFA is enforced for every account on the identity provider, with no exemptions | CC6.1 | P04 Authentication and Password | Admin console screenshot of the enforcement rule, plus the list of any exempted accounts |
| Access to production is granted only after the manager approves a request | CC6.2 | P03 Access Control | Onboarding tickets showing approval before the account was created |
| Leavers lose all access on their last day | CC6.2 | P18 Human Resources Security | Offboarding checklist and the identity provider deactivation timestamp for each leaver |
| Production and identity-admin access is reviewed every quarter and removals are recorded | CC6.3 | P03 Access Control | Reviewer attestation per review, with the list of accounts removed and the date |
| Every change to production code is reviewed by someone other than the author before merge | CC8.1 | P09 Change Management | Branch protection settings, plus a sample of merged pull requests with reviewer approval |
| Dependencies and infrastructure are scanned for vulnerabilities and fixed within a stated SLA | CC7.1 | P11 Vulnerability and Patch Management | Scanner reports for the period and a remediation tracker showing time to fix against the SLA |
| Security-relevant events are logged and alerts reach a person who is expected to act | CC7.2 | P12 Logging and Monitoring | Alert rule export and a sample alert with the timestamp and the response that followed |
| Incidents follow a written procedure with a named contact and a post-incident review | CC7.4 | P13 Incident Response | Incident tickets with timeline and review notes, or a tabletop exercise record if there were none |
| Production data is backed up on a schedule, encrypted, and restores are tested | A1.2 | P15 Backup and Recovery | Backup configuration showing schedule and retention, plus a restore test record with the outcome |
| Data is encrypted in transit with TLS 1.2 or higher and at rest by the cloud provider | CC6.7 | P08 Encryption and Key Management | TLS scan result for public endpoints and the storage encryption setting for production |
| Vendors with access to customer data are assessed before onboarding and reviewed annually | CC9.2 | P16 Vendor and Third-Party Risk | Vendor inventory with data access level, and the report or questionnaire collected for each critical vendor |
| A risk assessment is completed at least annually and drives what gets fixed | CC3.1 | P17 Risk Assessment and Management | Risk register with scores, owners and treatment dates, and the scope statement it was run against |
| Everyone completes security awareness training when they join and annually after that | CC2.2 | P18 Human Resources Security | Training completion records covering every active employee and contractor |
| Laptops have full-disk encryption and screen lock enforced | CC6.7 | P19 Endpoint and Workstation Security | Device inventory with encryption status, from the MDM console or a documented manual check |
| Confidential data is classified and handled according to written rules | C1.1 | P06 Data Classification and Handling | Classification matrix with handling rules, and a data inventory showing where each class is stored |
| Every policy is approved by management, acknowledged by staff, and reviewed on a stated cadence | CC1.1 | P01 Information Security | Approval and revision history per policy, plus signed acknowledgment forms for everyone active |
Writing your own control list
The order that wastes the least time is roughly this. Write down what you already do, in one line per control, naming the tool and the frequency. Map each line to the criteria it speaks to, which is what the policy set and the per-criterion pages are for. Then look for criteria with nothing against them: those are your real gaps, and they are usually in CC3 risk assessment, CC4 monitoring and CC9 vendor review rather than in the technical series.
For each gap, decide whether to build the control or to accept the risk and say so. A documented decision not to do something is a valid answer for a criterion that does not apply to your service; an undocumented gap is not. Finally, give every control an owner and a cadence, because the auditor will ask who runs it and how often.
Two details catch people out. A control has to exist before the observation period starts, not be invented during fieldwork, so the sequencing matters more than the wording. And a control that runs quarterly needs to have run in the period being reported on, which is the difference between a Type I and a Type II examination; see Type I vs Type II for what changes.
Where the policies fit
Controls are what you do; policies are where you write down what you do. An auditor asks for the policy to establish that the control was designed and authorized, then asks for evidence to establish that it operated. The 22 policies on this site cover the areas in the table above, and each one names an owner, a cadence and the tools it applies to, which is what turns a template into something you can be tested against. See what auditors ask about policies for the questions that come up in a walkthrough, and SOC 2 policies for startups for the order to adopt them in.
Frequently asked questions
- Is there an official list of SOC 2 controls?
- No. The AICPA publishes the Trust Services Criteria, which describe what has to be achieved. Each company writes its own controls to meet them, so two companies with very different control lists can both be reported on against the same criteria.
- How many SOC 2 controls do I need?
- There is no required number. What matters is that every criterion in the categories you are reporting on is addressed by a control that actually operates, and that you can evidence it. Counting controls is not a useful goal on its own: one clearly written control that runs every quarter is worth more than five that only exist on paper.
- What is the difference between a criterion and a control?
- A criterion is the requirement, for example CC6.2 on granting and removing access. A control is the specific thing you do about it, for example 'access to production is granted only after the manager approves a request in the ticket system'. Criteria come from the AICPA; controls come from you.
- Do the policies count as controls?
- A policy documents a control; it is not the control itself. The auditor tests whether the described control operated during the period, using evidence such as tickets, review records and configuration exports. A policy with no operating control behind it is a finding.
- Which criteria apply to me?
- The common criteria, CC1 through CC9, are in every SOC 2 report. Availability (A1), Confidentiality (C1) and the other optional categories only apply if you choose to include them in the scope, usually because a customer asked for them.
Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.