SOC 2 Controls List by Trust Services Criteria (CC1-CC9 + A/C/PI/P)

Criteria vs. controls vs. points of focus — what the AICPA actually publishes

The single most common misconception about SOC 2 is that the AICPA hands out a master control list you tick off. It does not. The AICPA publishes the 2017 Trust Services Criteria (With Revised Points of Focus — 2022) in TSP section 100 — a set of objectives your system must meet. You then design controls that satisfy those objectives, and a licensed CPA firm tests whether your controls meet the criteria. Two companies with identical scope can pass with completely different control sets.

This distinction matters because your control count is a design decision, not a fixed number. It also explains why a "SOC 2 controls list PDF" downloaded from a vendor is really a starter template mapped to the criteria — useful, but not authoritative. Four terms are worth keeping straight before you read the tables below.

One more clarification a CPA firm makes that generic guides skip: the Trust Services Criteria are a separate document from the AICPA's 2018 Description Criteria (also revised in 2022, published in the DC section). The Description Criteria govern how you write the system description and management assertion — the narrative sections of the report — while the Trust Services Criteria govern the controls the auditor opines on. This page is about the Trust Services Criteria.

The 5 SOC 2 Trust Services Criteria categories at a glance

SOC 2 organizes its criteria into five Trust Services Categories. Security — the Common Criteria — is the baseline present in every report; the other four are elective and chosen to match the commitments you make to customers. This examination is performed by a CPA firm under the AICPA's SOC 2 audit attestation standards; whether it tests design only or design plus operating effectiveness is the Type I vs Type II distinction.

A quick word on currency: the "2022" in the document title refers only to revised points of focus. The AICPA did not change any criterion in 2022 — the 61 criteria are identical to the 2017 set. So if a checklist says "2017 TSC," it is not out of date; the criteria simply have not changed.

The Common Criteria (CC1-CC9): the full index

The Common Criteria are the security backbone of every SOC 2 report. They comprise 33 individual criteria organized into nine series. Critically, CC1 through CC5 map one-to-one to the five components and 17 principles of the COSO 2013 Internal Control — Integrated Framework, while CC6 through CC9 are supplemental criteria the AICPA added for the Trust Services framework specifically. The centerpiece index below is the map most teams work from.

The three sections that trip teams up most are CC6, CC7, and CC9. CC1-CC5 are largely governance and documentation; CC6-CC9 are where operational engineering evidence lives, and where auditors spend the most time. The two deep-dive tables below expand CC6 and CC7 to the individual-criterion level.

CC1 — Control Environment

CC1 (five criteria, CC1.1-CC1.5) establishes the tone at the top: commitment to integrity and ethics, board independence and oversight, management's organizational structure and authority, commitment to competence, and accountability. It is the foundation the technical criteria rest on, and maps to COSO principles 1-5.

CC2 — Communication and Information

CC2 (three criteria) requires that relevant, quality information supports internal control, that it is communicated internally, and that it is communicated externally to parties such as customers. Example controls include distributing security policies and maintaining a public status page or trust portal.

CC3 — Risk Assessment

CC3 (four criteria) requires specifying objectives clearly enough to identify and assess risk, identifying and analyzing risk, assessing fraud risk, and evaluating how changes could affect the control system. The core artifact is a documented, periodically refreshed risk register.

CC4 — Monitoring Activities

CC4 (two criteria) requires ongoing and separate evaluations to confirm controls are present and functioning, and communication of deficiencies for timely correction. This is where internal audit, control self-assessments, and — for technical controls — penetration testing and continuous monitoring provide evidence.

CC5 — Control Activities

CC5 (three criteria) requires selecting and developing control activities that mitigate risk, selecting technology-based control activities, and deploying controls through policies and procedures. It is the bridge from risk assessment to the specific technical and operational controls in CC6-CC9.

CC8 — Change Management

CC8 contains a single criterion, CC8.1, but it carries heavy weight: the entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures. In practice this is your change-management and SDLC control — evidenced by change tickets, pull-request approvals, and CI/CD pipeline records.

CC9 — Risk Mitigation

CC9 has two criteria. CC9.1 covers identifying and developing risk-mitigation activities for business disruptions (including consideration of insurance). CC9.2 covers vendor and business-partner risk management — how you assess and monitor subservice organizations such as AWS, GCP, or Azure. This is the criterion that connects directly to the CUECs and subservice controls discussed below.

CC6 deep-dive: Logical & Physical Access Controls (CC6.1-CC6.8)

CC6 is the largest common-criteria series (eight criteria) and the most heavily tested area of any SOC 2 examination. The 2022 revision expanded its points of focus notably — for example, clarifying that logical access should be managed across employees, contractors, vendors, and business partners, and adding guidance on recovering devices such as laptops and phones. Below is each criterion with example control language and the artifact an auditor typically requests.

A fully worked example: CC6.1

To show what a real report row looks like, here is CC6.1 traced end to end. Criterion: the entity implements logical access security software, infrastructure, and architectures over protected information assets. Control: "MFA is enforced for all administrative access, and privileged access is provisioned only through a ticketed, manager-approved request." Test of control (Type II): the auditor selects a sample of accounts granted during the period and inspects the approval and MFA enrollment. Evidence: IdP configuration export plus the sampled access-request tickets. Result: "No exceptions noted" — or, if an approval is missing, an exception that may lead to a qualified opinion.

CC7 deep-dive: System Operations (CC7.1-CC7.5)

CC7 is the operational-security series: how you detect, respond to, and recover from vulnerabilities and incidents. It sits just behind CC6 in audit attention, and the 2022 points of focus strengthened its guidance around handling confidential information during operations. Two criteria draw the most scrutiny — CC7.2 (security monitoring) and CC7.4 (incident response).

A frequent design gap here mirrors the one in Availability: a written incident-response plan exists (CC7.4) but there is no evidence it has ever been exercised. Auditors increasingly expect a tabletop or live test, not just a document.

The four additional categories and their criteria

Beyond Security, you add categories that reflect the promises you make to customers. Each brings its own criteria, controls, and evidence. Note the recurring nuance in Availability's A1.3: the recovery plan must be tested, not merely documented — a written DR/BCP with no test evidence is one of the most common exceptions in the whole framework.

Availability (A1.1-A1.3)

Availability has three criteria: A1.1 (capacity management), A1.2 (environmental protections, backup, and recovery infrastructure), and A1.3 (testing recovery-plan procedures). Most SaaS companies that publish uptime SLAs add Availability. The A1.3 testing requirement is the one to watch.

Confidentiality (C1.1-C1.2)

Confidentiality has two criteria: C1.1 (identifying and maintaining confidential information) and C1.2 (disposing of it). It applies when you commit to protecting non-personal sensitive data — customer datasets, source code, or IP. It crosswalks naturally to HIPAA safeguards when the confidential data is health information.

Processing Integrity (PI1.1-PI1.5)

Processing Integrity has five criteria covering whether processing is complete, valid, accurate, timely, and authorized. It is most relevant to fintech, payments, and analytics platforms where customers rely on the correctness of outputs, not just their confidentiality.

Privacy (P1-P8 series)

Privacy is the largest optional category — roughly 18 criteria organized into eight series covering the full personal-information lifecycle: P1 notice, P2 choice and consent, P3 collection, P4 use/retention/disposal, P5 access, P6 disclosure to third parties, P7 quality, and P8 monitoring and enforcement. It is the natural on-ramp for organizations already subject to GDPR or CCPA, and its access and disclosure criteria map closely to GDPR data-subject rights.

How to choose which categories to include

Selecting categories is a scoping decision, not a compliance formality — every category you add multiplies controls and evidence. The rule of thumb: include a category only if you make a commitment to customers that it covers. When you are ready to formalize this, our guide to scoping your SOC 2 systems walks through the mechanics.

Once categories are set, the practical next step is turning criteria into an operating plan — our SOC 2 readiness checklist maps each criterion to owners and evidence, and the SOC 2 audit timeline shows how it sequences.

SOC 2 to ISO 27001 & NIST CSF crosswalk

If you already run — or plan to run — ISO 27001 or NIST, the good news is significant overlap. Roughly 70% of SOC 2 controls satisfy ISO 27001 Annex A requirements, so a single control library can serve both with modest additions. The mapping below is directional (it links CC series to their closest counterparts) and is a common reason teams pursue the two frameworks together.

Treat this as a starting point, not a substitute for a formal mapping exercise. The exact Annex A control depends on how you have written each SOC 2 control, but the CC6 → access/cryptography and CC9 → supplier-relationship links are stable across frameworks.

CUECs and subservice controls — the controls that aren't yours

A complete controls list includes controls you don't operate but depend on. SOC 2 reports formalize two such categories, both tied to CC9.2's vendor-risk criterion.

Complementary User Entity Controls (CUECs) are controls the report assumes your customers operate for the overall control objectives to be met — for example, "user entities are responsible for provisioning and deprovisioning their own end-user accounts in the application." If your customers don't perform them, the assurance is incomplete on their side.

Complementary Subservice Organization Controls (CSOCs) are controls the report assumes your subservice providers operate — most commonly your cloud platform (AWS, GCP, Azure). When you use the "carve-out" method, you exclude the subservice provider's controls from your description but list the CSOCs you rely on and monitor them (typically by reviewing the provider's own SOC 2 report). This is exactly the vendor-monitoring evidence CC9.2 expects.

Common exceptions by criterion — and how to fix them

Certain criteria generate the same findings audit after audit. Knowing them in advance is the cheapest insurance; for the full playbook see our guide to common SOC 2 findings.

A note on tooling: platforms such as Vanta, Drata, and Secureframe ship prebuilt control libraries mapped to these criteria and automate evidence collection. They accelerate the work, but they collect evidence — they don't create your controls or replace the auditor's independent testing. The control design and its operation are still yours to own, tested under our audit methodology.