Is there an official SOC 2 controls list? What to map instead
There is no mandated SOC 2 controls list. The framework is principles-based: the AICPA defines the Trust Services Criteria, and you design the controls that meet them. Here's what teams actually implement and how those controls map back to the criteria.
Why there's no fixed list
Teams searching for 'the SOC 2 controls list' are looking for something that doesn't exist by design. The AICPA publishes the Trust Services Criteria — outcome-oriented statements of what your controls must achieve — but it deliberately does not prescribe the specific controls you must implement. The criteria documents are explicit that the service organization identifies and implements the controls that meet the criteria; the framework provides the destination, not the route. This principles-based approach exists because SOC 2 applies to wildly different organizations, from a two-person API startup to a global payment processor, and a single mandated control set would be either too rigid for some or too lax for others. The tradeoff is flexibility in exchange for the burden of defining and justifying your own control set.
Points of focus are guidance, not requirements
Each criterion in the Trust Services Criteria is accompanied by 'points of focus' — illustrative considerations that management and auditors can use when designing and evaluating controls. It's easy to mistake these for a checklist, but they are explicitly not mandatory requirements, and not every point of focus is relevant to every organization. The AICPA refreshed the points of focus and related implementation guidance in 2022 to reflect evolving technology and cybersecurity risks, and continues to update accompanying guidance and the SOC 2 description criteria, but the underlying 2017 criteria themselves remained stable. Treat points of focus as a brainstorming aid for control design and for explaining your rationale to the auditor — not as a list to tick off. Your auditor evaluates whether your chosen controls meet the criteria, not whether you implemented every point of focus.
How the criteria are structured
The mandatory Security category is built on the Common Criteria, a set of nine CC series (CC1 through CC9) derived from the COSO internal control framework, covering the control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. If you add optional categories — availability, processing integrity, confidentiality, or privacy — each brings its own incremental criteria on top of the common set. Every control you write should trace to one or more of these criteria, and a single control often satisfies several. Understanding this structure is what lets you build a control set that is comprehensive without being bloated, because you can see exactly which criteria each control is there to address.
Control domains teams typically implement
Although the specific controls are yours to define, mature SOC 2 programs converge on a recognizable set of domains. These usually include logical access management (provisioning, deprovisioning, MFA, least privilege), change management (code review, testing, and approval before deployment), system monitoring and logging, incident response with documented detection and escalation, vulnerability management, vendor and third-party risk oversight, a formal risk-assessment process, HR and onboarding controls including background checks and security training, and data handling such as encryption in transit and at rest. Availability scope adds backup, disaster recovery, and capacity controls; confidentiality adds data classification and retention. The point isn't to copy this list verbatim but to map your real practices into domains like these and confirm each maps cleanly to the criteria you're claiming.
How platforms provide starter control libraries
This is precisely the gap compliance-automation platforms fill: rather than leave you staring at the bare criteria, tools like Vanta, Drata, Secureframe, and Sprinto ship pre-built control libraries already mapped to the Trust Services Criteria, then connect to your cloud, identity provider, and code repositories to gather evidence automatically. That mapping is genuinely useful as a starting point and a structure for evidence collection, and it can dramatically shorten the path to audit readiness. But the starter library is a template, not a guarantee — controls that don't reflect how your organization actually operates will fail in fieldwork, and your auditor still forms an independent opinion on whether your real controls meet the criteria. Use the library to accelerate, then prune and customize it to match what you genuinely do, because an accurate control set you can evidence beats a comprehensive one you can't.