TL;DR: SOC 2 trust services criteria require organisations to prove their access controls, reviews, and data-handling processes are effective across security, confidentiality, privacy, availability, and processing integrity, according to Zluri. The deeper issue is that audit readiness still fails when identity governance is treated as a checklist instead of a lifecycle discipline across human and non-human access.
NHIMG editorial — based on content published by Zluri: Access Management SOC 2 Trust Services Criteria: Implementing Effective Controls
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: How should teams prepare access controls for SOC 2 audits?
A: Start by mapping each sensitive system to a control owner, an access rule, and a review cadence.
Q: Why do access reviews often fail SOC 2 governance tests?
A: They fail when organisations stop at review completion and do not close the loop on remediation.
Q: How can organisations handle confidentiality and privacy controls together?
A: Treat them as related but separate obligations.
Practitioner guidance
- Map SOC 2 criteria to identity owners Assign each security, confidentiality, privacy, and availability control to a named owner, review cadence, and evidence source so the audit trail is complete before testing begins.
- Include machine identities in access reviews Add service accounts, API keys, and SaaS app tokens to the same review process used for human users, then require documented revocation for any unused or excessive entitlement.
- Tie disposal to offboarding Link data retention, user deprovisioning, and secret revocation so access to confidential or personal data ends when the business need ends, not after the audit.
What's in the full article
Zluri's full article covers the control examples this post intentionally leaves at the policy level:
- Detailed descriptions of how access management maps to SOC 2 security, confidentiality, and privacy requirements.
- Step-by-step examples of access review and auto-remediation workflows for SaaS applications.
- Practical explanations of how audit evidence can be produced from access management actions.
- Guidance on choosing between manual spreadsheet review and automated access governance processes.
👉 Read Zluri's SOC 2 access control guide for implementation details →
SOC 2 access controls: what IAM teams miss in audit prep?
Explore further
SOC 2 fails when access governance is treated as a point-in-time control. The article frames controls as items to implement for audit readiness, but the real governance problem is whether access can be granted, reviewed, limited, and revoked as a lifecycle. That is where many programmes weaken, because a control that exists at provisioning time can still fail at review or offboarding. The practitioner takeaway is that SOC 2 evidence has to reflect control durability, not just control existence.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why access review evidence often misses the identities auditors most need to see.
A question worth separating out:
Q: Who should own SOC 2 access governance when machine identities are involved?
A: Ownership should sit with the team that controls the system or workflow using the identity, not with a generic security queue. That owner must be responsible for approvals, reviews, rotation, and revocation. Without clear ownership, machine identities drift into permanent access and become hard to audit cleanly.
👉 Read our full editorial: SOC 2 access controls expose the gap in identity governance