Trust Service Categories are the control areas used in a SOC 2 report. They define the topics an organisation may be assessed on, with security required and the other categories chosen based on customer commitments, contractual needs, and the nature of the service being provided.
What Trust Service Categories Are
trust service Categories are the assessment areas used in a SOC 2 report. They provide the structure for what an organisation can be evaluated against, starting with Security and optionally extending to Availability, Confidentiality, Processing Integrity, and Privacy depending on the service and commitments made.
They matter because they define the scope of assurance, not a universal checklist. A SOC 2 engagement is built around the services and obligations a provider says it will meet, so the selected categories should reflect the actual trust promises being made to customers.
The Five Trust Service Categories
The five categories are commonly treated as the backbone of SOC 2 reporting. Security is the required baseline category, while the others are selected when they are relevant to the service, contractual promises, or the data handled.
- Security: protection against unauthorised access and other core control failures.
- Availability: the system’s ability to remain usable and resilient as committed.
- Confidentiality: protection of information that must be kept restricted.
- Processing Integrity: whether system processing is complete, valid, accurate, timely, and authorised.
- Privacy: how personal information is collected, used, retained, disclosed, and disposed of.
That structure is why a SOC 2 report is not simply “passed” or “failed” in the abstract. It is a statement about which trust attributes were in scope and how controls were designed and operated against those attributes.
How the Categories Shape a SOC 2 Report
The categories drive both the control narrative and the evidence that will be examined. A report scoped only to Security can still be highly meaningful, but it says less about uptime commitments, data handling promises, or the correctness of business processing than a broader scope would.
For buyers and assessors, the practical question is whether the selected categories match the risk and the service promise. A vendor handling sensitive customer data may need Confidentiality, while a service with strong uptime commitments may also need Availability. The categories chosen should line up with what customers are relying on, not just what is easiest to present.
For a concise definition of the underlying trust framework, the SOC 2 Trust Services Criteria (AICPA) remain the primary reference point, and the broader control environment is often mapped alongside the NIST SP 800-53 Rev 5 Security and Privacy Controls when organisations want a more detailed control catalogue.
Why Trust Service Categories Matter in Practice
The categories are a governance tool as much as an audit structure. They help teams decide what assurance they are willing to stand behind, what evidence they must collect, and where customer commitments create a control obligation.
They also shape buyer expectations. A SOC 2 report that includes only Security should not be read as equivalent to one that also covers Privacy or Availability, because the assurance boundaries are different. That distinction is often what makes the report useful in procurement, vendor review, and third-party risk management.
For organisations operating in cloud-heavy environments, the categories often align with broader trust expectations in guidance such as NIST Cybersecurity Framework 2.0 and can be compared with cloud assurance models like NIST Privacy Framework when privacy obligations are central to the service promise.
Risk and Threat Considerations
The main risk is category mismatch: an organisation can present a credible SOC 2 report while still leaving material promises outside the scope. That creates assurance gaps for customers who assume the report covers more than it actually does.
Failure mechanism: the service scope, contractual commitment, or data-handling reality is broader than the chosen trust service categories, so controls are assessed against the wrong trust boundary.
Impact: buyers may overestimate assurance, miss residual risk in unavailable, confidential, or privacy-sensitive workflows, and discover control gaps only after an incident, dispute, or failed review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while SOC 2 (AICPA) and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SOC 2 (AICPA) | CC6.1 — Logical Access Security Software, Infrastructure, and Architectures | SOC 2 trust categories define the assurance scope that CC6.1 helps secure. |
| Recommendation — Align the selected trust categories to the specific controls that protect the assessed service boundaries. | ||
| NIST CSF 2.0 | GV.OC-03 — Mission, Objectives, and Stakeholder Expectations | Trust categories reflect stakeholder commitments and the scope of services being assured. |
| Recommendation — Document which customer commitments each selected category is intended to assure. | ||
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | Trust category selection is driven by contractual and service commitments that shape assurance scope. |
| Recommendation — Map contractual trust promises to the categories included in the SOC 2 scope. | ||
| NIST SP 800-53 Rev 5 | CA-2 — Control Assessments | SOC 2 category scoping determines what controls are assessed and evidenced. |
| Recommendation — Assess controls only for the trust categories included in the report scope. | ||
Practitioner Guidance
Governance implication: choose the categories from the service promise outward, not from the audit convenience inward. If the organisation commits to uptime, sensitive data handling, or correctness of processing, those promises should be reflected in the categories selected and in the evidence plan that supports them.
Common misunderstanding: Security is required, but it is not a proxy for every other trust expectation. A narrow SOC 2 scope may still be valid, but it should be communicated as a narrow scope so stakeholders do not infer coverage that was never assessed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
