What the SOC 2 Trust Services Criteria are
The Trust Services Criteria (TSC) are control criteria set by the AICPA's Assurance Services Executive Committee (ASEC). The current document, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus – 2022), presents them for use in attestation or consulting engagements to evaluate and report on controls over information and systems.
The criteria describe outcomes, not a required list of controls. The TSC contrasts itself with frameworks that mandate a specific set of controls: each organization sets its own objectives, assesses its own risks and chooses controls that meet the criteria.
In a SOC 2 examination, a CPA acting as the service auditor uses the applicable criteria as the benchmark. Under the AICPA's SOC 2 description criteria, the service auditor's opinion covers whether the system description is presented in accordance with the description criteria, whether controls were suitably designed to provide reasonable assurance that the organization's service commitments and system requirements would be achieved, and, in a Type 2 examination, whether they operated effectively.
The criteria align with the 17 principles of the COSO Internal Control – Integrated Framework (2013), with supplemental criteria for logical and physical access, system operations, change management and risk mitigation. The 2022 revision updated only the points of focus; the AICPA states it doesn't alter the criteria, which remain suitable for any trust services engagement.
The five Trust Services Criteria categories
The TSC groups its criteria into five categories. A SOC 2 report can cover one category or several, and for each category it covers, a complete set of criteria is the common criteria plus that category's own criteria.
| Category | What it addresses | Criteria used |
|---|---|---|
| Security | Information and systems are protected against unauthorized access, unauthorized disclosure and damage | Common criteria, CC1 to CC9 |
| Availability | Information and systems are available for operation and use to meet objectives | Common criteria plus A1.1 to A1.3 |
| Processing integrity | System processing is complete, valid, accurate, timely and authorized | Common criteria plus PI1.1 to PI1.5 |
| Confidentiality | Information designated as confidential is protected | Common criteria plus C1.1 and C1.2 |
| Privacy | Personal information is collected, used, retained, disclosed and disposed of to meet objectives | Common criteria plus the P1 to P8 groups |
Where the categories differ
Availability doesn't set a minimum performance level, and it doesn't address system functionality or usability; it addresses whether controls support access for operation, monitoring and maintenance. Confidentiality applies to any information designated as confidential, such as information a contract requires you to protect, while privacy applies only to personal information.
The privacy criteria are grouped by topic: notice, choice and consent, collection, use, retention and disposal, access, disclosure and notification, quality, and monitoring and enforcement.
The SOC 2 common criteria, CC1 to CC9
The common criteria are the core of every SOC 2 examination. CC1 to CC5 follow the five COSO components and contain its 17 principles; CC6 to CC9 are the supplemental criteria for logical and physical access, system operations, change management and risk mitigation.
- CC1 Control environment (CC1.1 to CC1.5): integrity and ethical values, board oversight, structure and authority, competence, and accountability.
- CC2 Information and communication (CC2.1 to CC2.3): quality information, internal communication and communication with external parties.
- CC3 Risk assessment (CC3.1 to CC3.4): objectives, identifying and analyzing risks, fraud risk, and significant changes.
- CC4 Monitoring activities (CC4.1 and CC4.2): ongoing and separate evaluations, and communicating deficiencies.
- CC5 Control activities (CC5.1 to CC5.3): selecting control activities, general controls over technology, and policies and procedures.
- CC6 Logical and physical access controls (CC6.1 to CC6.8): access security, credentials, access changes, physical access, asset disposal, outside threats, data transmission and malicious software.
- CC7 System operations (CC7.1 to CC7.5): detecting vulnerabilities and configuration changes, monitoring for anomalies, evaluating security events, responding to incidents and recovering from them.
- CC8 Change management (CC8.1): authorizing, designing, testing, approving and implementing changes to infrastructure, data, software and procedures.
- CC9 Risk mitigation (CC9.1 and CC9.2): mitigating risks from business disruption, and assessing and managing risks from vendors and business partners.
What this means for a security-only report
Two consequences surprise teams scoping their first report. Vendor management sits inside the common criteria at CC9.2, so a report covering security alone still looks at how you assess and manage vendors and business partners.
Incident response sits at CC7.3 to CC7.5, so a defined, working process for evaluating security events, responding to incidents and recovering matters even without the availability category.
Points of focus: guidance, not a checklist
Under each criterion, the TSC lists points of focus. Following the COSO framework, it describes them as important characteristics of the criteria that can help management design and operate controls, and help management and the service auditor evaluate them.
They aren't a checklist. The TSC says some points of focus may not be suitable or relevant to an entity, that management may customize them or consider other characteristics, and that using the criteria doesn't require an assessment of whether each point of focus is addressed. When an organization commits to meeting a process or control framework, that framework's requirements are likely to be treated as additional points of focus.
Points of focus still help show what a service auditor may consider when evaluating a criterion. Two examples from the 2022 revision:
- CC4.1 (monitoring activities) has a point of focus on using different types of ongoing and separate evaluations, naming penetration testing, vulnerability scans, internal audit assessments and third-party assessments among the examples.
- CC7.1 (system operations) includes “Conducts Vulnerability Scans”: infrastructure and software scans on a periodic basis and after significant changes, with identified deficiencies remediated in a timely manner.
Choosing categories for your SOC 2 report
Start from what you have promised. The AICPA's description criteria say a service organization's service commitments and system requirements influence which categories it selects, giving the example of a cloud service provider that includes availability because of its importance to a broad range of users.
Service commitments can be made through contracts, service-level agreements and published policies such as a privacy policy. System requirements are the specifications the organization sets for how its system must function to meet those commitments, comply with laws and regulations, and achieve its other objectives. Questions that usually settle the choice:
- Do contracts or service-level agreements promise uptime or recovery? Consider availability.
- Is the accuracy and completeness of processing the product, as in payroll, billing or claims? Consider processing integrity.
- Do contracts designate customer information as confidential, such as financial data or source code? Consider confidentiality.
- Does the service collect, use or disclose personal information about individuals? Consider privacy.
- Which categories do your customers' security questionnaires and procurement teams actually ask for?
Scope trade-offs
Each added category brings more criteria, more evidence and more examination effort, so include what customers need and what you can operate reliably. Management is responsible for the system description, and the scope of the report is settled with the CPA firm that performs the examination.
Mapping the criteria to your controls
Because the TSC describes outcomes, you choose the controls. One control often supports several criteria, and one criterion is usually met by several controls working together. The AICPA also publishes mappings between the 2017 criteria and other frameworks, which help organizations that report against more than one.
A workable mapping records, for each criterion, the controls that address it, who owns each control, and the evidence that shows it operated. The points of focus listed under each criterion are a useful prompt when checking for gaps.
- List the categories in scope and every criterion that applies, starting with CC1 to CC9.
- For each criterion, record the controls that meet it, including controls operated by vendors you rely on.
- Name an owner and the evidence each control produces: tickets, logs, reviews, approvals and reports.
- Mark gaps where no control or no evidence exists, and close them before any review period starts.
- If you also follow ISO/IEC 27001, the NIST Cybersecurity Framework or HIPAA, map each control once and reuse the evidence.
Is a new version of the Trust Services Criteria coming?
As of September 27, 2026, the criteria the AICPA publishes are the 2017 Trust Services Criteria with revised points of focus from 2022, and no revised set of criteria has been issued. Reports of possible future changes are not the same as a published standard.
The TSC notes that ASEC followed due process, including exposure of the criteria for public comment, when it developed them. Until the AICPA publishes a revision, build to the current criteria and watch the AICPA's trust services and SOC pages for announcements.