The five SOC 2 control categories used to evaluate a service organisation's security posture: security, availability, processing integrity, confidentiality, and privacy. They translate broad assurance goals into a testable control framework that auditors can assess against real evidence.
Expanded Definition
Trust Service Criteria are the service organisation evaluation criteria used in SOC 2 reports to show whether controls are designed and operating effectively across security, availability, processing integrity, confidentiality, and privacy. In practice, they turn high-level assurance expectations into evidence-based control objectives that auditors can test. The criteria are not a substitute for a full security programme; they are the audit lens applied to it.
In NHI and Agentic AI environments, the criteria matter because machine identities, service account, tokens, and APIs often carry the access that makes a platform operational. That means control evidence must cover provisioning, rotation, revocation, logging, and oversight, not just human user access. Guidance varies across vendors and audit firms on how far to extend testing into automated workflows, so organisations should treat SOC 2 scoping as a governance decision, not a checkbox exercise. A useful external reference point is the NIST Cybersecurity Framework 2.0, which helps translate assurance goals into operational outcomes.
The most common misapplication is treating Trust Service Criteria as a one-time compliance label, which occurs when teams gather evidence for the audit period but fail to maintain continuous control operation.
Examples and Use Cases
Implementing Trust Service Criteria rigorously often introduces documentation and monitoring overhead, requiring organisations to weigh audit readiness against engineering speed.
- A SaaS provider maps service account creation, secret storage, and rotation to the security criterion so that auditor samples can show how non-human access is governed end to end, consistent with the lifecycle risks described in the Ultimate Guide to NHIs.
- An internal platform team documents how deployment pipelines preserve processing integrity by limiting who can approve changes, how builds are signed, and how API credentials are issued and revoked.
- A customer data processor demonstrates confidentiality controls by separating production tokens from developer access and proving that secrets are not stored in source code, a pattern repeatedly called out in NHI guidance and in zero-trust-aligned identity governance.
- A multi-tenant service uses availability evidence to show that access to monitoring, failover tooling, and break-glass credentials is controlled and recoverable during incidents.
- A healthcare vendor aligns privacy evidence with data classification, showing that NHI-enabled automation only touches regulated data under documented purpose limits and review.
Why It Matters in NHI Security
Trust Service Criteria matter because NHI failures rarely stay isolated. A leaked API key, overly broad service account, or unrevoked token can undermine the security criterion, distort processing integrity, and expose confidentiality obligations in a single incident. NHI Mgmt Group research shows that 80% of identity breaches involved compromised non-human identities, which is exactly the kind of evidence auditors and customers now expect organisations to account for in a SOC 2 review. The practical lesson is that trust is not established by policy language alone; it is established by demonstrable control operation over machine identities.
For teams working through assurance mapping, SOC 2 often overlaps with broader security governance concepts in the NIST Cybersecurity Framework 2.0, especially where identity, logging, and access control evidence must be sustained over time. Organisations typically encounter the need to prove Trust Service Criteria only after a customer security review, incident, or audit finding exposes gaps in secret handling, access review cadence, or incident traceability, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Access control evidence underpins SOC 2 security and confidentiality criteria. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret management failures commonly surface as SOC 2 evidence gaps. |
| NIST CSF 2.0 | DE.CM-8 | Continuous monitoring supports the ongoing evidence SOC 2 expects. |
Collect identity and pipeline telemetry to prove controls are operating throughout the audit period.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
