SOC 2 Controls List: Criteria, Examples, and Best Practices

There is no official SOC 2 controls list. The AICPA publishes the Trust Services Criteria, and every company writes its own SOC 2 controls list to meet the criteria in scope for its report [1].

That flexibility means you start with a blank page, and the page keeps growing. AI tools, non-human identities like service accounts and API keys, and shadow SaaS all add systems, users, and vendors an auditor can ask about.

This guide gives you a starting point: the five Trust Services Criteria, a controls list for the common criteria (CC1 to CC9) with example controls and evidence, the same for the optional criteria, and seven best practices for running controls across teams.

What Is a SOC 2 Controls List?

A SOC 2 controls list is the set of policies, procedures, and technical safeguards your company runs to meet the Trust Services Criteria. The auditor evaluates each control and reports whether it was designed well and, for a Type 2 report, whether it operated effectively over time.

Three terms get mixed up:

• Criteria are the requirements the AICPA sets, such as CC6.2, which asks you to register and authorize new users before issuing credentials and granting access. You don't write these. You meet them.
• Points of focus describe what a good control under each criterion might address. They are guidance, not a checklist, but you should be able to explain why one doesn't apply.
• Controls are what your company actually does, in your own words. For example: "Access to production systems is requested in the ticketing system and approved by the system owner before it is granted."

One control can meet several criteria, and one criterion usually needs several controls. That's why two similar companies can end up with very different lists, and why a copied list rarely survives the first conversation with an auditor.

The Five Trust Services Criteria

Every SOC 2 report covers Security. The other four categories are optional, and you add them based on the commitments you make to customers.

Source: AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022) [1].

A simple rule for the optional categories: if you promise uptime, add Availability. If customers rely on your calculations or transactions, add Processing Integrity. If you hold customer data under contract terms, add Confidentiality. If you collect personal information directly from individuals, consider Privacy.

SOC 2 Common Criteria Controls List (CC1 to CC9)

Because Security is always in scope, the common criteria are the core of every SOC 2 controls list. Here is what each series covers, common example controls, and the evidence auditors typically ask for.

Source: criteria from AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022) [1]. Example controls and evidence are common practice, not AICPA requirements.

CC6 Logical and Physical Access Controls, Point by Point

CC6 has more individual criteria than any other common criteria series, and it's where SaaS and identity sprawl shows up first.

Many of these depend on knowing what apps you have. An app an employee signed up for with a work email holds company data and has users. If it isn't in your inventory (CC6.1), it isn't in your access review (CC6.3) or on your offboarding checklist (CC6.2). The same goes for AI tools connected through OAuth and for unowned service accounts. For more on the review side, see why access reviews matter for SOC 2 compliance.

Controls List for the Additional Criteria

The optional categories add these criteria on top of the common criteria, not in place of them.

SOC 2 Type 1 vs Type 2 Controls

There is no separate SOC 2 Type 2 controls list. Both report types cover the same controls. What changes is the question the auditor asks:

• Type 1: are the controls designed to meet the criteria at a single point in time?
• Type 2: are they designed well, and did they actually run, every time, across the review period?

For a Type 2, the auditor samples evidence from across the period: new hires, departures, production changes. A departed employee who kept access to one app, or a skipped access review, shows up as an exception. That's why evidence collection has to be a habit, not a project.

How to Build Your SOC 2 Controls List

1. Set the scope and system boundary. Decide which services, infrastructure, people, and data the report covers, which optional categories you're adding, and which vendors are carved out under their own SOC reports.
2. Read the points of focus. For each criterion in scope, note which points of focus apply. They're the best hint you'll get about what an auditor expects.
3. Write control statements. Each control needs an owner, a frequency, and the evidence it produces. "The IT manager reviews admin access to production on a set schedule and records it in the ticketing system" is testable. "We limit admin access" is not.
4. Keep a control matrix. Map every control to its criteria, owner, frequency, and evidence in a spreadsheet or GRC tool. It's what you hand the auditor and what your team works from all year.
5. Collect evidence continuously. Let systems record evidence as each control runs (tickets, logs, workflow histories) instead of gathering screenshots the week before fieldwork.
6. Run a readiness review. Before the audit window opens, test a sample of controls internally or with your audit firm, and fix the gaps while they're cheap.

Your scope, asset inventory, access controls, and vendor list all depend on an accurate picture of the apps your company uses. See why SaaS management is important for SOC 2 compliance.

7 Best Practices for Managing SOC 2 Controls Across Teams

A SOC 2 report runs on proof. Promising that you follow your controls isn't enough. When we first went through our SOC 2 Type 2 audit as a small team of ten employees, we used our own product, Torii, to gather and store the proof we needed.

SOC 2 work spreads across IT, HR, Security, Finance, and Legal, which is where controls slip. Here are seven practices that help, with the criteria each one supports.

1. Automate Onboarding So Access Is Approved Before It Is Granted

Supports: CC6.2

Torii can manage onboarding as part of joiner, mover, and leaver governance. Beyond adding new employees to core tools before their first day, you can:

1. Alert the right teams automatically when a new employee is starting
2. Send a checklist of steps to be taken for the employee
3. Send a checklist of steps to be taken by the employee
4. Send employee responsibilities and company policies to the employee
5. Add employees to user groups on different systems automatically

2. Run Access Reviews That Cover Every App, AI Tool, and Non-Human Identity

Supports: CC6.2 and CC6.3

Torii shows you the systems employees use from the day they join until the day they leave. For core tools, you see who is an active user and what access rights they have, so you can:

1. Remove users who no longer need access to an application
2. Remove admin rights from users who no longer need privileged access
3. Add users and admins who should have access
4. Set up a workflow that alerts you when an employee accesses a retired application
5. Use the SSO audit report to see how employees sign in to each system

Don't stop at employee accounts. Include AI tools, which employees often connect on their own, and non-human identities such as service accounts and API keys. They hold access to company data too, and often have no clear owner.

3. Fully Offboard Departing Employees

Supports: CC6.2 and CC6.3 (access removal)

Departures are a common source of exceptions, because one forgotten app is enough. Beyond automatically removing employees from core tools, Torii lets you:

1. Send automated alerts to remove the employee from all applications
2. Alert the people responsible for non-SaaS tasks, such as collecting hardware
3. Automatically transfer files from one employee to another
4. Get a real-time report and audit of each employee's offboarding

4. Track Vendors and Renewals in One Place

Supports: CC9.2

Vendor risk management starts with knowing who your vendors are. Torii stores each app's contracts, contacts, and use cases, and helps you manage contracts and renewals. Renewal notifications give you time to run a security review before you sign again. When you end a vendor relationship, you can close the application in Torii and keep its data for audit purposes.

5. Store NDAs and DPAs With Each Vendor

Supports: C1.1 and CC9.2

Your vendors need confidentiality commitments that match your own, which usually means signed NDAs and data processing agreements (DPAs). Store them at the application level in Torii, so every team can find them and you can pull them for the auditor without searching inboxes.

6. Keep an Audit Trail of Every Control Action

Supports: CC4.1, plus the evidence for CC6.2 and CC6.3

Having controls is half the work. Proving they ran is the other half. Torii records its automated work and every update made in the platform, so you have:

• Who was onboarded, and what actions were taken
• Who was offboarded, and what actions were taken
• All applications discovered
• All documents stored
• All information added, including who changed it and when

7. Keep a Single Source of Truth for Every App

Supports: CC6.1 (asset inventory)

Torii can be your source of truth for every SaaS application, including ones nobody bought through IT. One place for owners, users, contracts, and documents gives every team the same picture, gives you the asset inventory CC6.1 points to, and makes scoping your next report faster.

Planning for Your Next SOC 2 Audit

SOC 2 isn't a one-time project. Customers ask for a current report, so the work repeats, and each cycle brings new apps, AI tools, service accounts, and vendors into scope. Treat your controls list as a living document and let your systems produce evidence as they go, so the next audit is easier than the last.

See how Torii helps with SOC 2 preparation. Book a demo.

[1] AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022)