SOC 2 Control List: Common Criteria and Categories

There is no single official SOC 2 control list that every company copies. SOC 2 is a report on controls at a service organization that are relevant to security, availability, processing integrity, confidentiality, or privacy, and the controls you actually run are the ones you design to meet the AICPA criteria for your own system. What is fixed is the structure: five categories, nine Common Criteria groups (CC1 to CC9), and a set of criteria under each. In this guide we walk through that structure, give you a working list of the controls auditors typically expect to see under each group, and show you how to tailor it to your own environment.

TL;DR

• SOC 2 has five Trust Services Categories: security, availability, processing integrity, confidentiality and privacy. Security is mandatory and is evaluated through the Common Criteria, CC1 to CC9.
• Criteria are fixed by the AICPA, but controls are yours. Each organization's system, risks and commitments are unique, so no universal control set exists.
• A usable control has an owner, a cadence, and evidence that proves it operated. A Type 2 audit tests that over a period of time.
• Start with scope, map your data flows, find gaps and plan remediation before the audit begins.

Table of Contents

• What SOC 2 controls are and how they relate to criteria
• The five Trust Services Categories
• SOC 2 control list by Common Criteria (CC1 to CC9)
• Controls for the optional categories
• An example control, from policy to evidence
• Type 1 and Type 2: how the control list is tested
• How to tailor the list to your company
• Our perspective: the control list is also a sales asset
• Turning your controls into faster questionnaire answers
• FAQ
• Sources

What SOC 2 controls are and how they relate to criteria

Three terms get mixed up constantly, so it helps to separate them.

• Criteria are the AICPA's Trust Services Criteria. They state what a well-controlled system should achieve. The 2017 Trust Services Criteria, with points of focus revised in 2022, are the current reference for evaluating controls over information and systems.
• Points of focus are the AICPA's guidance on what to consider under each criterion. They are helpful prompts, not a checklist you must satisfy line by line.
• Controls are the specific policies, procedures and technical settings that your company operates to meet each criterion. They are written by you and tested by your auditor.

A simple chain shows how they fit: a criterion asks that access to systems is restricted to authorized users, your control says that production access requires single sign-on with multi-factor authentication, and your evidence is the identity provider configuration plus a sample of access records. The auditor tests the control and evidence, then reports on whether the criterion was met.

The five Trust Services Categories

The five categories are security, availability, processing integrity, confidentiality and privacy. Security is always in scope and is evaluated with the Common Criteria. The other four are optional. You choose them according to your service commitments, system requirements and risks.

How do you decide? Read your customer contracts and your security questionnaires. If customers hold you to an uptime commitment, add availability. If you promise to keep customer business data restricted, add confidentiality. If you process transactions or calculations on behalf of customers, consider processing integrity. If you collect personal information directly, consider privacy.

SOC 2 control list by Common Criteria (CC1 to CC9)

The Common Criteria are organized into nine groups: CC1 control environment, CC2 information and communication, CC3 risk assessment, CC4 monitoring activities, CC5 control activities, CC6 logical and physical access, CC7 system operations, CC8 change management and CC9 risk mitigation. CC1 to CC5 are the primary classifications, and CC6 to CC9 are subclasses of control activities.

Below, for each group, we list controls that companies commonly implement. Treat them as a starting point and a vocabulary, not as a requirement set.

CC1: Control environment

This group is about tone at the top and accountability.

• A written code of conduct that employees acknowledge at hire and annually
• Defined security roles and responsibilities, with leadership oversight of security and compliance
• Background checks for new hires, as permitted by law
• Documented job descriptions and a process for evaluating performance
• Security awareness training completed at onboarding and on a recurring schedule

CC2: Information and communication

This group covers how you produce, use and share information about your controls.

• Published information security policies, reviewed at least annually
• A channel for employees to report incidents and concerns
• A customer-facing description of your system, commitments and responsibilities
• A way to communicate changes and incidents to affected customers

CC3: Risk assessment

• A documented risk assessment performed at least annually
• A risk register with owners, ratings and treatment decisions
• Consideration of fraud risk and of changes in the business or technology that affect risk
• Vendor risk assessments for critical third parties

CC4: Monitoring activities

• Ongoing monitoring of control performance, such as automated compliance checks
• Periodic internal reviews or internal audits
• Tracking and remediation of control deficiencies, with findings communicated to management
• Vulnerability scanning and penetration testing on a defined schedule

CC5: Control activities

• Controls mapped to risks and to criteria
• Technology general controls over infrastructure, security and change
• Policies and procedures that define who does what, and when

CC6: Logical and physical access

This is usually the heaviest group in a real audit, and the one auditors sample most.

• Centralized authentication through single sign-on with multi-factor authentication
• Documented approval before access is granted, and role-based access based on least privilege
• Timely removal of access when someone leaves or changes roles
• Periodic access reviews of users, privileged accounts and service accounts
• Encryption of data at rest and in transit
• Network segmentation, firewalls and restrictions on inbound traffic
• Physical access controls for offices and data centers, or reliance on a cloud provider's controls
• Secure disposal of media and data
• Endpoint protection and device management for laptops and mobile devices

CC7: System operations

• Logging and monitoring with alerts for anomalies
• A vulnerability management process with remediation timelines by severity
• A documented incident response plan, tested through tabletop exercises
• Incident tickets that record detection, response, root cause and lessons learned

CC8: Change management

• Changes are requested, reviewed, tested and approved before release
• Code review through pull requests, with branch protection
• Separation between development, test and production environments
• An emergency change procedure with after-the-fact review

CC9: Risk mitigation

• Business continuity and disaster recovery planning
• Cyber insurance or other risk transfer where appropriate
• Vendor management: due diligence before onboarding, contracts with security terms, and periodic review of vendor assurance reports

Controls for the optional categories

The four optional categories add criteria on top of the Common Criteria. Typical controls look like this.

Availability

• Capacity monitoring and alerting
• Backups with periodic restore tests
• A disaster recovery plan tested at least annually
• Redundancy across zones or regions

Processing integrity

• Input validation and error handling
• Reconciliation of processed data against source data
• Monitoring of job completion and failures
• Defined processing specifications that match customer commitments

Confidentiality

• A data classification policy that identifies confidential information
• Retention schedules and secure deletion at contract end
• Non-disclosure agreements with employees and vendors
• Restricted access to confidential data, with logging

Privacy

• A published privacy notice that matches actual practice
• Consent and choice mechanisms where required
• Processes for access, correction and deletion requests
• Limits on collection, use and retention of personal information
• Breach notification procedures

For the exact wording of each criterion, use the AICPA's Trust Services Criteria document. Your auditor will map your controls to it.

An example control, from policy to evidence

Abstract lists only help so much, so here is one control written the way an auditor would want to see it. This is an illustration, not a template your auditor has approved.

Notice what makes it testable: a named owner, a fixed frequency, and artifacts that exist at the moment the control runs. A control that says "access is reviewed regularly" fails because there is nothing to sample.

Evidence collection is where teams lose the most time. Tools can help: for example, AWS Audit Manager's SOC 2 framework collects relevant evidence for an assessment and, with Evidence Finder enabled, lets you search for specific evidence and export it as CSV. Whatever tooling you use, capture evidence as the control operates rather than reconstructing it in the final weeks.

Type 1 and Type 2: how the control list is tested

The same control list is tested differently depending on report type. A Type 1 report looks at whether controls are suitably designed at a point in time. A Type 2 report also tests whether they operated effectively over a period, which is why recurring controls like quarterly access reviews need several instances of evidence. If you are deciding between them, our guide to SOC 2 Type 1 vs Type 2 differences lays out the trade-offs, and the complete guide to SOC Type II reports covers what to expect during the observation window.

How to tailor the list to your company

Copying a generic list is the most common mistake we see. Guidance reproduced by PwC states that management should identify risks to its service commitments and system requirements, and the controls needed to address them. That means a ten-person startup on a single cloud provider and a fintech with its own data centers will have different lists, even for the same report.

A practical sequence, in line with Deloitte's SOC readiness guidance, which recommends defining scope, mapping data flows and control processes, identifying gaps and planning remediation before attestation:

1. Define scope. List the products, infrastructure, people, data and vendors that make up the system in the report.
2. Choose categories. Start with security, then add others based on contracts and customer demands.
3. Map what you already do. Most teams already run many controls informally. Write them down against CC1 to CC9.
4. Identify gaps. Mark criteria with no control, or controls with no evidence.
5. Remediate. Assign owners, set cadences and build the evidence trail.
6. Complete readiness work. The same Deloitte guide also points to documenting controls, identifying complementary user entity controls and drafting the system description before the audit.
7. Engage your auditor early. Confirm control wording and sampling expectations before the observation period begins.

For a longer walkthrough, see our 7-step SOC 2 compliance checklist, and for how auditors approach the engagement, SOC 2 auditors and SaaS compliance.

Our perspective: the control list is also a sales asset

We talk with security, GRC and sales teams every week, and a pattern repeats. The audit is a project with an end date, but the questions that follow it never stop. A prospect receives your SOC 2 report, then sends a questionnaire asking about the same controls in different words: how you manage access, how you handle change, how you respond to incidents.

That is why we encourage teams to write their control descriptions once, in clear and consistent language, and treat them as source material for every later answer. If your access review control is described precisely in your policy, your report and your knowledge base, a question on the topic takes seconds to answer rather than an afternoon of searching. If those three descriptions disagree, you create risk for yourself and friction for the buyer.

Two habits make the biggest difference in our experience. First, keep one owner per control and one source of truth for the wording. Second, version your documents, so that when a policy changes you can show what was true during each period. This is the same discipline our platform is built around: a knowledge base with document versioning and AI retrieval that shows a confidence score, so reviewers can see which answers are well supported and which need a human check.

The SOC 2 control list tells auditors what you do. Your questionnaire answers tell customers the same thing, faster. Keeping the two aligned is what turns compliance work into shorter sales cycles.

— Gaspard

Turning your controls into faster questionnaire answers

Once your controls are documented, the next bottleneck is usually repeating them across customer security reviews. Our Questionnaire Automation Tool parses questionnaires in any format, drafts answers from your approved content, and flags low-confidence responses for review. Your teammates collaborate in real time, and a customizable Trust Center lets buyers see your security posture before they ask. Our Smart Security Knowledge Base is where your control descriptions can live and stay current.

If you are also comparing report types, our explainers on SOC 1 vs SOC 2 and on SOC 2 requirements for SaaS are good next reads.

FAQ

How many controls does SOC 2 have?

There is no fixed number. The AICPA defines criteria, and each organization designs the controls that meet them for its own system and risks. Companies often end up with somewhere in the range of dozens to a couple of hundred controls, depending on scope and the categories selected. Your auditor confirms what applies to you.

What are the SOC 2 Common Criteria?

They are the security criteria grouped as CC1 to CC9: control environment, information and communication, risk assessment, monitoring activities, control activities, logical and physical access, system operations, change management and risk mitigation. Every SOC 2 report includes them, because security is the one mandatory category.

Do I need all five Trust Services Categories?

No. Security is required, while availability, processing integrity, confidentiality and privacy are chosen based on your commitments and risks. Adding categories widens the audit, so pick the ones your customers actually rely on you for.

What is a SOC 2 compliance checklist?

It is a working plan rather than an official form. Define scope, choose categories, map existing controls to the criteria, find gaps, remediate, and prepare evidence before the audit. Our SOC 2 compliance checklist breaks this into seven steps.

Sources

• SOC 2 - SOC for Service Organizations: Trust Services Criteria (AICPA)
• 2017 Trust Services Criteria, with revised points of focus 2022 (AICPA)
• Common Criteria (PwC Viewpoint)
• A practical guide to SOC readiness (Deloitte)
• SSAE-18 SOC 2 (AWS Audit Manager)

Recommended

• SOC 2 Trust Principles: The Five Criteria Explained
• SOC 2 Compliance Requirements: Your 2026 Guide
• 7 Steps to Create a Complete SOC 2 Compliance Checklist
• SOC 2 compliance guide for tech and finance in 2026