Here's where teams get stuck: they confuse "criteria" (what the AICPA requires you to meet) with "controls" (how your specific organization meets it). That mix-up creates audit-readiness gaps, and it's a leading cause of failed control tests during a SOC 2 examination.
This guide breaks down the SOC 2 controls list by Trust Services Category, walks through the CC1-CC9 common criteria backbone, and covers practical guidance on scoping your controls and dodging the mistakes that trip up first-time audit candidates.
TL;DR
- SOC 2 controls are your own safeguards, not a universal AICPA checklist
- Security (CC1-CC9) is mandatory; the other four Trust Services Criteria apply only when relevant
- Total control count depends on scope and complexity, not a fixed number
- Access reviews, vendor management, and incident response testing cause most audit exceptions
- A controls matrix with owners, evidence, and testing cadence beats chasing scattered points of focus
What Are SOC 2 Controls?
SOC 2 controls are the specific policies, procedures, and technical safeguards your organization implements and tests to meet the AICPA's Trust Services Criteria. There's no government-style checklist here. Two companies can pass the same SOC 2 audit with entirely different sets of controls, as long as each set satisfies the required criteria.
Auditors work with three distinct terms, and mixing them up is where most confusion starts:
- Criteria – the formal requirement itself. CC6, for example, covers logical and physical access controls.
- Controls – your company's actual implementation. For CC6, that might mean multi-factor authentication and quarterly access reviews.
- Points of focus – AICPA guidance describing characteristics that can help you design and evaluate a control.
The AICPA's Trust Services Criteria framework makes clear that points of focus are not a mandatory one-to-one mapping. You don't need a separate control for every single point of focus listed under a criterion.
Why This Distinction Matters in 2026
Organizations juggling SOC 2 alongside CMMC 2.0, NIST 800-171, or ISO 27001 are drowning in duplicated evidence work. The same access control might need to satisfy CC6 under SOC 2 and AC-family requirements under NIST 800-171.
Building one control library mapped across frameworks, instead of maintaining separate evidence trails for each, saves compliance teams from re-proving the same control four different ways.
The SOC 2 Controls List by Trust Services Category
Every SOC 2 report is anchored on Security, the mandatory baseline. The other four categories get layered on based on what your customers actually expect to see documented in your report.
Security Controls (The Common Criteria)
Security is the mandatory foundation protecting your systems and data against unauthorized access, built on the CC1-CC9 series covered in detail below.
Representative controls include:
- Multi-factor authentication (MFA)
- Access provisioning and deprovisioning procedures
- Firewall configuration and endpoint monitoring
- Security awareness training
- Background checks for sensitive roles
Availability Controls
Availability controls confirm your systems stay accessible and recoverable in line with what you've committed to customers. This category fits SaaS and cloud providers with formal uptime or SLA commitments especially well.
Common examples:
- Backup and disaster recovery procedures
- Business continuity plans
- Capacity planning processes
- Environmental risk assessments
Confidentiality Controls
Confidentiality controls protect non-personal sensitive information, things like intellectual property, contracts, and business data, that still needs to move securely between trusted parties.
Typical controls include:
- Data classification policy
- Encryption at rest and in transit
- Data retention schedules
- Secure disposal processes
Processing Integrity Controls
This category verifies your systems process data completely, accurately, and on time, making it best suited for organizations running transactions, calculations, or data processing on behalf of customers.
Key examples include:
- Input and output validation checks
- Reconciliation processes for transactions and calculations
- Automated error detection with real-time alerting
- Data processing accuracy reviews
Privacy Controls
Privacy controls govern how personal information (PII or PHI) gets collected, used, retained, and disposed of.
These controls typically include:
- Consent management processes
- Data minimization practices
- Breach notification procedures
- Data subject access request handling
This category overlaps heavily with HIPAA, GDPR, and CCPA obligations. Most organizations add it only when they're handling protected health information or personally identifiable data directly.
The Common Criteria (CC1–CC9): The Backbone of Every SOC 2 Report
Regardless of which optional Trust Services Categories you scope in, every SOC 2 report rests on nine Common Criteria series. Each represents a topic area containing multiple criteria and points of focus, not a single control to check off.
| Series | Focus Area |
|---|---|
| CC1 | Control Environment |
| CC2 | Communication and Information |
| CC3 | Risk Assessment |
| CC4 | Monitoring Activities |
| CC5 | Control Activities |
| CC6 | Logical and Physical Access |
| CC7 | System Operations |
| CC8 | Change Management |
| CC9 | Risk Mitigation |
Each series represents a layer of control maturity. Auditors form their opinion by testing controls mapped against each of these nine areas, not by counting boxes checked.
Rather than trying to satisfy every point of focus individually, most successful programs build a controls matrix that links each CC series to:
- An owner – the person accountable for that control's operation
- An evidence source – where the proof lives (ticketing system, IdP logs, HR platform)
- A testing cadence – how often the control gets reviewed or re-tested
This matrix approach turns nine abstract categories into something an audit team can actually execute against.
How Many Controls Do You Actually Need in 2026?
There's no fixed number. SOC 2 is risk-based, meaning your control count depends entirely on which TSC categories you select, how complex your infrastructure is, and what your specific auditor expects to see tested.
Factors that actually drive the count:
- Number of Trust Services Categories in scope
- System and infrastructure complexity (single-tenant vs. multi-cloud, for example)
- Regulatory exposure beyond SOC 2 itself
- The granularity your CPA firm expects during testing
A lean startup with Security-only scope and a single cloud environment will land on a noticeably shorter controls list than a mid-size SaaS company running Security, Availability, and Confidentiality across multiple regions. Enterprises layering in Processing Integrity or Privacy, plus subservice organizations, push the count further still.
Defense Contractors Face a Multiplied Control Count
Defense contractors and DIB companies face a compounded version of this problem. Layering SOC 2 alongside CMMC 2.0 and NIST 800-171 means tracking overlapping control requirements across frameworks that don't share a common evidence format out of the box.
That's the exact gap QMS Learning's upcoming Defense Cybersecurity Readiness pathway is built to close. The pathway bundles CMMC & NIST 800-171, ISO 27001, and SOC 2 into one program, so teams aren't rebuilding evidence workflows across four overlapping frameworks.
It's currently running as a pilot cohort with a Q3 2026 launch, aimed at SaaS vendors and service providers in the defense supply chain who need both a clean SOC 2 report and CMMC readiness.
Common Mistakes to Avoid When Building Your SOC 2 Controls List
These three mistakes account for most of the gaps auditors flag during the assessment:
- Treating SOC 2 like a fixed checklist. SOC 2 is risk-based, not a form to copy. Borrowing another company's controls list without mapping it to your own infrastructure leaves gaps an auditor will find.
- Overlooking Complementary User Entity Controls (CUECs). These are customer-side controls your report assumes are working, such as restricting physical access to a server room (per Wolf & Co). Skipping this review creates false assurance.
- Underestimating judgment-based control evidence. Access reviews, vendor assessments, and incident response tests resist automation and drive the most audit exceptions. CertPro's review cites late access reviews, orphaned terminated-employee accounts, and untested incident response plans as the top patterns.
Frequently Asked Questions
What is SOC 2 in simple terms?
SOC 2 is a voluntary attestation showing your organization has implemented controls to protect customer data, evaluated against the AICPA's Trust Services Criteria. An independent CPA firm performs the audit and issues the report.
What are the 5 principles of SOC 2?
The five Trust Services Categories are Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only one that's mandatory for every SOC 2 report.
How many controls are in SOC 2 in 2026?
There's no fixed number, only criteria you must satisfy. Your actual control count depends on which TSC categories you select, your infrastructure complexity, and your auditor's expectations. Counts vary widely between a lean startup and a multi-region enterprise.
What's the difference between SOC 2 controls, criteria, and points of focus?
Criteria are the formal AICPA requirements. Controls are your company's specific implementation of those requirements. Points of focus are AICPA guidance describing helpful characteristics for designing a control, not separate mandatory requirements.
Do all five Trust Services Categories need controls?
No. Only Security is mandatory. The other four, Availability, Confidentiality, Processing Integrity, and Privacy, get scoped in based on your service commitments and what your customers expect to see.
What evidence do auditors expect for SOC 2 controls?
Auditors typically request five evidence families: access records (provisioning, reviews), change management logs, risk and vendor assessments, resilience documentation (backups, DR tests), and people evidence (training records, background checks).
