The Complete SOC 2 Controls List: A Founder's Guide (2026)

Somewhere in the first enterprise deal that stalls on a security questionnaire, most founders discover that "SOC 2" is not one document — it's a list of controls, and nobody hands you that list upfront. You find out about it control by control, usually while your sales lead is refreshing their inbox waiting for legal sign-off.

This guide lays out what's actually in that list, why AICPA structures it the way it does, and what changes once you move from a Type 1 report to a Type 2 audit report that actually gets you through procurement.

Where the SOC 2 Controls List Actually Comes From

SOC 2 isn't a government regulation. It's a framework created by the American Institute of Certified Public Accountants — AICPA SOC 2 —, and it's built around five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

Security is the only mandatory category. The other four are optional, and most SaaS companies only add Availability and Confidentiality because those are the two criteria enterprise buyers ask about most. Adding Privacy usually only makes sense if you're handling regulated personal data at scale — health records, financial identifiers, that kind of thing.

Within Security, AICPA organises controls into nine categories, labelled CC1 through CC9. This is the actual "controls list" people mean when they ask for one:

• CC1 – Control Environment: Does your company have a real governance structure? Board oversight, an org chart that reflects actual authority, a code of conduct people have read

• CC2 – Communication and Information: Do employees know the security policies exist, and can they find them?

• CC3 – Risk Assessment: Have you actually identified what could go wrong, or is this a template you filled in once?

• CC4 – Monitoring Activities: Are you watching your own controls, or assuming they still work because they did last year?

• CC5 – Control Activities: The technical and procedural controls themselves — access reviews, change management, segregation of duties

• CC6 – Logical and Physical Access Controls: Who can get into your systems, how, and how you revoke that access when someone leaves

• CC7 – System Operations: Incident detection and response — do you have a process, or a Slack channel that everyone forgets exists

• CC8 – Change Management: How code and infrastructure changes get reviewed and approved before they hit production

• CC9 – Risk Mitigation: How you handle vendor risk and business continuity planning

Most founders assume this is a checklist you complete once. It isn't. Every one of these nine categories gets tested against evidence — not intentions.

What "Evidence" Actually Means in This Context

This is where a lot of first-time SOC 2 candidates get tripped up. A policy document that says "we review access quarterly" is not evidence. A ticket, a log, or a signed-off spreadsheet showing that the Q2 access review actually happened, on time, with names attached — that's evidence.

Auditors sample. They don't read every log from every week of your audit period. They pick specific dates and specific employees and ask you to produce the paper trail for that exact moment. If your controls only exist on the days you remember to run them, a Type 2 audit will find the gap.

The Difference Between Type 1 and Type 2 — And Why It Changes Everything

A SOC 2 Type 1 report answers one question: were your controls designed properly on a single date? It's a snapshot. You can pass a Type 1 with policies that look great on paper and have never actually been enforced.

A SOC 2 Type 2 report answers a harder question: did those controls actually operate consistently over a review period — usually somewhere between three and twelve months? This is the report enterprise buyers actually want, because it's much harder to fake. A company can write a beautiful access control policy and never once run the quarterly review it promises. Type 2 catches exactly that.

If you're choosing between the two for your first audit, know that most serious enterprise buyers will eventually ask for Type 2 anyway — starting with Type 1 mainly buys you time to fix gaps before the harder review begins.

What a SOC 2 Auditor Actually Does During the Engagement

A common misconception is that your SOC 2 auditor is a consultant who helps you build your controls. They aren't — and if they are, that's a conflict of interest most reputable firms won't touch. The auditor's job is independent verification. They review your control design, request evidence, sample transactions and events across your audit period, and then issue an opinion — unqualified (clean), or qualified (something didn't hold up).

Choosing the right SOC 2 auditor matters more than most founders expect going in. A firm with genuine SaaS and cloud infrastructure experience will ask sharper, more relevant questions than a generalist auditor — and that translates into fewer surprises mid-engagement and a report that enterprise security teams recognise as credible rather than generic.

Building Your Own Controls List Before the Audit Starts

Before you ever talk to an auditor, it helps to map your actual environment against the nine CC categories above and be honest about where the gaps are. A few places founders consistently underestimate:

Access management is usually the biggest gap. Startups tend to over-provision access early — everyone has admin rights because it was faster at the time — and then never revisit it. CC6 will ask you to prove access is reviewed regularly and revoked promptly when someone leaves. If your last access review was "whenever we remembered," that's a finding waiting to happen.

Vendor risk under CC9 catches companies that never formally evaluated their own sub-processors — the cloud provider, the analytics tool, the customer support platform. You don't need to audit every vendor yourself, but you do need a documented process for assessing them before they touch your data.

Incident response under CC7 is often the newest muscle a company has to build. Most startups have never had a real incident, which means they've also never tested whether their response plan actually works. Auditors will ask for evidence of at least a tabletop exercise, not just a document nobody's opened.

What the Final SOC 2 Audit Report Actually Contains

The finished report isn't a certificate — there's no SOC 2 "seal" you slap on your website (in fact, AICPA explicitly prohibits using their logo that way). What you get is a detailed report with several sections: management's assertion, the auditor's opinion, a description of your system, the actual controls tested, and — critically — any exceptions noted against those controls.

Buyers who actually know what they're reading skip straight to the exceptions section. A clean report with zero exceptions is rare and, honestly, sometimes viewed with mild suspicion by experienced reviewers — a small, well-explained exception with a documented remediation plan often reads as more credible than a suspiciously perfect report.

How This Connects to Broader Compliance Work

If your company is also working toward ISO 27001, you'll notice real overlap in control intent, even though the frameworks are structured differently — access management, risk assessment, and incident response show up in both. Mapping controls once and reusing evidence across frameworks saves real audit prep time instead of duplicating work for every certification you pursue.

Companies managing both SOC 1 and SOC 2 obligations run into a similar overlap — SOC 1 focuses on controls relevant to financial reporting, while SOC 2 covers broader operational security, but a lot of the underlying evidence-gathering discipline is shared between the two.

A Realistic Timeline for Founders Planning This Out

Readiness work — closing the gaps this guide describes — typically takes one to three months depending on how mature your existing practices are. The Type 2 observation period itself runs three to twelve months on top of that. Add four to eight weeks for the audit and report drafting after the observation period closes. Founders who start this process only after a customer demands it are usually looking at a five-to-eight-month wait before they have anything to hand over — which is exactly the gap that stalls deals.

The Real Takeaway

A SOC 2 controls list isn't a form to fill out once a year. It's closer to an operating discipline — access reviews that actually happen on schedule, incident response plans that get tested rather than filed away, vendor decisions that get documented instead of made on a Slack thread. Founders who treat it that way from the start find the audit itself almost anticlimactic. The ones who treat it as a last-minute compliance sprint are the ones who end up with exceptions on their report — and a slower path through their next enterprise deal.