SOC 2 Controls List: What Controls Do You Need to Implement?

There is no universal SOC 2 control list. It is up to you to select controls that satisfy whichever of the five Trust Services Criteria are in your scope (61 requirements if you include all five), then prove to your auditor that those controls are designed and operating effectively.

In your SOC 2 report, the CPA will name every control you asserted and, in a Type 2 report, record any exception they find when testing those controls across the review period. That means a skipped quarterly access review, a change pushed without a ticket, or a policy nobody acknowledged could become a written exception that your prospects and their security teams read before they sign a contract with you.

To ensure you have a clean SOC 2 report, this page covers the types of controls that satisfy each Trust Services Criterion and examples of the evidence that proves them.

How many SOC 2 controls are there?

There is no required number of SOC 2 controls. The count depends on which Trust Services Criteria you include in scope, how complex your infrastructure is, and how your organization chooses to meet each criterion. Most organizations end up with somewhere between 60 and 100 controls.

For a more concrete reference point, here is an illustrative example of what a SOC 2 control set might look like when scoped to Security, Availability, and Confidentiality:

Two things stand out in that data.

• First, controls and requirements are not one to one. For instance, a formal risk assessment helps satisfy eight different requirements in the SOC 2 framework, while the requirement for policies and procedures (CC5.3) is supported by 24 separate controls because every written policy lands there.
• Second, controls can outnumber requirements more than two to one, and tests usually outnumber controls. So the bulk of the work of SOC 2 is less about implementing a certain number of controls and more about producing evidence that each one was in place and operated as described to meet the requirements for the entire review period.

How do SOC 2 controls, tests, evidence, and requirements fit together?

To comply with SOC 2, your controls need to meet the requirements of your in-scope Trust Services Criteria, and you need tests and evidence to show those controls are designed and operating effectively.

Here's how these different pieces of SOC 2 compliance relate:

• A requirement states an outcome
• A control is what your organization does to achieve that outcome
• A test checks that the control operates as intended
• Evidence is the proof that it does, typically a screenshot, policy, training record, ticket, or other artifact

During a SOC 2 audit, your auditor evaluates whether each control is designed to meet its requirement. For a Type 2 report, they then test whether each control operated as described throughout the review period. That testing typically involves interviewing personnel, inspecting evidence like tickets and policy documents, observing a process, or reperforming a control or process, such as attempting to log in to a system without multi-factor authentication to ensure it fails.

In a SOC 2 automation platform, requirements are mapped to applicable controls, and controls are mapped to tests. Although some require manual uploads, many tests run and collect evidence automatically through integrations or in-platform modules, like policy and risk management, and are monitored continuously so you can see a failing control and fix it before your auditor finds it.

Here’s what this might look like in practice: Your auditor pulls a list of terminations from HR for the review period, selects a sample, and compares each person's termination date with the date their access was actually removed according to JIRA tracking. A two-week lag on one departed engineer can be enough for an exception, even if your policy and tooling are sound.

Because one control can satisfy several requirements, and one test can support several controls, mapping these relationships is where most of the effort goes. It is also why organizations that already hold one framework rarely start from zero on the next.

Where do the AICPA SOC 2 Points of Focus fit in?

The American Institute of Certified Public Accountants (AICPA) publishes “points of focus” for each Trust Services criterion. Points of focus are examples of how an organization could satisfy a requirement, but they aren’t the only ways an organization can.

In other words, points of focus aren’t requirements. They're simply guidelines to help you better understand what you can do to meet each requirement. They’re also a good resource for understanding how an auditor will think about each TSC when evaluating and testing your organization's controls.

For example, one point of focus for CC1.1 (a commitment to integrity and ethical values) is establishing standards of conduct and communicating them at every level of the business. A Code of Conduct policy that every employee acknowledges is one example of a control that addresses it.

So while there are specific criteria required for compliance, how your organization satisfies them is up to you and your CPA auditor. That means, ultimately, no two SOC 2 audits or reports are identical.

SOC 2 controls list by Trust Services Criterion

The tables below list example controls for each Trust Services Criterion, along with the tests and evidence that can prove they’re in place and operating effectively. Each table shows one representative requirement per category. Note that these are illustrative examples, not prescriptive ones. Your control set may differ based on your scope, systems, and auditor.

Security controls (Common Criteria)

Security is the only Trust Services Criterion required in every SOC 2 audit. Its 33 requirements, called the Common Criteria, are grouped into nine series (CC1 through CC9). They cover far more than technical safeguards: roughly a third of the Common Criteria address governance, people, risk, and communication.

That is why an auditor reviewing security may look at multi-factor authentication and firewall rules, but also at board minutes, background checks, and whether employees actually signed your policies.

Availability controls

The Availability criteria require you to manage capacity, protect and back up the systems your customers depend on, and prove your recovery plan works. They are most often added to scope by SaaS and infrastructure providers whose customers would be directly affected by downtime.

Confidentiality controls

The Confidentiality criteria require you to identify confidential information, protect it for as long as you keep it, and dispose of it when you no longer need it. Confidential information is typically business data your customers share with you under contract, like financial records, intellectual property, or customer lists, and unlike personal information, it is often useful precisely because it can be shared with authorized parties.

Processing integrity controls

The Processing Integrity criteria require your system to process data completely, accurately, on time, and only as authorized. They are most relevant when customers rely on your system's outputs directly, such as payment processing, payroll, data transformation, or financial reporting services.

Privacy controls

The Privacy criteria require you to handle personal information according to the commitments in your privacy notice, from collection through disposal. With 18 requirements across eight series, Privacy is the largest category after Security, and it is typically added to scope by organizations that collect personal information directly from individuals.

How to choose and document your SOC 2 controls

Choosing SOC 2 controls starts with your scope and ends with evidence you can produce for every day of the review period. The steps below, which run in parallel with the broader SOC 2 audit process, reflect how most organizations build a control set that holds up under testing, rather than one that only looks complete on paper.

1. Define your scope and Trust Services Criteria.

Decide which systems, services, and data are in scope, and which criteria beyond Security your customers actually need. Every category you add brings its own requirements, controls, and evidence, so add Availability, Confidentiality, Processing Integrity, or Privacy because a customer commitment calls for it, not by default.

2. Start from a mapped control set, not a blank page.

Writing controls from scratch against dozens of requirements invites both gaps and duplicates. Starting from a set that is already mapped to the criteria, and to frameworks like ISO 27001 if they are on your roadmap, lets you focus on tailoring rather than drafting.

3. Check every requirement for coverage.

Confirm that each in-scope requirement maps to at least one control, and pay extra attention to thinly covered ones. For example, fraud risk (CC3.3) and board independence (CC1.2) may only have one or two supporting controls, so a weakness in any of those controls leaves the requirement uncovered.

4. Write each control the way it will be tested.

Your auditor tests the control as you describe it. If a control says access is reviewed quarterly, changes are approved by an independent reviewer, or backups are restored annually, those frequencies and conditions become the test. Describe what you actually do, and avoid committing to a cadence your team can't sustain.

5. Assign an owner and an evidence source to every control.

Each control needs a person accountable for it and a defined source of evidence, whether that is an integration, a ticketing system, or a document. Controls without a clear owner are the ones most likely to be missed mid-period.

6. Test before the auditor does.

A readiness assessment shows which controls would fail today, while you still have time to fix them before the review period begins.

7. Monitor continuously through the review period.

For a Type 2 report, a control that works in month one and lapses in month seven still produces an exception. Continuous monitoring and alerts on failing tests help you maintain compliance between audits instead of reconstructing evidence at the end.

The organizations that come out of SOC 2 with clean reports generally aren't the ones with the most controls. They are the ones whose controls match what they actually do, with evidence collected as the work happens.

How Secureframe helps you implement and prove SOC 2 controls

Secureframe maps a SOC 2 control set to the Trust Services Criteria in your scope, then connects those controls to tests that run continuously through integrations with your cloud providers, identity tools, code repositories, ticketing systems, and endpoints.

Failing tests surface before your auditor finds them, and evidence is automatically collected throughout the review period rather than leaving you to assemble it at the end. Because Secureframe uses common controls across frameworks, the same controls and tests also count toward ISO 27001, HIPAA, and other frameworks you add later.

To see how Secureframe maps and tests your SOC 2 controls and simplifies the entire compliance process end-to-end, request a demo.

This post was originally published in November 2021 and has been updated for accuracy and comprehensiveness.