Choosing Trust Services Criteria - which ones your organisation actually needs?

Choosing Trust Services Criteria - which ones your organisation actually needs?

Not every organisation needs the full set of Trust Services Criteria under SOC 2. In practice, your selection should be driven by what your system actually does, what data you process, and the commitments you make to customers in contracts, SLAs, and product documentation. One thing, however, is non-negotiable: Security is always included in the scope of SOC 2. The remaining categories should be added deliberately, based on risk exposure and your business model.

This decision is not about optics. It directly affects the scope of controls, the volume of evidence you must maintain, the level of process maturity required, and the responsibilities assigned across teams. As a result, the choice of criteria should follow from a structured assessment of your system and obligations, rather than an attempt to broaden the report for appearance's sake.

What the Trust Services Criteria are and why the selection matters?

The Trust Services Criteria consist of five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Each addresses a distinct dimension of system reliability and governance. At the same time, all of them focus on how controls are designed and whether they operate effectively in practice.

Security forms the foundation of the framework. It covers protection against unauthorised access, misuse, and improper modification of data. This includes identity and access management, monitoring, incident response, and change management controls.

The remaining four categories are optional. Their inclusion depends on whether they are relevant to the nature of your services and your contractual commitments. Therefore, selecting TSC should be treated as a strategic risk management decision, not a procedural formality.

Security as the baseline

Every SOC 2 report includes the Security category. This means the organisation must demonstrate that its systems are safeguarded against threats and that security controls are appropriately designed and functioning as intended.

Importantly, Security extends beyond the IT function. It encompasses governance, employee access provisioning and deprovisioning, security awareness training, internal policies, and executive oversight. In other words, the scope of Security influences the entire organisation, not just its technical infrastructure.

Selecting criteria based on service commitments

A practical and defensible approach begins with analysing the commitments your organisation makes to customers. First, clearly define the system scope covered by SOC 2. Then review key documents such as SLAs, master service agreements, DPAs, terms of service, and product descriptions.

If you contractually commit to a defined level of uptime, the Availabilitycategory naturally becomes relevant. Similarly, if customers depend on the accuracy of processing results, Processing Integrity may be appropriate. Meanwhile, if you process personal data, Privacy should be considered. In contrast, where your service involves storing or handling sensitive business information, Confidentiality may be necessary.

By aligning criteria with documented commitments, you ensure consistency between what you promise and what your report demonstrates.

Availability - when uptime is part of your value proposition

The Availability category focuses on whether systems operate as committed. This typically includes business continuity planning, disaster recovery procedures, performance monitoring, capacity management, and incident response related to service disruption.

If your contracts specify availability targets or if downtime would materially impact your customers, including this category is justified. Conversely, if availability is not a defined commitment, adding it may unnecessarily expand the control environment without delivering meaningful value.

Processing integrity - when output accuracy is critical

Processing Integrity addresses whether systems process data in a complete, valid, accurate, timely, and authorised manner. This is particularly relevant for billing platforms, financial systems, transactional services, or any environment where processing outputs directly affect customers' operations.

It is important to distinguish this from the accuracy of user-submitted data. The focus here is on whether the system performs processing as designed and whether controls detect and correct processing errors. In other words, the emphasis is on operational reliability rather than data truthfulness.

Confidentiality - protecting sensitive information

Confidentiality applies to information classified as confidential, which may or may not include personal data. Examples include proprietary documents, financial records, customer content, and information protected under non-disclosure agreements.

Including this category requires demonstrating effective data classification, access restrictions, encryption where appropriate, defined retention policies, and secure disposal practices. If your business model relies on safeguarding client-sensitive materials, omitting Confidentiality could raise legitimate concerns among report users.

Privacy - managing the personal data lifecycle

Privacy covers the full lifecycle of personal data, from collection and use to storage, disclosure, and deletion. It requires alignment with the privacy notices provided to individuals and mechanisms that enable data subject rights.

If your organisation processes personal data and aims to demonstrate mature governance in this area, including Privacy may be appropriate. In practice, this often entails closer coordination between legal, compliance, and operational teams, as well as clearly documented procedures for handling data subject requests and retention obligations.

Privacy vs. Confidentiality - understanding the distinction

Although both categories relate to information protection, their scope differs significantly. Privacy focuses specifically on personal data and compliance with defined privacy principles. Confidentiality, on the other hand, concerns protecting sensitive information regardless of whether it qualifies as personal data.

Recognising this distinction helps prevent over-scoping and ensures that each category is included for a clear and defensible reason.

Making a defensible decision

Selecting the appropriate Trust Services Criteria should be the outcome of a structured assessment of system scope, data classification, and contractual commitments. Begin by clearly defining the boundaries of the system. Next, categorise the data it processes and analyse stakeholder expectations.

Only then should you evaluate how expanding the scope affects internal controls, governance structures, and documentation requirements. Each additional category increases the number of controls to maintain and the breadth of evidence to produce. As a result, the decision should balance risk mitigation with operational feasibility.

Conclusion

The selection of Trust Services Criteria should reflect your business model and the commitments you make to customers. Security forms the foundation of every SOC 2 report, while Availability, Processing Integrity, Confidentiality, and Privacy should be included only when justified by the nature of your services and the data you handle.

When selected thoughtfully, these criteria enhance the credibility of your report and strengthen your overall risk management posture. Rather than serving as a formal checkbox exercise, SOC 2 then becomes a practical framework for demonstrating trust and operational discipline.