The Trust Service Criteria (TSC) are a set of control benchmarks published by the American Institute of Certified Public Accountants (AICPA) that define what a SOC 2 audit evaluates. Every SOC 2 report — whether Type 1 or Type 2 — measures an organisation’s controls against one or more of these criteria. Understanding what each criterion covers, how they relate to one another, and which ones apply to your organisation is essential for scoping an audit correctly and building a control environment that satisfies both auditors and customers.
The TSC were originally known as the Trust Service Principles and were revised and renamed in the 2017 update to the AICPA’s Trust Services Criteria framework (TSP Section 100). This revision aligned the criteria more closely with the Committee of Sponsoring Organizations of the Treadway Commission (COSO) Internal Control — Integrated Framework, establishing a structure of criteria and supplementary “points of focus” that auditors use during evaluations.
There are five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Of these, only Security is mandatory in every SOC 2 engagement. The remaining four are selected based on the nature of the service being audited and the commitments the organisation has made to its customers.
Security (Common Criteria)
Security is the foundational criterion and the only one required in every SOC 2 audit. It is often referred to as the Common Criteria because its controls underpin all other criteria — any organisation pursuing Availability, Processing Integrity, Confidentiality, or Privacy must first satisfy the Security criterion.
The Security criterion addresses whether information and systems are protected against unauthorised access, unauthorised disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, or privacy of data. It is organised into nine control series, labelled CC1 through CC9, each addressing a distinct domain.
CC1 — Control Environment establishes the tone at the top. It covers governance structures, board oversight, management philosophy, organisational structure, and accountability for internal controls. Auditors evaluate whether leadership has defined responsibilities for control oversight and whether personnel understand their obligations.
CC2 — Communication and Information addresses how the organisation communicates internally and externally about control-related matters. This includes policies and procedures documentation, security awareness training, and the mechanisms used to report control failures or incidents.
CC3 — Risk Assessment requires the organisation to identify, analyse, and manage risks that could prevent it from achieving its objectives. This includes maintaining a risk register, conducting periodic risk assessments, and evaluating the potential for fraud.
CC4 — Monitoring Activities covers how the organisation evaluates whether its controls are functioning effectively over time. This includes ongoing monitoring, separate evaluations, and the remediation of identified deficiencies.
CC5 — Control Activities addresses the policies and procedures that ensure management directives are carried out. This series covers authorisation processes, segregation of duties, and the design and implementation of controls over technology infrastructure.
CC6 — Logical and Physical Access Controls is one of the most heavily scrutinised areas. It covers user authentication, role-based access control, access provisioning and de-provisioning, physical security of data centres, encryption of data at rest and in transit, and protection against malware.
CC7 — System Operations addresses how the organisation detects and responds to anomalies, security events, and incidents. This includes intrusion detection systems, vulnerability management, incident response plans, and the processes for escalating and resolving security events.
CC8 — Change Management covers the controls around modifying infrastructure, software, and system configurations. Auditors look for documented change request processes, testing and approval procedures, separation of development and production environments, and rollback capabilities.
CC9 — Risk Mitigation addresses how the organisation manages risk through business practices such as vendor management, insurance, and contractual protections. This includes evaluating third-party service providers and ensuring that outsourced functions do not introduce unacceptable risk.
In practice, implementing the Security criterion requires controls such as multi-factor authentication, endpoint detection and response, centralised logging and monitoring, formal access review processes, documented incident response procedures, and regular vulnerability scanning and penetration testing.
Availability
The Availability criterion evaluates whether the system is operational and usable as committed or agreed upon. This criterion is particularly relevant for organisations that provide infrastructure services, cloud platforms, or any service where uptime directly affects customers.
Availability does not prescribe a specific uptime percentage. Instead, it measures whether the organisation has defined availability commitments (typically through service level agreements) and has implemented controls to meet those commitments. The key areas covered include:
Performance monitoring and capacity planning. Organisations must demonstrate that they monitor system performance against defined baselines and plan for capacity needs before they become critical. This includes monitoring CPU utilisation, memory, network throughput, and storage capacity.
Disaster recovery and business continuity. The Availability criterion requires documented disaster recovery plans that are tested regularly. Auditors evaluate recovery time objectives (RTOs) and recovery point objectives (RPOs), backup procedures, data replication strategies, and the results of disaster recovery tests.
Incident management for availability events. Beyond security incidents, organisations must have processes for detecting, responding to, and communicating about availability disruptions. This includes alerting mechanisms, escalation procedures, and post-incident reviews.
Environmental protections. For organisations that manage their own infrastructure, this includes physical controls such as redundant power supplies, cooling systems, fire suppression, and geographic distribution of data centres.
Common implementation patterns for Availability include automated scaling policies, multi-region deployments, real-time uptime dashboards, regular failover testing, and published status pages that communicate service health to customers.
Processing Integrity
Processing Integrity addresses whether system processing is complete, valid, accurate, timely, and authorised to meet the organisation’s objectives. This criterion is most relevant for organisations that process transactions, perform calculations, aggregate data, or transform information on behalf of their customers.
The distinction between Processing Integrity and Security is important. Security protects data from unauthorised access and modification. Processing Integrity ensures that authorised processing produces correct results. A system can be fully secure yet still produce inaccurate outputs due to software defects, configuration errors, or incomplete data handling.
The criterion covers several dimensions:
Completeness. All transactions that should be processed are processed, and none are duplicated or omitted. This requires input validation, batch reconciliation, and transaction logging.
Validity. Only authorised and legitimate transactions are processed. This involves business rule validation, authorisation checks, and rejection of malformed inputs.
Accuracy. Processing produces the correct result. This includes calculation verification, rounding rules, currency handling, and data transformation logic.
Timeliness. Processing occurs within the expected timeframe. This covers batch processing windows, real-time processing latency requirements, and escalation procedures when processing delays occur.
Authorisation. Processing is initiated and approved by appropriate parties. This includes workflow approvals, segregation of duties between those who initiate and those who approve transactions, and audit trails.
Organisations typically implement Processing Integrity controls through automated data validation rules, reconciliation processes between source and target systems, error queues with manual review workflows, checksums or hash verification for data in transit, and comprehensive audit logging of all processing activities.
Confidentiality
The Confidentiality criterion addresses how an organisation protects information that is designated as confidential. This differs from Security in scope: while Security protects all information and systems broadly, Confidentiality focuses specifically on data that has been classified as confidential based on contractual, legal, or organisational requirements.
Examples of confidential information include intellectual property, financial data shared under non-disclosure agreements, business plans, source code, pricing models, and any data that the organisation or its customers have explicitly designated as requiring restricted access.
The criterion covers the full lifecycle of confidential information:
Identification and classification. Organisations must define what constitutes confidential information and maintain a data classification scheme. This typically involves categories such as public, internal, confidential, and restricted, with corresponding handling requirements for each.
Access restrictions. Confidential information must be accessible only to authorised individuals who have a legitimate business need. This involves role-based access controls, need-to-know principles, and regular access reviews to ensure that permissions remain appropriate as roles change.
Encryption. Data classified as confidential must be protected through encryption both at rest and in transit. This includes database encryption, file-level encryption for stored documents, TLS for data in transit, and key management procedures.
Retention and disposal. Organisations must define retention periods for confidential information and ensure that data is securely disposed of when it is no longer needed. Disposal methods must render the data unrecoverable — this includes cryptographic erasure, secure deletion, and physical destruction of media where applicable.
Implementation patterns for Confidentiality include data loss prevention (DLP) tools, document classification labels, encrypted storage solutions, secure file transfer mechanisms, and automated retention and disposal policies enforced through the organisation’s information management systems.
Privacy
The Privacy criterion governs how personal information is collected, used, retained, disclosed, and disposed of. It is the most prescriptive of the five criteria and is structured around a set of privacy principles that closely mirror requirements found in data protection regulations such as the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and other privacy legislation.
The Privacy criterion is distinct from the other four criteria in an important way: its scope is limited to personal information — data that can identify an individual, such as names, email addresses, national identification numbers, health records, and financial details. The other criteria apply to all data and systems regardless of whether personal information is involved.
The key areas addressed by the Privacy criterion include:
Notice. The organisation must inform individuals about its privacy practices, including what personal information is collected, the purposes for collection, how the information will be used, and with whom it may be shared. This is typically communicated through a privacy policy or privacy notice.
Choice and consent. Individuals must be given choices about how their personal information is collected, used, and disclosed. Where required by law, explicit consent must be obtained before processing.
Collection. Personal information must be collected only for the purposes identified in the privacy notice, and collection must be limited to what is necessary for those purposes — a principle commonly referred to as data minimisation.
Use, retention, and disposal. Personal information must be used only for the purposes stated in the privacy notice, retained only for as long as necessary to fulfil those purposes, and disposed of securely when no longer needed.
Access and correction. Individuals must have the ability to access their personal information held by the organisation and request corrections to inaccurate data.
Disclosure to third parties. When personal information is shared with third parties, the organisation must ensure that those parties are bound by appropriate contractual protections and that individuals are informed about such disclosures.
Security of personal information. This overlaps with the Security criterion and requires that personal information is protected against unauthorised access, use, and disclosure through technical and organisational measures.
The overlap between the Privacy criterion and GDPR is substantial. Both require lawful bases for processing, data minimisation, purpose limitation, individual rights (access, rectification, erasure), and accountability mechanisms. However, SOC 2 is a voluntary attestation framework, not a legal obligation. Satisfying the Privacy criterion demonstrates alignment with privacy best practices but does not constitute legal compliance with any specific regulation.
How to choose which criteria apply
Selecting the right criteria is a scoping decision that should be made before the audit engagement begins. The criteria you include determine the controls you must implement and evidence, so the decision has direct implications for cost, effort, and timeline.
A practical decision framework considers three factors:
Service type. The nature of your service is the strongest indicator. If you provide infrastructure or platform services, Availability is almost certainly relevant. If you process financial transactions or perform data transformations, Processing Integrity applies. If you store customer intellectual property or trade secrets, Confidentiality is appropriate. If you handle personal information, Privacy should be considered.
Customer commitments. Review your contracts, service level agreements, and marketing materials. If you have committed to specific uptime guarantees, Availability is in scope. If your contracts include confidentiality clauses about customer data handling, the Confidentiality criterion applies. Customer questionnaires and due diligence requests often reveal which criteria your customers expect.
Regulatory requirements. If your organisation or your customers operate in regulated industries — healthcare, financial services, government — certain criteria may be effectively mandatory even though the SOC 2 framework treats them as optional. Organisations subject to GDPR or CCPA often include the Privacy criterion to demonstrate alignment with regulatory expectations.
Most organisations begin with Security alone for their first audit. This approach allows the organisation to establish the foundational control environment without overextending. Additional criteria are typically added in subsequent audit cycles as the organisation matures and as customer demand requires.
Points of Focus
Each Trust Service Criterion is accompanied by a set of Points of Focus published by the AICPA. These are not additional requirements but rather clarifications that explain what the criterion intends to address. They guide both the organisation in designing controls and the auditor in evaluating them.
For example, under CC6 (Logical and Physical Access Controls), Points of Focus include considerations such as “the entity restricts logical access to information assets through the use of access control software and other mechanisms” and “the entity considers the potential for fraud when assessing risks to the achievement of objectives.” These points help organisations understand the level of specificity expected.
Points of Focus are not a checklist. An organisation does not need to address every Point of Focus individually. Instead, they represent the types of considerations that are relevant to each criterion. An auditor may determine that certain Points of Focus are not applicable to a particular organisation based on its size, complexity, or the nature of its services.
When designing controls, it is useful to review the Points of Focus for each criterion in scope and map them to specific policies, procedures, and technical controls within your environment. This mapping exercise helps identify gaps before the audit and ensures that control documentation addresses the areas auditors are most likely to examine.
Mapping criteria to controls
The relationship between criteria and controls is many-to-many. A single control may satisfy requirements across multiple criteria, and a single criterion will require multiple controls. Understanding this mapping is essential for building an efficient control environment that avoids duplication.
Consider a few practical examples:
An access review process — where managers review and confirm user access rights quarterly — addresses the Security criterion (CC6, logical access controls), the Confidentiality criterion (restricting access to confidential data), and potentially the Privacy criterion (limiting access to personal information).
An encrypted backup system with regular restoration testing addresses Security (CC7, protecting against data loss), Availability (disaster recovery preparedness), and Confidentiality (protecting classified data at rest).
A data processing reconciliation report that compares input records to output records after batch processing addresses Processing Integrity (completeness and accuracy of processing) while also supporting the Security criterion (CC4, monitoring activities).
This many-to-many mapping means that organisations should design controls with multiple criteria in mind from the outset. Retrofitting controls to cover additional criteria after implementation is more costly and often results in fragmented documentation.
A well-structured control environment organises controls by operational domain — access management, change management, incident response, data protection — rather than by individual criterion. Each control is then mapped to every criterion it supports, creating a matrix that auditors can review to confirm complete coverage.
Building a sustainable control environment
The Trust Service Criteria are not a one-time exercise. SOC 2 audits recur annually, and the controls you implement must operate continuously and produce evidence of their effectiveness over time. This is particularly true for Type 2 audits, which evaluate controls over a review period of three to twelve months.
Organisations that succeed with SOC 2 treat the Trust Service Criteria as an operational framework rather than a compliance project. They embed controls into daily workflows, automate evidence collection wherever possible, and assign clear ownership for each control area. They review their criteria selection annually, adding or removing criteria as their service offerings and customer expectations evolve.
The AICPA periodically updates the Trust Services Criteria framework. Organisations should monitor these updates and adjust their control environments accordingly. The most recent significant revision in 2017 aligned the criteria with the COSO framework, and subsequent clarifications have refined Points of Focus and addressed emerging risks such as cloud computing and remote work.
Understanding the Trust Service Criteria thoroughly — not just their definitions but their practical implications — is the foundation for an efficient, defensible, and sustainable SOC 2 programme.