SOC 2 Trust Service Criteria: All Five Categories, Every Criterion Number

SOC 2 Trust Service Criteria: All Five Categories, Every Criterion Number

TL;DR

• Security (CC1–CC9) is the only mandatory category. Every SOC 2 report covers it.
• Availability (A1), Processing Integrity (PI1), Confidentiality (C1), and Privacy (P1–P8) are optional and chosen based on what your customers actually need.
• The governing document is the AICPA's 2017 Trust Services Criteria with Revised Points of Focus — 2022, published September 2023.
• The term "Trust Service Principles" is obsolete. The AICPA renamed them "Trust Service Criteria" in 2017.
• Each optional category adds specific criterion numbers on top of the Common Criteria (CC1–CC9); controls do overlap, so adding Availability does not require building from scratch.

Editorial note: This article was drafted using AI-assisted summarization of the AICPA's publicly available 2017 Trust Services Criteria (Revised Points of Focus — 2022) and verified claim-by-claim against the primary source document before publication. The Security Compliance Guide editorial team includes professionals with backgrounds in information security and compliance program management. We are not licensed CPA auditors or attorneys; this article is a reference guide, not audit advice. For binding scoping decisions, engage a licensed CPA firm registered with the AICPA.

Who this is for

This article is written for security engineers, compliance leads, and startup founders preparing for a first or expanded SOC 2 audit. It assumes familiarity with the concept of an audit but not with the AICPA's criterion numbering system. If you need a step-by-step evidence checklist, see our SOC 2 compliance checklist.

Security: CC1 Through CC9

Security is the only required Trust Service Criterion. Every SOC 2 report — Type I or Type II (see what is a SOC 2 Type II report) — covers it. The AICPA groups Security controls under nine Common Criteria (CC) clusters, all drawn from the 2017 TSC document.

CC1: Control Environment

CC1 is the governance layer — not a technical control, which surprises many engineering-led organizations preparing their first audit. It requires board-level oversight of the control structure, a defined organizational hierarchy with accountability for security, and documented HR policies covering hiring, training, and termination. Auditors look for governance artifacts: board charters, code-of-conduct acknowledgments, and org charts with clear reporting lines. The most common gap here is a code of conduct that was signed once during onboarding and never re-acknowledged; annual re-acknowledgment with a signed record is the standard auditors expect.

Practitioner note — CC1 for startups without a board: Venture-backed companies with an informal investor advisory arrangement still need to demonstrate oversight. Document your security governance touchpoints in board meeting minutes, including any discussion of the security program's status. A single paragraph per quarter in written minutes satisfies this requirement and takes ten minutes to produce.

CC2: Communication and Information

CC2 has two distinct scopes that get conflated: internal communication (employees receive the policies and procedures needed to perform their control responsibilities) and external communication (customers and service providers receive accurate information about the system and its boundaries). Auditors test both. Log management, security policy distribution, and vendor communication procedures sit under CC2, but so does your public system description — the document that defines what the SOC 2 is actually covering. A system description that understates the actual data flows is a CC2 finding, not just a scoping note.

CC3: Risk Assessment

CC3 requires identifying and analyzing risks to achieving the organization's objectives. Two requirements trip up first-time audit candidates. First, CC3 mandates identifying fraud risks separately — not embedded in general operational risk, but explicitly called out. Second, it requires a process for identifying new risks triggered by change events: new product features, acquisitions, regulatory updates, key personnel departures. The risk register is the central artifact. It should be revisited at defined intervals and after material changes, and those reviews need to leave a dated record.

Practitioner note — risk register frequency: There is no AICPA-specified review cadence for the risk register, but quarterly review with a written record of who participated and what changed (including "no changes identified") is the floor that most experienced auditors accept for a SaaS company. Annual-only reviews create a coverage gap that becomes a finding if a significant change event occurred mid-year without a documented risk reassessment.

CC4: Monitoring Activities

The organization evaluates whether controls are operating effectively over time. This means ongoing monitoring (automated alerting, dashboards) and separate evaluations (internal audits, management reviews). Deficiencies identified through monitoring must be communicated to whoever can act on them. CC4 is where many first-time audit candidates are caught short: they have controls but no evidence of regularly reviewing whether those controls worked.

Practitioner note: The most common CC4 gap is not a missing control — it is missing evidence that the control produced output. A SIEM configured to alert on privilege escalation satisfies the tool requirement. The auditor's question is: "Show me the last 90 days of those alerts and what the team did with them." If that review history does not exist in a ticket, email chain, or log comment, CC4 is not met. Build your evidence cadence — weekly or bi-weekly triage of monitoring outputs — before your observation period begins, not during it.

CC5: Control Activities

CC5 covers the implementation layer: documented policies and procedures that direct people and systems to take the right actions. Financial controls, technology access controls, segregation-of-duties requirements, and physical access to facilities all fall here. The auditor's traceability check runs CC5 back to CC3: each control should map to a risk identified in the risk register. Controls that exist but cannot be traced to a specific risk, or risks in the register without corresponding controls, are CC5 gaps. This mapping is often the most time-consuming pre-audit exercise for organizations building their control framework from scratch.

CC6: Logical and Physical Access Controls

CC6 is often the most evidence-heavy Common Criteria cluster. It covers:

• User provisioning and de-provisioning (including off-boarding timelines)
• Authentication mechanisms (MFA, password complexity)
• Authorization frameworks (role-based access, principle of least privilege)
• Encryption of data in transit and at rest
• Physical access to data centers and offices

For cloud-native organizations, physical security evidence often comes from the cloud provider's own SOC 2 or ISO 27001 report via a third-party reliance argument. That argument must be explicitly documented.

CC7: System Operations

The organization monitors and responds to anomalies in system operations. This includes intrusion detection, vulnerability management, and incident response procedures. Auditors will ask for evidence of actual alerts, not just that a SIEM is configured. Incident response runbooks must be current and tested; a runbook that has never been exercised does not satisfy CC7.

Practitioner note on Points of Focus: The 2017 TSC document structures each criterion around Points of Focus — the AICPA's illustrative sub-items that auditors use to evaluate whether a criterion is met. CC7, for example, includes Points of Focus covering the detection and response to security events and the identification of new vulnerabilities. Your auditor will not necessarily test every Point of Focus, but they will expect your controls to be traceable to them. When mapping your control set to the TSC, work at the Point of Focus level, not just the criterion level — this is where gaps surface before fieldwork, not during it. The full Points of Focus are published in the 2017 TSC document (see Sources).

CC8: Change Management

CC8 covers controlled changes to infrastructure, data, software, and procedures. Core evidence items: a formal change request process, peer code review requirements, separation of development and production environments, and documented rollback procedures. CC8 is where organizations running fast CI/CD pipelines with direct-to-production deploys face the most friction — not because fast deployments are inherently non-compliant, but because each deploy must leave an evidence trail. Pull request reviews in GitHub, approved Jira tickets linked to deploy records, and protected main branch rules with required reviewers are all acceptable; verbal approvals and force-pushes are not.

Practitioner note — emergency change procedures: CC8 requires a documented exception process for emergency changes that bypass the normal approval flow. Auditors will look for this. Define it in writing: what constitutes an emergency, who can authorize an out-of-band deploy, and what retrospective review is required within 24–48 hours. Without a documented emergency procedure, every hotfix deploy is an untested control exception.

CC9: Risk Mitigation

CC9 formalized vendor risk management as a SOC 2 requirement. It covers vendor security assessments, contractual security requirements, ongoing monitoring of critical vendors, and incident notification clauses in vendor agreements. What trips up first-time candidates is scope: CC9 applies to any third party whose failure could affect the security of the in-scope system — not just software vendors, but also payment processors, data center operators, and any subprocessor that touches customer data.

Practitioner note — tiering vendors for proportionate review: Not every vendor needs a full security questionnaire. A defensible CC9 program classifies vendors by criticality (based on data access and system dependency) and applies review depth accordingly: full questionnaire plus annual re-review for Tier 1 vendors with system access; SOC 2 or equivalent report review for Tier 2; a lightweight checklist for Tier 3. Auditors accept this tiering approach when the classification logic is documented. A flat "we assess all vendors the same way" approach either over-burdens the program or leaves critical vendor gaps unexamined.

Availability: A1

The Availability criterion uses a single criterion label, A1, which encompasses the full set of Availability-specific control points. It evaluates whether the system is available for operation and use as committed or agreed — meaning against SLAs, not against a universal standard. A service that commits to 99.5% uptime is measured against 99.5%, not 99.99%.

A1 control areas include:

Capacity and performance management. The organization monitors current system capacity (compute, storage, network) against defined thresholds and plans for future demand. Evidence: monitoring dashboards, capacity planning records, scaling event logs.

Disaster recovery. A documented DR plan with Recovery Time Objectives and Recovery Point Objectives. The plan must be tested, with results documented and deficiencies tracked. Testing frequency is not prescribed by A1, but annual testing is the de facto auditor norm for most service organizations. A critical distinction auditors probe here: a DR test that was conducted but produced no written findings does not satisfy A1. The test output must include what was exercised, what succeeded, what failed, and how any failures will be remediated — an undocumented "we ran it and it worked" is treated as no test at all.

Availability incident response. Procedures for detecting, escalating, and resolving incidents that breach availability commitments. Mean Time to Detect and Mean Time to Resolve are metrics auditors commonly review against SLA thresholds.

Backup and restoration. Backup schedules, retention periods, and verified restoration procedures. The word "verified" is deliberate: backups that are created but never restoration-tested do not satisfy A1.

Environmental and infrastructure protections. For organizations running on AWS, Azure, or GCP, the cloud provider's shared-responsibility model covers physical environmental controls. The organization must demonstrate it has configured multi-region or multi-AZ architecture where its availability commitments require it — this is not automatic.

Availability is the second most frequently included criterion after Security among SaaS providers who publish their SOC 2 scope publicly. Any SaaS product with enterprise customers operating under a signed SLA will face this as a procurement requirement.

Processing Integrity: PI1

Processing Integrity uses a single criterion label, PI1, covering the full set of controls over whether system processing is complete, valid, accurate, timely, and authorized.

This criterion is about what the system does to data — not about whether the data was accurate when it arrived. A payroll system that receives a correct salary figure and then applies the wrong tax bracket has a processing integrity failure. A fintech platform that processes a batch job out of sequence creates a processing integrity risk.

PI1 control areas include:

Input validation. Controls that verify incoming data meets defined parameters before it enters processing. Format checks, range validations, duplicate detection, and referential integrity rules all count.

Processing monitoring. Reconciliation procedures, automated exception alerts, and job scheduling controls that verify processing runs as designed. Auditors ask for evidence that exceptions are logged, investigated, and resolved, not just that exception handling code exists.

Output verification. Controls that confirm processing results are complete and accurate before delivery. For financial data this often means record-count reconciliations or dollar-amount totals compared across systems. For data transformation pipelines it means checksum or hash comparisons between input and output.

Error handling and correction. Documented procedures for logging, investigating, and correcting processing errors. Root-cause analysis is the expected depth: resolving the symptom without addressing the cause does not satisfy PI1.

Processing Integrity is the least frequently included criterion — most SaaS companies do not expose transaction processing in a way that creates significant downstream financial or operational risk for customers. It is common in payroll, financial data aggregation, insurance premium calculation, and healthcare data processing.

Practitioner note — scoping PI1: A frequent scoping mistake is including PI1 because the product touches financial data, rather than because the product transforms financial data in a way that affects customer downstream obligations. A SaaS platform that stores payroll records but does not calculate tax liabilities or run payment batches typically has no PI1 obligation. A platform that calculates net pay, applies tax rules, and generates ACH payment files has a direct PI1 obligation. The test is: if your system produces incorrect output, does a real financial or operational harm flow directly to your customer or their end users? If yes, PI1 belongs in scope. Scope creep here adds significant audit cost for no corresponding customer assurance value.

Confidentiality: C1

Confidentiality uses a single criterion label, C1. It covers whether information designated as confidential is protected as committed or agreed.

"Confidential information" under the TSC means any data your organization has agreed to treat as confidential — trade secrets, intellectual property, customer data under NDAs, financial forecasts, M&A plans. It does not mean personal information specifically; that is Privacy. An organization can have C1 obligations without having P1–P8 obligations if it holds business-sensitive data but not personal data about individuals.

C1 control areas include:

Data classification. A formal policy defining what constitutes confidential information and the protections applied at each classification level. Without documented classification, there is no coherent way to demonstrate that confidential data received appropriate treatment.

Encryption. Confidential data encrypted at rest and in transit. AES-256 and TLS 1.2 or later are current technical standards. Key management documentation must cover rotation schedules, access restrictions, and the process for handling key compromise.

Access controls. Least-privilege access to confidential data, with access reviews conducted at defined intervals. Auditors will ask for evidence of reviews — not just that a review process exists in a policy document.

Retention and disposal. Defined retention periods for confidential data, with documented secure disposal procedures for both digital (cryptographic erasure, secure deletion) and physical media (shredding, degaussing). The disposal of media after decommissioning cloud instances is an area where gap evidence often exists.

Third-party management. NDAs or equivalent contractual protections covering any third party that receives confidential information. Vendor security assessments confirm the third party can actually honor those commitments.

Confidentiality is commonly included as a third criterion alongside Security and Availability. Legal technology, data analytics, consulting, and government contractor organizations face the highest demand for it from customers.

Privacy: P1 Through P8

Privacy has eight criterion points, P1 through P8, making it the most granular of the five categories. The P-series is structurally derived from the AICPA Privacy Management Framework; the eight criteria consolidate and update the ten principles from the earlier 2009 AICPA/CICA Generally Accepted Privacy Principles (GAPP) document. The Privacy criterion applies when an organization collects, uses, retains, discloses, or disposes of personal information — any data that can identify an individual.

P1: Notice. The organization communicates its privacy practices to individuals, including what personal information it collects, why it collects it, how it uses it, and with whom it shares it. A published privacy policy is the baseline artifact; it must accurately reflect actual practices.

P2: Choice and Consent. Individuals are given meaningful choices about the collection, use, and disclosure of their personal information. Consent mechanisms must match the sensitivity of the data — opt-in for sensitive categories, opt-out for less sensitive. Auditors compare consent flows in the product against the stated policy.

P3: Collection. The organization collects personal information only for the purposes identified in the notice, and only what is necessary for those purposes. This is data minimization in practice. Auditors examine data flows and database schemas to verify that collection matches stated purpose.

P4: Use, Retention, and Disposal. Personal information is used only for the purposes identified in the notice. Retention periods are defined per data type, and data is disposed of when those periods expire. Automated retention enforcement — rather than manual deletion — is the most defensible implementation.

P5: Access. Individuals can access, review, and correct their personal information. The organization must provide a working mechanism for access requests and respond within a defined timeframe. For organizations subject to GDPR or CCPA, the DSR (Data Subject Request) process satisfies P5, though the SOC 2 scope may differ.

P6: Disclosure to Third Parties. Personal information is disclosed to third parties only for the purposes in the notice and with appropriate safeguards. This requires a data processing agreement or equivalent with each third-party recipient. Sub-processor lists, required under GDPR Article 28, overlap significantly with P6 evidence.

P7: Security for Privacy. Personal information is protected against unauthorized access, disclosure, or destruction. The specific controls mirror CC6 and C1 — encryption, access controls, logging. P7 effectively requires that the Privacy criterion be backed by the Security criterion's technical controls.

P8: Quality. The organization maintains accurate, complete, and relevant personal information for the stated purposes. This means procedures for correcting inaccurate data upon request and data quality monitoring for systems where accuracy matters to the individual (credit data, healthcare records, employment data).

One important distinction: if your organization already meets GDPR or CCPA requirements, you have addressed many P1–P8 requirements. GDPR's lawful basis requirements (Article 6) align with P2; GDPR's right of access (Article 15) aligns with P5; GDPR's data minimization principle (Article 5(1)(c)) aligns with P3. The gap between regulatory compliance and P1–P8 satisfaction is usually documentation format and the specific evidence format SOC 2 auditors expect, not the controls themselves.

Practitioner note — P1 through P8 vs. Type I vs. Type II timing: Privacy criteria are typically tested over the full observation period in a Type II engagement. P5 (Access) is particularly exposure-prone: the auditor will select a sample of Data Subject Requests received during the observation window and verify that each was responded to within the organization's stated timeframe. Organizations that have a documented DSR process but no ticket or email records of actual requests being processed — because they have received zero requests — should document that fact explicitly rather than leaving it blank. A zero-request assertion with a working DSR mechanism on record is auditable. An undocumented gap is not.

How to Choose Which Criteria to Include

The right combination of criteria depends on four factors: your business model, your customer contracts, your regulatory obligations, and your current control maturity.

Most organizations reaching out to enterprise procurement for the first time need Security and Availability. Adding Confidentiality is a one-to-two cycle decision once Availability is bedded in. Processing Integrity and Privacy follow the product model, not timeline pressure.

How to read customer questionnaires for criteria signals: Enterprise security questionnaires often ask for SOC 2 reports without specifying which criteria. The implicit signal is in the question set: if a questionnaire contains detailed uptime/SLA questions, the customer cares about Availability even if they don't say it. If it contains data classification questions and asks about NDA obligations between you and your sub-processors, Confidentiality is implied. If it asks for a GDPR Article 28 DPA or a CCPA service provider addendum, Privacy is in scope. Using the questionnaire as a scoping signal is more reliable than asking the customer directly — most procurement teams do not know which SOC 2 criteria they want, only what operational risks they are trying to mitigate.

Mapping TSC to Other Frameworks

Organizations already aligned with ISO 27001 or NIST CSF find meaningful overlap with the SOC 2 Common Criteria, but the overlap is in control substance, not in documentation format. Auditors require SOC 2-specific evidence even when the underlying control is identical to an ISO 27001 Annex A control.

The ISO 27001:2022 column uses 2022 control numbers. The legacy 2013 numbering differs; organizations still operating against the 2013 standard should verify the mapping before relying on this table.

Frequently Asked Questions

Do I need all five Trust Service Criteria for SOC 2?

No. Security (CC1–CC9) is the only required category. Availability (A1), Processing Integrity (PI1), Confidentiality (C1), and Privacy (P1–P8) are selected based on your commitments to customers.

What is the difference between Trust Service Criteria and Trust Service Principles?

The same thing. In 2017, the AICPA renamed "Trust Service Principles" to "Trust Service Criteria" to better describe their function as evaluation standards rather than aspirational principles. Resources predating 2017 use the older term.

Can I add criteria to a report after my first audit?

Yes. Adding criteria in subsequent periods is common. Each new category requires controls, documentation, and evidence specific to that category. Many organizations add Availability in year two after completing a Security-only Type I.

How long does preparation take for a full five-criteria SOC 2?

The 2017 TSC document does not specify a preparation timeline — that depends entirely on your starting control maturity. Organizations with existing ISO 27001 or NIST CSF programs may close gaps in three to four months. Organizations starting from scratch, with no documented risk register, no access review history, and no incident response runbook, should expect six to twelve months of preparation before a Type II observation period can begin. The AICPA sets no minimum; auditors look for evidence that controls were operating consistently, and a two-month history of any control is rarely sufficient for a credible Type II opinion.

Which criteria do enterprise customers most commonly require?

Security and Availability together are the most frequently requested combination in vendor security questionnaires targeting SaaS providers. Confidentiality is commonly the next addition, particularly in regulated industries. Processing Integrity and Privacy are requested less frequently but appear with increasing regularity in fintech and consumer-product procurement.

How do the Common Criteria relate to the category-specific criteria?

CC1–CC9 (the Common Criteria) apply to every SOC 2 report. A1, PI1, C1, and P1–P8 are additional criteria that apply only when the corresponding category is in scope. Category-specific criteria often reference and build on CC6 controls, so the evidence for CC6 partial-satisfies requirements in A1, C1, and P7.

Sources

1. AICPA Assurance Services Executive Committee. 2017 Trust Services Criteria (With Revised Points of Focus — 2022). Published September 30, 2023. Accessed 2026-05-12. https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
2. AICPA. SOC 2 — System and Organization Controls Suite of Services. Accessed 2026-05-12. https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
3. ISO. ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection. https://www.iso.org/standard/27001
4. NIST. Cybersecurity Framework 2.0. https://www.nist.gov/cyberframework
5. HHS Office for Civil Rights. HIPAA Security Rule — 45 CFR Part 164 Subpart C. https://www.hhs.gov/hipaa/for-professionals/security/index.html

Last reviewed: 2026-06-22. This article was prepared by the Security Compliance Guide Editorial Team and verified against primary AICPA source documentation. We are not licensed auditors, attorneys, or compliance consultants. This article does not constitute audit advice. For binding scoping and control decisions, consult a qualified CPA firm or accredited SOC 2 auditor. See our editorial standards for full sourcing and review rules.