Learn · SOC Reports
The SOC 2
Controls List
Ask for a SOC 2 controls list and every vendor will hand you one — including us, below. The caveat none of them lead with: SOC 2 prescribes no controls at all. The AICPA defines the criteria; your organization designs the controls that meet them.
No official list exists. The Trust Services Criteria define what controls must achieve — never which controls to run. The auditor evaluates whether your controls, as you designed and operated them, meet the criteria. Everything below is illustration, not prescription.
Plain-English explainer · Illustrative, not prescriptive · Last reviewed July 2026
SOC 2 has no official controls list. The AICPA defines criteria — the Trust Services Criteria — and each organization designs its own controls to meet them; the auditor’s job is to evaluate whether your controls, as designed and operated, satisfy those criteria. Which makes every “SOC 2 controls list” you will find — including the one on this page — a vendor’s illustration, not a requirement. We publish ours anyway, because a good illustration is genuinely useful: it shows what controls typically look like, where they cluster, and how much ground the examination covers. The list below is organized the way the criteria are — the nine common criteria series (CC1–CC9) evaluated in every SOC 2 against the Trust Services Criteria (the 2017 criteria, with points of focus revised in 2022), followed by the optional categories. If the framework itself is new to you, start with what SOC 2 is; to see where controls live inside the finished document, see how to read a SOC 2 report.
The Mechanics
Criteria, Not Controls
Frameworks like ISO 27001 ship a control catalog inside the standard. SOC 2 deliberately does not. The Trust Services Criteria are outcome statements — the Security category alone spans 33 criteria across the nine series CC1–CC9 — and they describe what must be achieved, never which mechanism achieves it. A criterion says, in effect, “the entity restricts logical access to authorized users”; it does not say SSO, MFA, or quarterly reviews. Your controls are the specific, testable mechanisms you choose. Three consequences follow:
- Two organizations can hold equally clean opinions with very different control sets — a 40-person SaaS company and a global payments processor should not run identical controls, and the criteria never ask them to.
- The audit question is never “do you have control X?” It is “do the controls you chose, taken together, meet criterion Y?” — asked criterion by criterion, with evidence.
- Section 4 of the finished report shows this mechanic in writing: each applicable criterion paired with your controls and the auditor’s tests. Unmet criteria surface there as exceptions — or, if severe, a qualified opinion.
Illustrative List
The Common Criteria, CC1–CC9
Security — expressed through the common criteria — is evaluated in every SOC 2 examination, whatever else is in scope. Below, each series with the controls organizations most commonly run against it. Treat every line as an example to adapt, not a box to tick.
CC1–CC5 · Aligned with COSO’s 17 principles
The governance backbone — these read like management practices because they are.
CC1 — Control Environment
Criteria CC1.1–CC1.5
Governance and people — whether the organization is structured to take control seriously.
- A board or senior leadership body oversees the security program and reviews its performance at defined intervals.
- An organization chart defines reporting lines, and security responsibilities are written into role descriptions.
- Background checks are completed for new hires before access is granted, where local law permits.
- A management-approved information security policy exists and is reviewed at least annually.
- Personnel acknowledge the code of conduct and security policies at hire and annually thereafter.
CC2 — Communication & Information
Criteria CC2.1–CC2.3
Whether the right information reaches the right people — inside the company and out.
- Security policies are published where all personnel can reach them — an intranet, wiki, or policy portal.
- Every employee completes security awareness training at onboarding and refreshes it annually.
- Service commitments — security, availability, support — are communicated to customers through contracts and SLAs.
- A defined channel lets personnel and external parties report security concerns or suspected incidents.
CC3 — Risk Assessment
Criteria CC3.1–CC3.4
Whether the organization identifies what could go wrong before the auditor does.
- A formal risk assessment runs at least annually, recorded in a risk register with owners, ratings, and treatment decisions.
- Fraud risk — including the possibility of management override — is explicitly considered.
- Vendor and subservice-organization risks are identified and assessed alongside internal ones.
- The assessment is refreshed when significant change lands: new products, acquisitions, major architecture shifts.
CC4 — Monitoring Activities
Criteria CC4.1–CC4.2
Whether anyone checks that the controls themselves keep working.
- Internal control performance is monitored through recurring reviews, dashboards, or internal audit.
- An annual penetration test is performed by a qualified independent party, with findings tracked to closure.
- Vulnerability scans run on a defined cadence — monthly or continuous — with results triaged by severity.
- Control deficiencies are logged, assigned an owner, and reported to management until remediated.
CC5 — Control Activities
Criteria CC5.1–CC5.3
Whether controls are actually deployed through policies and procedures — not merely intended.
- Each significant risk in the register maps to one or more controls that mitigate it.
- Controls are documented in procedures stating who performs them, how, and how often.
- Technology general controls — access, change, operations — cover the systems behind customer commitments.
- Policies and procedures are reviewed periodically and updated when the environment changes.
CC6–CC9 · The supplemental series
IT-focused criteria layered on top of COSO — where most technical controls concentrate.
CC6 — Logical & Physical Access
Criteria CC6.1–CC6.8
The largest series — where most of a technology company’s security controls live.
- MFA is enforced for all production access: cloud consoles, VPN, and administrative accounts.
- Access follows role-based profiles on a least-privilege basis, with documented manager approval.
- Provisioning and deprovisioning are ticketed, and departing users lose access within a defined window.
- Quarterly user-access reviews cover production systems, with documented sign-off and removals tracked to completion.
- Data is encrypted in transit (TLS) and at rest across production data stores and backups.
- Encryption keys sit in a managed key-management service and rotate under a defined process.
- Privileged access is restricted to a small named group, and privileged sessions are logged.
- Physical access to offices and any self-managed server space is badge-controlled, with visitor logging.
CC7 — System Operations
Criteria CC7.1–CC7.5
Detecting, responding to, and recovering from the things that go wrong anyway.
- Security-relevant events are logged centrally — a SIEM or equivalent — and retained for a defined period.
- Automated alerts fire on anomalies: failed-login spikes, unusual administrative actions, malware detections.
- A documented incident response plan defines severity levels, roles, and communication steps.
- The incident response plan is tested at least annually through a tabletop exercise or simulation.
- Identified vulnerabilities are remediated within defined timelines by severity, and capacity is monitored with alerting on thresholds.
CC8 — Change Management
Criterion CC8.1
One criterion, many controls — how changes reach production without breaking commitments.
- Production changes follow a documented SDLC: ticket, review, test, approval, deploy.
- Peer code review is required before merge — no one ships their own unreviewed change.
- The CI/CD pipeline enforces automated tests and approvals before deployment.
- Development, staging, and production environments are segregated, and production data is not used in test without safeguards.
- Emergency changes may bypass the standard path but are documented and reviewed after the fact.
CC9 — Risk Mitigation
Criteria CC9.1–CC9.2
Business disruption and vendor risk — mitigation beyond day-to-day security operations.
- Mitigation activities are defined for identified business-disruption risks.
- Cyber insurance is evaluated as part of the risk-transfer decision.
- Vendors are risk-tiered, and higher-risk vendors undergo security review before onboarding and periodically after.
- Contracts with critical vendors include security and confidentiality obligations.
- Subservice organizations’ own SOC reports are reviewed annually, including the CUECs they assign.
Two drafting notes. Weight: CC6–CC8 typically hold the bulk of a technology company’s controls and attract most of the evidence requests, so they deserve the most drafting care. Reuse: one well-designed control often serves several criteria — a quarterly access review alone supports multiple CC6 criteria — so the list above overstates how much genuinely separate machinery a lean program needs.
Optional Categories
Beyond Security: The Optional Series
The other four trust services categories join the scope only when your commitments call for them. Each brings its own criteria series — and therefore its own controls.
| Category | Include it when | Example controls |
|---|---|---|
| A seriesAvailability | You make uptime, continuity, or disaster-recovery commitments — SLAs with numbers in them. | Capacity planning and forecasting; scheduled backups with periodically tested restores; a documented disaster recovery plan exercised at least annually. |
| C seriesConfidentiality | You hold information bound by NDAs or contractual confidentiality clauses. | A data classification standard; NDAs with personnel and vendors; secure disposal of confidential information at the end of its retention period. |
| PI seriesProcessing Integrity | Customers depend on complete, accurate, timely, authorized processing — billing, payroll, payments. | Input validation and edit checks; monitoring of processing with error queues and escalation; reconciliation of outputs against source records. |
| P1–P8Privacy | You commit to how personal information is collected, used, retained, disclosed, and disposed of. | Privacy notice; consent and collection limitation; retention and disposal schedules; data-subject access handling; controls over third-party disclosure; data quality checks; monitoring and enforcement. |
Scope by commitment, not ambition: if your MSA promises uptime, Availability belongs in scope; if you never handle personal information under your own privacy notice, Privacy probably does not. Every added category adds criteria, controls, evidence, and audit hours.
The Numbers
How Many Controls in a SOC 2?
The only honest answer: as many as your organization defines. The AICPA sets no minimum, no maximum, and no target — the fixed quantity in a SOC 2 is the criteria, and the controls flex around them. Patterns do exist, though: in typical practice, Security-only examinations commonly land somewhere between roughly 60 and 150 controls, climbing as optional categories join the scope. Treat that as a description of what we commonly see prepared, not a rule — credible reports run leaner and heavier for good reasons. Four things move the number:
- Categories in scope — each optional category adds criteria, and every applicable criterion needs controls behind it.
- System boundary — more products, environments, and legal entities inside the description mean more controls.
- Granularity — one organization writes “access is reviewed quarterly” once; another writes it per system. Same practice, very different counts.
- Template inheritance — platform libraries often install more controls than the organization consciously chose to operate.
Resist treating the count as a maturity score. Every control you claim is a control the auditor tests, so a padded list impresses no one — it just widens your exception surface. A lean set of well-owned controls that demonstrably meets the criteria beats a long one nobody operates; the failure modes of the long list are catalogued in SOC 2 opinions and exceptions.
Your List
Building a Control Set You Actually Own
Five steps, in the order that prevents rework.
- 1Start from your commitments. List what you promise customers — in contracts, SLAs, DPAs, and your security page. The criteria are evaluated against your service commitments and system requirements, so the control set starts there, not in a template.
- 2Map the system. Draw the boundary the description will use — infrastructure, software, people, procedures, and data — plus the subservice organizations you build on and the CUECs you will expect of customers. Controls exist to protect this map.
- 3Draft series by series. Walk CC1–CC9, then any optional categories in scope, writing down what you actually do — one testable control at a time, each with a named owner and a frequency.
- 4Adapt platform libraries; don’t adopt them wholesale. Delete what does not apply, reword what remains until it describes your organization, and accept no control without an owner.
- 5Validate with a readiness assessment. Before the examination window opens, have someone play auditor: map controls to criteria, hunt for gaps and orphaned controls, and fix both. That is what audit preparation exists for.
To be fair to the compliance platforms: prebuilt control libraries mapped to the criteria are a real accelerant, and the monitoring layered on top genuinely helps evidence collection. The failure mode is not using a library — it is installing one and assuming the work is done. The auditor tests whether controls operated, not whether a template was present, and a control nobody runs fails the same way whether it was hand-written or shipped in a library. Tranquility Cybersecurity (TCSA) works on the preparation side of that line — scoping, control drafting, readiness assessment, evidence, and coordination of the examination through empanelled, independent licensed CPA firms, since only licensed CPA firms can issue the opinion. If a report is on your roadmap, start with our SOC 2 services overview.
SOC 2 Controls — Common Questions
The official-list question, typical counts, and who decides whether controls are enough.
Is there an official SOC 2 controls list?
No. The AICPA publishes the Trust Services Criteria — the 2017 criteria, with points of focus revised in 2022 — not a control catalog. Each organization designs its own controls to meet the applicable criteria, and the service auditor evaluates whether those controls, as designed and operated, actually do. Every published “SOC 2 controls list,” including the one on this page, is an illustration of common practice, not a requirement.
How many controls does SOC 2 have?
None are prescribed, so the real answer is: however many your organization defines. In typical practice, Security-only reports commonly run somewhere between roughly 60 and 150 controls, and counts rise as Availability, Confidentiality, Processing Integrity, or Privacy join the scope. That range describes what is commonly seen in preparation work, not a rule — the criteria set no minimum, maximum, or target.
What are the Common Criteria (CC1–CC9)?
The nine series of criteria used to evaluate the Security category, present in every SOC 2 examination. CC1–CC5 — control environment, communication and information, risk assessment, monitoring activities, and control activities — align with COSO’s 17 internal-control principles. CC6–CC9 — logical and physical access, system operations, change management, and risk mitigation — are the supplemental, IT-focused series where most of a technology company’s controls sit.
Do we have to use a compliance platform’s control set?
No. Compliance platforms ship prebuilt control libraries mapped to the criteria, and they are legitimate accelerators — but nothing requires them, and installing one is not the audit. The auditor tests whether your controls operated, not whether a template was present. If you use a library, prune what does not apply, reword the rest to match what you actually do, and give every control a named owner.
Does SOC 2 require MFA or encryption?
Not by name — SOC 2 prescribes no specific technology anywhere. The CC6 logical-access criteria require you to restrict access and protect information, and MFA plus encryption in transit and at rest are the near-universal ways organizations meet them. You cannot fail for lacking a named tool, but you would have to demonstrate how the criteria are met without it — an increasingly hard argument in modern practice.
Can we exclude controls or criteria from a SOC 2?
You scope categories, not criteria. The optional categories — Availability, Confidentiality, Processing Integrity, and Privacy — enter scope based on your commitments, and the common criteria are evaluated in every SOC 2. Within scope, the controls are your choice, but a criterion cannot simply be skipped: if no control addresses it, the auditor reports the gap as an exception or a qualification rather than ignoring it.
Who decides whether our controls are enough?
Ultimately the service auditor — a licensed CPA firm — whose opinion states whether your controls, as designed and (in Type 2) operated, meet the applicable criteria. Management asserts first; the auditor examines that assertion. A readiness assessment finds the gaps while they are still fixable. Tranquility Cybersecurity (TCSA) does that preparation and coordinates examinations through empanelled, independent licensed CPA firms — the opinion itself always comes from the CPA firm.
Related reading: the Learn hub, what SOC 2 is, the Trust Services Criteria in depth, how to read a SOC 2 report, SOC 2 opinions and exceptions, and our SOC 2 services. More terms in the compliance glossary.
Written By Expert Auditors
Get in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours