SOC 2 Controls List: The Complete List by Trust Services Criteria

The Complete SOC 2 Controls Framework Explained

The complete SOC 2 controls framework encompasses 47 foundational criteria organized across the five AICPA Trust Services Criteria: Security (Common Criteria CC1–CC9, 22 controls), Availability (6 controls), Processing Integrity (6 controls), Confidentiality (6 controls), and Privacy (7 controls). Security is mandatory for every SOC 2 audit.

When preparing for a SOC 2 audit, technology leaders frequently confront confusing terminology regarding the distinction between a "criterion" and a "control." Under the AICPA Trust Services Criteria (codified in TSP Section 100), the AICPA defines the universal criteria—the non-negotiable security requirements that an organization must fulfill. In turn, your engineering and operations teams define the specific controls—the technical policies, infrastructure configurations, and procedural guardrails designed to satisfy those criteria.

Because every company implements a bespoke technological architecture, the AICPA intentionally avoids prescribing rigid, mandatory control language. However, auditing firms evaluate controls against universal evidence standards. If a control lacks verifiable audit evidence—such as system-generated audit logs, cryptographic certificates, or documented peer approvals—auditors will note a testing deviation regardless of how sophisticated the underlying software may be.

To understand how these controls fit into an overall audit engagement, review our comprehensive overview of what SOC 2 actually is and how licensed CPA firms evaluate compliance.

Criteria Architecture: Scoping Common Criteria and Optional Additions

Security (Common Criteria CC1–CC9) is mandatory for 100% of SOC 2 audits. The remaining four criteria—Availability, Confidentiality, Processing Integrity, and Privacy—are optional modular additions scoped according to your contractual commitments, SLA terms, and customer data exposure.

Scoping your audit correctly is the single most impactful factor in controlling audit expenses and avoiding implementation burnout. Adding criteria unnecessarily expands the auditor’s testing surface, increases sample sizing, and inflates audit fees. The table below outlines when each criterion must be included:

Before committing to optional criteria with an auditor, evaluate your baseline maturity using our free, browser-based SOC 2 readiness assessment. It lets you toggle criteria dynamically to visualize the exact gap remediation requirements for each option.

The Complete 47 SOC 2 Controls Inventory by Criterion

Below is the complete 47-control inventory derived from the AICPA Trust Services Criteria. Each entry specifies the standardized control code, the core requirement in plain English, the primary evidentiary artifacts expected by CPA auditors, and its audit priority weight.

1. Security Criteria (Mandatory Common Criteria CC1.1 – CC9.2)

2. Availability Criteria (A1.1 – A1.3)

3. Processing Integrity Criteria (PI1.1 – PI1.5)

4. Confidentiality Criteria (C1.1 – C1.2)

5. Privacy Criteria (P1.1 – P8.1)

How CPA Auditors Map Evidence to Controls During Fieldwork

CPA auditors verify control execution by extracting population lists and selecting randomized statistical samples for evidentiary inspection. They evaluate primary source logs, timestamped screenshots, automated API pulls, and formal leadership approval records.

During an attestation examination, auditors never accept verbal affirmations or self-reported status spreadsheets. For every control in scope, your team must provide concrete artifacts that corroborate operational compliance. The audit testing methodology follows four rigorous verification standards:

• Inquiry: Interviews with control owners (such as CTOs, security directors, and DevOps leads) to evaluate understanding of policies and operating procedures.
• Inspection of Records: Detailed examination of timestamped system logs, automated CI/CD pipeline runs, signed vendor contracts, and HR background check completion certificates.
• Direct Observation: Live walkthrough demonstrations where engineers share their screens to show active MFA enforcement, AWS security group restrictions, or incident response alert dashboards.
• Re-Performance: The auditor independently recalculates an automated system output—such as re-running an access privilege query or executing a disaster recovery database restoration test.

To track evidence collection across all 47 controls interactively and record internal notes for your engineering team, use our interactive SOC 2 compliance checklist.

Tailoring Controls for Cloud-Native Stacks (AWS, GCP, Azure, GitHub)

Modern cloud-native startups satisfy SOC 2 criteria by leveraging automated cloud infrastructure capabilities, Infrastructure as Code (IaC), and identity provider integrations rather than creating manual, paperwork-heavy enterprise bureaucracy.

By mapping the 47 AICPA criteria to native cloud configurations, SaaS engineering teams can satisfy audit requirements programmatically:

• Access Management (CC6.1–CC6.3): Centralize identity with Okta or Google Workspace, enforce hardware WebAuthn MFA, and automate AWS IAM role assignment via Single Sign-On (SSO).
• Change Governance (CC8.1): Enforce GitHub branch protection rules requiring at least one approved peer code review, linear commit history, and passing automated unit/integration tests before merging to main.
• Continuous Encryption (CC6.1, C1.1): Enforce TLS 1.3 in transit across all public endpoints and utilize cloud KMS (Key Management Service) with customer-managed keys (CMKs) and automated annual rotation for data at rest.
• Continuous Auditing (CC7.2): Aggregate AWS CloudTrail, VPC Flow Logs, and application audit logs into an immutable storage bucket (S3 Object Lock) monitored by automated intrusion detection tooling.