SOC 2 access controls expose the gap in identity governance

At a glance

What this is: This is a SOC 2 explainer focused on how access controls, access reviews, and data protection requirements map to audit readiness.

Why it matters: It matters because SOC 2 controls often fail at the identity layer first, where entitlement sprawl, weak review processes, and poor access disposal affect human users, service accounts, and SaaS workloads alike.

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.

👉 Read Zluri's SOC 2 access control guide for implementation details

Context

SOC 2 is not just a documentation exercise. It is a test of whether identity, access, and data-handling controls actually work under audit scrutiny, especially where permissions, reviews, and disposal processes are involved.

For identity teams, the practical challenge is that SOC 2 expectations cut across human IAM, NHI governance, and lifecycle management. If access is granted too broadly, reviewed too infrequently, or revoked inconsistently, the control environment can look complete on paper while remaining weak in operation.

Key questions

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. Then prove the control works by showing approved access, timely recertification, and documented revocation for exceptions. Auditors look for repeatable governance, not just policy language or screenshots.

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. A list of excessive access is not evidence of control effectiveness unless it leads to removal, reduction, or approved exception handling. SOC 2 expects the control outcome to change, not just the meeting to happen.

Q: How can organisations handle confidentiality and privacy controls together?

A: Treat them as related but separate obligations. Confidentiality controls limit access to sensitive business data, while privacy controls govern the collection, use, retention, and disposal of personal data. The strongest programmes connect access limitation, retention rules, and deletion workflows so data cannot outlive its approved purpose.

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.

Technical breakdown

SOC 2 security criteria and access control design

The security trust services criterion is the mandatory SOC 2 baseline because it addresses unauthorised disclosure and access across the full control environment. In practice, that means access control design, monitoring, and periodic risk review must work together rather than operate as separate activities. For IAM teams, this is where role-based access control, least privilege, and segregation of duties become auditable control statements instead of policy language. The control objective is not simply to grant access, but to prove that only approved identities can reach sensitive systems and data.

Practical implication: map each sensitive application and dataset to explicit access rules, owners, and review evidence before the audit window opens.

Access reviews, remediation, and audit evidence

SOC 2 access review expectations depend on whether the organisation can identify excessive or outdated access and then remediate it in a controlled way. A review that only lists entitlements without removal action is weak evidence because the control outcome has not changed. This is especially relevant for SaaS estates, where permissions drift faster than annual or quarterly review cycles can catch. The audit value comes from traceability: who reviewed, what was flagged, what was revoked, and whether the change was completed within the same governance process.

Practical implication: require review outputs to include remediation status, approver identity, and a repeatable evidence trail for every revocation or reduction.

Confidentiality, privacy, and data disposal controls

Confidentiality and privacy are distinct SOC 2 criteria. Confidentiality is about preventing accidental disclosure of sensitive business data, while privacy is about collecting, using, and disposing of personal data in line with stated rules and consent expectations. That distinction matters because access limitation alone does not satisfy either criterion if retention and disposal are unmanaged. Data disposal is therefore part of identity governance, not a separate records task, because stale access to retained data extends the exposure window long after the business need has ended.

Practical implication: tie data classification, retention, and deletion workflows to access governance so revoked identities cannot keep reaching retired data.

NHI Mgmt Group analysis

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.

Access review without revocation is a false control signal. The article emphasises user access review and anomaly detection, which are necessary, but an inventory of excessive access does not by itself reduce risk. In identity governance terms, the failure mode is stale entitlement persistence: the organisation can see over-privilege but still leave it in place. Practitioners should treat remediation completion as part of the control, not an optional follow-on.

Confidentiality and privacy controls depend on lifecycle discipline, not only encryption or policy language. The article correctly separates these criteria, but the governance implication is broader: access limitation, retention, and disposal must stay aligned as data moves through collection, use, storage, and deletion. If identities keep access after the business purpose ends, the criterion may be technically documented and operationally hollow. The practical conclusion is that lifecycle offboarding is a confidentiality and privacy control, not just an admin task.

Standing access is the hidden SOC 2 liability in both human and non-human identity programmes. The same review logic used for employees often misses service accounts, API keys, and other machine identities that can retain access long after the originating workflow changes. That creates an identity blast radius problem: controls may certify human access while non-human access remains outside the evidence set. The practitioner implication is to bring machine identities into the same audit scope as human access reviews and revocation workflows.

From our research:

• 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.
• That visibility problem is documented further in the NHI Lifecycle Management Guide, which is the right next step for teams tightening revocation and offboarding discipline.

What this signals

Standing access is the control gap most likely to undermine SOC 2 evidence. When 30.9% of organisations still store long-term credentials directly in code, the audit problem is not just policy compliance, it is whether identities can be traced, reviewed, and revoked across the full lifecycle. Teams should treat code, SaaS entitlements, and service accounts as one governance surface, not separate review queues.

SOC 2 programmes should now be designed around entitlement reduction, not entitlement documentation. In practice that means access reviews must end in removal, and data disposal must be linked to identity offboarding so stale access does not survive the business use case.

The next maturity step is to align evidence collection with lifecycle controls. Resource owners need a repeatable path from approval to recertification to revocation, with machine identities included in the same governance model as human users.

For practitioners

• 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.
• Evidence remediation, not just review completion Store proof that flagged access was removed, reduced, or formally accepted, because a completed review without a follow-up change is weak SOC 2 evidence.

Key takeaways

• SOC 2 control strength depends on whether access, review, and disposal are tied together across the identity lifecycle.
• Machine identities can undermine audit evidence even when human access looks well governed, because excessive privilege and poor visibility persist in the background.
• Teams should prove remediation, not just review completion, if they want SOC 2 controls to withstand scrutiny.

Key terms

• SOC 2 Trust Services Criteria: SOC 2 trust services criteria are the control categories auditors use to judge whether an organisation protects data and operates reliably. They cover security, availability, processing integrity, confidentiality, and privacy, and each criterion requires evidence that controls work in practice, not just on paper.
• Access Review: An access review is a formal check of who can reach systems, data, or applications, and whether that access is still justified. In mature programmes, the review includes remediation, evidence of removal, and ownership for exceptions, so it becomes a governance action rather than a reporting exercise.
• Confidentiality Control: A confidentiality control limits access to sensitive business information so it is not disclosed accidentally or inappropriately. It usually combines access restriction, classification, retention, and disposal rules, because information stays at risk whenever its permissions or lifetime are broader than the business need.
• Non-Human Identity: A non-human identity is any machine or software identity used to authenticate and authorise access, such as a service account, API key, token, certificate, or workload identity. These identities need lifecycle governance because they often persist longer than the tasks or systems they support.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Access Management SOC 2 Trust Services Criteria: Implementing Effective Controls. Read the original.