There Is No Official SOC 2 Controls List. Here Is What Auditors Actually Test.

Type "SOC 2 controls list" into a search bar and you will find PDFs, spreadsheets, and gated ebooks promising the definitive answer. None of them are official. There is no single SOC 2 controls list published by the AICPA, because a SOC 2 audit does not test against a universal checklist. It tests against the controls you say you have, documented in your own system description, and nothing else.

The "SOC 2 controls list" you're searching for does not exist

The confusion is understandable. Frameworks like PCI DSS hand you a numbered list of requirements. Check every box, pass the assessment. SOC 2 works differently, and that difference is the whole point of the framework.

SOC 2 is governed by the AICPA's Trust Services Criteria, a set of control objectives, not control instructions. The criteria describe outcomes a well-run company should be able to demonstrate (access is restricted to authorized users, changes get reviewed before they ship, incidents get logged and resolved). They do not tell you which tool to buy, which policy template to use, or how many approval steps a deploy needs. That part is yours to design.

This is why two companies can both pass a SOC 2 audit with genuinely different control sets. A five-person startup running everything on AWS with SSO and a change-management workflow in GitHub can satisfy the same criteria as a 200-person company with a dedicated security team and a homegrown ticketing system. Different controls, same criteria, both clean opinions.

What auditors actually test instead

An auditor's starting point isn't a master list. It's your system description, the document where you state, in writing, what you actually do to secure your environment. The audit then checks whether reality matches that document.

Here's the proof case that makes this concrete. Say your system description states that all production passwords require multi-factor authentication and a minimum length of twelve characters. The auditor doesn't compare that to some external password standard. They pull your identity provider's configuration, confirm MFA is enforced for every account with production access, and sample a handful of users to check the policy actually applies rather than sitting unenforced in a settings page nobody revisits.

Encryption works the same way. If your system description says customer data is encrypted at rest and in transit, the auditor asks for evidence. That might be the database configuration showing encryption enabled, the TLS certificate covering your application endpoints, or a screenshot of your cloud provider's encryption settings. The auditor doesn't care whether encryption exists somewhere in the industry. They care whether your stated control matches what you built.

Change management gets the same treatment. If your system description says production deploys require a reviewed and approved pull request, the auditor doesn't take your word for it. They pull a sample of merges from your observation period and check whether each one has an approving reviewer distinct from the author, timestamped before the merge rather than added afterward to backfill the record.

Get the system description wrong, either by overstating what you do or by describing a control you haven't actually implemented, and the audit finds the gap. This is also why copying a competitor's public security page word for word is a bad idea. You'd be attesting to controls that may not exist in your environment at all.

CyberSprint's audit packages bundle the compliance platform, the readiness work, and the independent CPA firm's engagement into one coordinated path, precisely so the system description gets written accurately the first time instead of rewritten mid-audit. The CPA firm that signs the final opinion still has to stay independent of whoever built your controls in the first place, why the audit firm can't also build your controls which is why readiness and audit stay two separate engagements even when one partner coordinates both.

How many controls does SOC 2 actually have?

There's no fixed count, which is a direct consequence of there being no fixed list. But the question deserves a real answer, not a shrug.

The AICPA organizes the required baseline, called the Common Criteria, into nine categories, CC1 through CC9. Each category is a control objective, and each one typically maps to somewhere between five and fifteen individual controls depending on how you implement it and how granular your auditor likes documentation. Add that up across a security-only scope and most startups land somewhere in the range of 60 to 100 individual controls.

Add optional criteria beyond Security, such as Availability or Confidentiality, and that number climbs, since each one carries its own controls and more evidence to collect. Security-only is still the normal starting scope for an early-stage SaaS company.

Vendors publish different totals for the same reason menus list different numbers of dishes depending on whether a side counts as its own item. A single objective like access provisioning might be one control in a lean startup's documentation and three separate controls (request, approval, periodic review) in a larger company's. Treat any specific number you see online, including the range above, as a typical estimate, not a spec sheet you need to hit exactly.

The nine Common Criteria categories, in plain English

These categories are the closest thing to a SOC 2 controls checklist that actually exists, because they're the fixed structure every audit is built on. What varies underneath each one is up to you.

• CC1, Control Environment. Does leadership actually care about security, or is there a policy binder nobody reads? Covers org structure, accountability, and whether people are trained on what's expected of them.
• CC2, Communication and Information. How security expectations, incidents, and policies get communicated internally and to customers.
• CC3, Risk Assessment. Whether you formally identify and evaluate risks to your systems, and how often.
• CC4, Monitoring Activities. Ongoing checks that controls are still working, not just designed to work on paper.
• CC5, Control Activities. The policies and procedures that put the other categories into practice day to day.
• CC6, Logical and Physical Access Controls. Who can get into your systems and your buildings, and how that access is granted, reviewed, and revoked. This is usually the category with the most individual controls, since it covers everything from password policy to offboarding.
• CC7, System Operations. Detecting and responding to security events, including your incident response process.
• CC8, Change Management. How code and infrastructure changes get reviewed and approved before they hit production.
• CC9, Risk Mitigation. Vendor risk management and business continuity planning.

Notice what's missing from that list. No specific tools, no specific policy language, no specific approval chains. Those live in your system description, one layer down.

For the full picture of SOC 2 scope, timeline, and cost, the SOC 2 compliance guide for SaaS startups covers it end to end.

The mistake that turns a controls list into an audit finding

Most first-time SOC 2 audits don't fail on missing controls. They generate findings because a control was written as an aspiration instead of a description of what actually happens. Here's a common example. An engineering handbook says all code changes require peer review, but branch protection isn't actually turned on for the repo that touches production. The policy exists. The enforcement doesn't. An auditor who samples ten merges and finds two that skipped review has a finding, even though the intent was real.

The fix isn't a longer policy. It's making the control self-enforcing wherever you can, so it doesn't depend on someone remembering to follow it. Branch protection rules instead of a reminder in the handbook. SSO group membership tied to a ticketing system instead of a manual spreadsheet. An offboarding step wired into HR software instead of a checklist a manager might skip. A control that only works when a human remembers it is a control that will eventually fail a sample.

Quarterly access reviews break the same way. It's easy to write "we review production access every quarter" into a policy and then actually do it twice in a year, once in March and once in November, because nobody put a recurring reminder on a calendar. An auditor sampling four quarters and finding two review dates has a real finding, not a technicality. A control that depends on someone's memory needs a trigger that doesn't, whether that's a recurring calendar hold with a required sign-off, or a report your identity provider generates automatically on a schedule.

Building your own SOC 2 controls checklist

Since nobody hands you a finished list, you have to build one that fits your company. In practice, this is where most of the actual work of getting audit-ready happens.

1. Map your environment. List every system that touches customer data or production infrastructure. You can't design a control for something you haven't accounted for.
2. Assign a control to each Common Criteria category. For CC6 that might mean SSO plus MFA plus a quarterly access review. For CC8 it might mean required pull request approval before merge to main.
3. Write the policy before you implement it. Auditors want to see intent documented before evidence collected. Doing it backward creates a paper trail that looks retrofitted.
4. Collect evidence as you go. Screenshots, config exports, and ticket logs dated across your observation period. Waiting until the week before fieldwork to gather everything is the single most common cause of a rushed, stressful audit.
5. Have someone who isn't you review the list. A second set of eyes, whether a fractional security lead or a formal readiness engagement, tends to catch the gaps between what you think you do and what you can actually prove.

A readiness assessment exists specifically to pressure-test this list before an independent auditor ever sees it. It's a separate line item from the audit itself, worth the cost even when you're confident in your own work.

Ready to see what your own controls list would look like?

Start a Conversation with CyberSprint and we'll walk through your environment together. We can sketch out what a realistic, audit-ready controls list looks like for a company your size. No generic template required.

Frequently asked questions

Is there a SOC 2 controls checklist PDF I can just download and use?

Plenty exist, and they're useful for orientation, but none is official, and using one as your actual system description is risky. Your auditor tests your stated controls against your real environment. A generic PDF describes someone else's environment. Use one as a starting reference, then rewrite it to match what you actually do.

How many controls does SOC 2 require at minimum?

There's no fixed minimum count. What's fixed is the nine Common Criteria categories every security-only SOC 2 report has to address. Most startups end up documenting somewhere around 60 to 100 individual controls to cover them, though the exact number depends on how granular your documentation is.

Who decides what counts as a valid control?

You propose the control, and your independent CPA auditor evaluates whether it satisfies the relevant Trust Services Criteria objective and whether the evidence supports that it operated as described. No external body pre-approves individual controls.

Can I reuse another company's SOC 2 controls list?

Only as a reference for ideas, never as your submitted documentation. Two companies with different tech stacks, team sizes, and processes will have genuinely different controls even when they satisfy the same criteria. Attesting to a control you haven't actually implemented is exactly what an audit is designed to catch.

Is SOC 2 the same thing as being "SOC 2 certified"?

No. SOC 2 is an attestation issued by an independent CPA firm, not a certification, so "SOC 2 certified" isn't accurate even though people say it casually. the difference between SOC 2 attestation and certification The controls list conversation is the same either way. What changes is the word you use to describe the report you get at the end.

There's a version of this that feels like busywork, chasing a list that doesn't exist. There's another version where building that list becomes the moment you actually understand your own security posture for the first time. That's usually the version that turns into a shorter sales cycle and an easier enterprise deal down the road.