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.
Download Complete SOC 2 Controls List (Excel & CSV)
Get the full 47-control inventory in a formatted Excel spreadsheet (.xlsx) or CSV. Includes control codes, plain-English requirements, auditor evidence requirements, implementation weights, and tracking columns.
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:
| Criterion | Controls | Applicability | When to Include |
|---|---|---|---|
| Security (Common Criteria) | 22 | Mandatory (All Audits) | Always in scope. Protects systems and customer data against unauthorized physical and logical access. |
| Availability | 6 | Optional | Include if contracts specify formal uptime SLAs (e.g., 99.9%), capacity monitoring, or disaster recovery failover times. |
| Processing Integrity | 6 | Optional | Include if your system executes automated financial transactions, algorithmic processing, or programmatic payroll runs. |
| Confidentiality | 6 | Optional | Include if customer agreements enforce specific Non-Disclosure Agreements (NDAs), sensitive proprietary data segregation, or scheduled secure data disposal. |
| Privacy | 7 | Optional | Include only if your platform directly collects, processes, and stores personal identifiable information (PII) subject to privacy frameworks. |
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)
| Code | Plain-English Requirement | Auditor Evidence Required | Weight |
|---|---|---|---|
CC1.1 |
Are information security policies documented, approved by leadership, and communicated to all personnel? Auditors start here: without written, approved policies, every other control lacks authority. This is the most common Day-1 gap. |
Information security policy document; leadership approval record; evidence of communication (e.g. onboarding pack, intranet post) | Critical |
CC1.2 |
Are security roles and responsibilities formally assigned (e.g. a named security owner)? Someone must own security decisions. In small teams this can be the CTO wearing a second hat — but it must be written down. |
RACI or role description naming the security owner; org chart | Medium |
CC1.3 |
Is there a formal joiner/mover/leaver process covering access provisioning and revocation? Orphaned accounts from ex-employees are one of the top audit findings. Auditors sample leavers and check deprovisioning dates. |
Joiner/mover/leaver procedure; sample of recent joiners/leavers with access grant and revoke timestamps | Critical |
CC2.1 |
Are security responsibilities communicated to employees at onboarding and at least annually? Policies nobody has read don't count. Auditors look for training records, not good intentions. |
Security awareness training records; onboarding checklist showing the security briefing | Medium |
CC2.2 |
Is there a defined channel for reporting security concerns, known to all staff? A reporting channel (even a monitored inbox) shows the control environment is alive, not just documented. |
Published reporting channel; internal comms referencing it | Low |
CC3.1 |
Has a formal risk assessment been performed in the last 12 months, identifying threats to the system? The risk assessment drives everything else — auditors expect it to be recent, documented, and actually used to choose controls. |
Risk assessment report dated within the last 12 months; risk register | Critical |
CC3.2 |
Are identified risks rated, assigned owners, and tracked to remediation? A risk list with no ratings, owners, or follow-up is decoration. Auditors check that significant risks have treatment plans. |
Risk register with ratings, owners, and status updates | Medium |
CC4.1 |
Are key controls monitored on an ongoing basis (automated checks, alerts, or scheduled reviews)? Point-in-time controls fail Type 2. Auditors want evidence that controls operated across the whole review period. |
Monitoring dashboards or alert rules; review logs showing the cadence | Medium |
CC4.2 |
Are control deficiencies and exceptions logged, tracked, and remediated within defined timeframes? Finding gaps is expected; ignoring them is not. Auditors sample exceptions to see the remediation trail. |
Exception/deficiency log with remediation dates | Medium |
CC5.1 |
Do documented procedures exist for the key security control activities (not just policies, but how-tos)? Policies say what; procedures say how. Auditors test whether staff actually follow the documented steps. |
Standard operating procedures for access provisioning, incident handling, and change deployment | Medium |
CC6.1 |
Is logical access to production restricted to authorized personnel with unique credentials and least-privilege roles? The single most-tested control family. Shared accounts and standing admin access are instant findings. |
Access control policy; IAM role definitions; list of production access holders | Critical |
CC6.2 |
Is multi-factor authentication enforced for remote access, admin consoles, and production systems? MFA gaps are among the most common failures. Auditors verify enforcement, not just availability. |
IdP MFA enforcement policy; report showing MFA coverage across users | Critical |
CC6.3 |
Are user access rights reviewed periodically (at least quarterly) by system or asset owners? Access reviews with no evidence didn't happen. Auditors ask for the review records and follow up on revocations. |
Quarterly access review records with reviewer sign-off and resulting access changes | Critical |
CC6.4 |
Are credentials managed securely — no shared accounts, no secrets or keys in code repositories? Secrets in git history are a classic startup finding. Auditors run scans or ask for your secret-management story. |
Secrets management tool in use; repository scan results; no-shared-accounts attestation | Critical |
CC6.5 |
Is access revoked promptly when people leave or change roles (within 24 hours for privileged access)? Auditors sample terminated employees and compare last working day against the deprovisioning timestamp. |
Deprovisioning tickets or logs matched to HR termination dates | Critical |
CC7.1 |
Are production systems monitored for security events, with alerts on anomalies? Logging without alerting is archiving. Auditors check that someone actually looks at the signals. |
SIEM or monitoring configuration; sample alerts with documented responses | Medium |
CC7.2 |
Is there a documented incident response plan, tested (tabletop or live) in the last 12 months? An untested incident response plan is a draft. Auditors want the test record and any lessons-learned actions. |
Incident response plan; tabletop exercise notes with date and attendees; resulting action items | Critical |
CC7.3 |
Are backups performed on schedule and restoration tested at least annually? Untested backups are Schrodinger's backups. Auditors ask for the restore test evidence. |
Backup schedule; restore test report with date and result | Medium |
CC8.1 |
Do production changes follow a formal process — approval, testing, and a rollback plan? Paper-only change management is a top-five finding. Auditors sample recent deploys for approval and test evidence. |
Change tickets showing approval and testing; rollback records | Critical |
CC8.2 |
Are production deployments separated from development (no direct edits to production)? Direct production edits bypass every other control. Pipelines with branch protection are the expected pattern. |
CI/CD pipeline configuration; branch protection rules; evidence of no direct production access | Medium |
CC9.1 |
Are new vendors and subservice organizations assessed for security risk before onboarding? Your auditors inherit your vendors' risk. Having no vendor assessment process is a common startup gap. |
Vendor risk assessment procedure; completed assessments for critical vendors | Critical |
CC9.2 |
Are SOC 2 reports (or equivalent assurance) collected and reviewed annually for critical vendors? For subservice organizations in your audit boundary, auditors expect you to monitor their controls — usually via their SOC 2 report. |
Vendor SOC 2 reports on file; review notes and follow-up on any qualifications | Medium |
2. Availability Criteria (A1.1 – A1.3)
| Code | Plain-English Requirement | Auditor Evidence Required | Weight |
|---|---|---|---|
A1.1 |
Are availability commitments (uptime SLA or targets) defined and communicated to customers? You can't be audited against commitments you never made. SLAs usually live in contracts or on a status page. |
SLA wording in customer contracts or terms; status page showing targets | Low |
A1.2 |
Is production infrastructure designed for resilience (redundancy, failover, multi-zone)? Single points of failure undermine availability claims. Auditors ask for the architecture story. |
Architecture diagram showing redundancy; failover test records | Medium |
A1.3 |
Are recovery objectives (RTO/RPO) defined and supported by backup and restore capabilities? RTO/RPO turn 'we have backups' into measurable commitments auditors can test. |
Defined RTO/RPO; restore tests demonstrating they are met | Medium |
A1.4 |
Is there a documented disaster recovery / business continuity plan, tested in the last 12 months? Same bar as incident response: documented and tested, or it doesn't count. |
DR/business continuity plan; test report with date, scope, and results | Critical |
A1.5 |
Is capacity monitored with alerting to prevent availability incidents? Running out of disk or compute is an avoidable outage. Auditors like to see proactive monitoring. |
Capacity monitoring dashboards; alert thresholds | Low |
A1.6 |
Are availability incidents tracked, with post-incident reviews for significant outages? Repeat outages without learning are a control failure. Auditors sample incident records. |
Incident log; post-mortem reports for major incidents | Medium |
3. Processing Integrity Criteria (PI1.1 – PI1.5)
| Code | Plain-English Requirement | Auditor Evidence Required | Weight |
|---|---|---|---|
PI1.1 |
Are system inputs validated for completeness and accuracy before processing? Garbage in, garbage out — auditors check that input controls exist for material processing. |
Input validation rules; error and rejection logs | Medium |
PI1.2 |
Are processing errors logged, investigated, and corrected within defined timeframes? Error handling is where integrity controls prove themselves under stress. |
Error logs with investigation and resolution records | Medium |
PI1.3 |
Are system outputs reconciled or validated against expected results? Reconciliations catch what input validation misses. Expected for financial or customer-facing outputs. |
Reconciliation procedures and completed reconciliations | Medium |
PI1.4 |
Is data retained and disposed of according to a defined retention schedule? Keeping everything forever is both a privacy and an integrity risk. |
Data retention policy; disposal/deletion logs | Low |
PI1.5 |
Are processing specifications documented, with changes to processing logic formally controlled? Undocumented processing logic can't be audited. Changes need the same rigor as code deploys. |
Processing specifications; change records for logic changes | Medium |
PI1.6 |
Is data protected against unauthorized modification during processing and transmission? Integrity means data nobody was supposed to touch stays untouched — checksums, signed payloads, TLS. |
Encryption in transit (TLS); integrity checks; transmission controls | Medium |
4. Confidentiality Criteria (C1.1 – C1.2)
| Code | Plain-English Requirement | Auditor Evidence Required | Weight |
|---|---|---|---|
C1.1 |
Is confidential information identified and classified (what counts as confidential)? You can't protect what you haven't defined. Classification usually starts with customer data and credentials. |
Data classification policy with defined categories | Medium |
C1.2 |
Is confidential data encrypted at rest and in transit? Encryption is the baseline expectation; auditors verify it, not just the claim. |
Encryption standards; at-rest encryption evidence; TLS configuration | Critical |
C1.3 |
Are confidentiality / NDA agreements in place with employees, contractors, and relevant third parties? The legal layer of the control — auditors sample agreements. |
Signed NDAs / confidentiality clauses; contractor agreements | Medium |
C1.4 |
Is access to confidential information restricted on a need-to-know basis? Overlaps with logical access but scoped to data: who can see customer data, and why them? |
Access matrices for confidential data stores; justification records | Medium |
C1.5 |
Are there procedures for secure disposal of confidential information (media, documents, devices)? Decommissioned laptops and old backups are classic leakage points. |
Disposal procedure; device wipe/destruction certificates | Low |
C1.6 |
Are confidentiality commitments to customers documented and monitored for compliance? If your contracts promise confidentiality, auditors check you keep the promise. |
Contract confidentiality clauses; monitoring/compliance records | Medium |
5. Privacy Criteria (P1.1 – P8.1)
| Code | Plain-English Requirement | Auditor Evidence Required | Weight |
|---|---|---|---|
P1.1 |
Is there a published privacy notice describing what personal data is collected and why? Notice is the foundation of every privacy criterion. Auditors read it first. |
Published privacy notice; version history | Medium |
P2.1 |
Is a lawful basis (consent or equivalent) established before collecting personal data? Collect first, justify later fails. The basis must be documented per data type. |
Consent records or lawful-basis register | Medium |
P3.1 |
Is collection limited to personal data necessary for the stated purpose (data minimization)? Hoarding personal data 'just in case' is a finding. Auditors ask why each field is collected. |
Data inventory showing the purpose per data element | Medium |
P4.1 |
Is personal data retained only as long as necessary, then securely deleted? Retention schedules must exist and be followed — auditors sample deleted-vs-retained records. |
Retention schedule; deletion logs | Medium |
P5.1 |
Can individuals access, correct, or delete their personal data on request, within defined timelines? Data subject rights need a working process, not a policy paragraph. Auditors test it. |
Data-subject-request procedure; log of requests with response times | Critical |
P6.1 |
Is personal data shared with third parties only with proper basis, with records of disclosures? Subprocessors and data sharing need contracts (DPAs) and a disclosure register. |
Data processing agreements with subprocessors; disclosure register | Medium |
P8.1 |
Are privacy incidents (breaches) identified, risk-assessed, and notified per policy and legal deadlines? Breach notification has legal clocks (e.g. 72 hours under GDPR). Auditors check the process exists before it's needed. |
Breach response procedure; incident log; notification templates | Critical |
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.
Evaluate Your Controls Maturity in 15 Minutes
Benchmark your security posture against all 47 criteria. Free, fully in-browser, with prioritized gap remediation and instant readiness scoring.