There are five SOC 2 Trust Services Criteria categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the baseline for every SOC 2 scope; the other four are selected when they are relevant to the service, commitments, data, and stakeholder needs. The hard part is not memorising the five names. Choosing a defensible scope. And understanding what that choice means for controls, owners, and evidence.
What are the SOC 2 Trust Services Criteria?
The Trust Services Criteria are the framework used in SOC 2 examinations to evaluate controls over information and systems used to provide products or services. The current AICPA resource is the 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, with points of focus revised in 2022 by the AICPA Assurance Services Executive Committee (AICPA & CIMA).
Strictly, Security, Availability, Processing Integrity, Confidentiality, and Privacy are Trust Services categories containing criteria. That wording is a little fussy. In practice, many teams and buyers refer to them collectively as the “five SOC 2 Trust Services Criteria.”
For SOC 2 scoping, Security is the required baseline: every SOC 2 scope includes the common criteria associated with Security. Availability, Processing Integrity, Confidentiality, and Privacy are additional categories selected when relevant to the in-scope service, principal commitments, system requirements, and customer information needs (Schellman).
A SOC 2 is an examination-level attestation engagement performed by a licensed CPA, resulting in a SOC 2 report. It should not be described as a certification (Journal of Accountancy).
The five Trust Services Criteria, explained in engineering terms
Security concerns protection of information and systems against unauthorised access, unauthorised disclosure, and damage that could compromise the organisation’s objectives. For engineering teams, this usually maps to areas such as identity and access management, secure change management, vulnerability handling, incident response, logging, monitoring, and infrastructure safeguards.
Availability concerns whether systems are available for operation and use as committed or agreed. This is most relevant when the service has meaningful uptime, resilience, recovery, or accessibility commitments. Availability does not set a universal uptime target by itself; it depends on what the organisation has committed to provide.
Processing Integrity concerns whether system processing is complete, valid, accurate, timely, and authorised. This is not a blanket statement that every piece of data in the business is correct. It applies to the processing responsibilities of the in-scope system, such as transaction handling, workflow approvals, calculations, data transformations, imports, exports, or reconciliations.
Confidentiality concerns protection of information designated as confidential. That may include customer data, business-sensitive information, trade secrets, intellectual property, or other information the organisation has committed to protect as confidential.
Privacy concerns the collection, use, retention, disclosure, and disposal of personal information in line with the organisation’s objectives and commitments. The practical thing to remember is that Confidentiality is about protecting designated confidential information, while Privacy is about how personal information is handled across its lifecycle. Personal information may also be confidential, but the two categories are not the same (AICPA).
Criteria vs controls vs evidence
Criteria define the trust categories included in the SOC 2 scope. Controls are the organisation-specific processes, technical safeguards, and governance activities used to address those criteria, evidence is the support an auditor tests to evaluate whether those controls are suitably designed and, for Type 2, operating effectively over the examination period (AICPA & CIMA).
A simple way to think about the relationship is:
For example, Security may lead to an access control area, which may include a quarterly user access review, supported by review records, approvals, and remediation tickets. Availability may lead to backup and recovery controls, supported by backup configuration records, restore test evidence, or incident records. These are examples, not universal SOC 2 requirements.
One selected category usually maps to multiple controls. One control may also support more than one category or framework. For instance, centralised identity management could support Security, Confidentiality, and other compliance requirements if the control is designed and evidenced appropriately.
Engineering teams often feel SOC 2 most directly at the evidence layer. The audit question becomes: can the team show, with reliable artifacts, that the control actually operated? That may involve change tickets, access review records, identity-provider settings, deployment approvals, incident tickets, monitoring alerts, backup test records, encryption configuration evidence, or privacy workflow records, depending on the selected scope and control design.
How to decide which optional criteria belong in your SOC 2 scope
Choose optional criteria deliberately. The decision should reflect what the in-scope service does, what the organisation has committed to customers, what data it handles, and what stakeholders need from the report. That decision should usually be based on inputs like contracts, SLAs, security questionnaires, direct customer requests, product functionality, data classifications, privacy commitments, and auditor input.
Consider Availability when customers rely on the service being available for operation and use, and those availability commitments are material to the service. Usually exclude it when there is no identified uptime, resilience, recovery, or accessibility commitment that needs to be represented in the SOC 2 scope.
Consider Confidentiality when the service stores, processes, or transmits information that customers or the business designate as confidential. Usually exclude it when no in-scope information has been designated confidential and Security controls sufficiently address the relevant unauthorised access risks for the report’s purpose.
Consider Processing Integrity when the system performs processing where completeness, validity, accuracy, timeliness, or authorisation materially affects customer outcomes. Examples include financial calculations, transaction workflows, data transformations, automated approvals, or critical imports and exports. Usually exclude it when the product primarily stores, displays, or transmits information without material processing commitments.
Consider Privacy when the organisation’s commitments include the collection, use, retention, disclosure, or disposal of personal information. Usually exclude it when personal information handling is not material to the in-scope service or commitments. Privacy laws and regulatory obligations may inform the risk analysis, but including Privacy in SOC 2 does not by itself prove legal compliance.
Do not add optional categories because they sound more mature. Adding a category adds applicable criteria to the examination and can require additional controls, evidence, testing, ownership, and maintenance where existing controls do not already address them. A broader scope may be appropriate, but it should have a clear business, contractual, system, data, or stakeholder rationale.
SOC 2 TSC scoping and evidence matrix
The following matrix is editorial guidance for scoping discussions. Example controls, evidence, and owners are illustrative, not auditor-prescribed requirements. Validate the final scope, control design, and evidence sufficiency with your service auditor.
| Criterion | Include when | Usually exclude when | Example control areas | Example evidence | Likely owner |
|---|---|---|---|---|---|
| Security | Always included as the SOC 2 baseline. | Not applicable for SOC 2; Security is the required baseline category. | Access control, change management, incident response, vulnerability management, monitoring, vendor risk, policy governance. | Access review records, MFA/SSO configuration evidence, change tickets, incident records, vulnerability remediation tickets, policy acknowledgements. | Security, Engineering, Infrastructure/DevOps, GRC/Compliance, leadership. |
| Availability | Material commitments exist around system availability, uptime, resilience, recovery, or operation and use. | No identified availability commitment or stakeholder need justifies adding the category. | Monitoring, alerting, incident response, backup and restore, capacity management, disaster recovery. | Availability reports, monitoring alerts, incident postmortems, backup job records, restore test evidence, DR exercise records. | Infrastructure/DevOps, SRE, Engineering, Operations, leadership. |
| Processing Integrity | The service performs material processing where completeness, validity, accuracy, timeliness, or authorisation affects customer outcomes. | The service has no material processing responsibility beyond basic storage, hosting, or display. | Input validation, workflow approvals, reconciliation, job monitoring, exception handling, output review. | Processing validation records, reconciliation logs, failed-job alerts, approval records, exception queues, test records for critical workflows. | Engineering, Product, Operations, Data/Platform teams, GRC/Compliance. |
| Confidentiality | In-scope information is designated confidential by customers, the business, contracts, or data classification. | No in-scope information has been designated confidential and no stakeholder need supports adding the category. | Data classification, encryption, access restrictions, secrets management, secure data transfer, data disposal. | Encryption configuration screenshots or logs, access control records, data classification records, key management evidence, secure deletion records. | Security, Engineering, Infrastructure/DevOps, Legal, GRC/Compliance. |
| Privacy | Personal information lifecycle commitments are material: collection, use, retention, disclosure, or disposal. | Personal information handling is not material to the in-scope service or commitments. | Privacy notice alignment, consent or preference handling, retention, deletion, disclosure controls, privacy request workflows. | Retention records, privacy request tickets, deletion workflow evidence, consent/preference records, data inventory excerpts. | Legal/Privacy, Product, Engineering, Operations, GRC/Compliance. |
What engineering teams should do after choosing criteria
After selecting the proposed categories, document the rationale for each optional criterion. Record the service boundaries, customer commitments, system responsibilities, data types, and stakeholder needs considered. For exclusions, write down why the category is not currently relevant rather than leaving the decision implicit.
Then validate the proposed scope with leadership, customer-facing teams, and the service auditor or advisory partner. Sales or customer success may know about contract terms or questionnaire expectations that engineering has not seen. Legal or privacy teams may know about commitments affecting personal information. The auditor can help confirm whether the proposed scope aligns with the system description and examination objectives. The annoying part is that some of this sits outside engineering.
Next, map each selected category to control areas and identify evidence sources already produced by engineering systems. Prefer evidence that reflects normal operations: identity-provider logs, ticketing workflows, CI/CD approvals, monitoring systems, incident tools, backup platforms, and privacy request systems. One-off audit folders are harder to maintain and can drift from how production systems actually operate.
Assign accountable owners for both control operation and evidence retention. A control without an owner becomes an audit surprise later, especially if it operates periodically. For a Type 1 examination, controls are evaluated as of a specified date. For a Type 2 examination, operating effectiveness is also evaluated over a specified period, so teams need to retain evidence showing recurring controls operated during that period and can support the auditor’s selected tests (AICPA & CIMA; Schellman).
For teams that have chosen their SOC 2 scope, Ciphrix can help operationalise control ownership and ongoing evidence collection across engineering systems. The goal is to make compliance reflect how production systems actually operate, rather than rebuilding evidence manually for each audit.
Choose the criteria first, then design the evidence plan around that scope. A focused SOC 2 report is easier to explain, operate, and maintain than a broad scope chosen without a clear reason, at least for most teams.