SOC 2 audit checklists expose the access review gap in SaaS governance

At a glance

What this is: This is a SOC 2 audit checklist that frames compliance as a control-readiness exercise, with access reviews, scope definition, and evidence collection as the core tasks.

Why it matters: It matters because SOC 2 outcomes depend on identity governance across human, NHI, and privileged access programmes, not just policy documentation or point-in-time attestations.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Zluri's 8-step SOC 2 audit checklist for compliance readiness

Context

SOC 2 is a control assurance framework, not just an audit checklist, and the hardest failures usually appear where access, evidence, and operating discipline do not line up. For identity teams, that means the real question is whether human access, service accounts, and administrative privileges can be shown to follow the same governance model consistently.

The article is useful because it treats audit readiness as a sequence of decisions about scope, trust service criteria, risk assessment, and access reviews. That is exactly where identity governance either supports the audit or becomes the gap that auditors and customers notice first.

Key questions

Q: How should security teams prepare identity controls for a SOC 2 audit?

A: Start by tying every in-scope identity, privilege, and review process to a specific trust service criterion. Then collect evidence that shows controls operated in practice, not just that policies exist. SOC 2 auditors look for operating effectiveness, so remediation records, approval trails, and review outcomes matter as much as the control design.

Q: Why do access reviews matter so much in SOC 2 readiness?

A: Access reviews are the clearest proof that entitlement decisions are still valid. They expose stale accounts, excessive privilege, and unresolved exceptions. In a SOC 2 context, a review only matters if it leads to access change or documented justification, because auditors need evidence that governance affected the control environment.

Q: What do organisations get wrong about SOC 2 and least privilege?

A: They often treat least privilege as a policy statement instead of an operating model. SOC 2 exposes that mistake quickly, because auditors can compare approved access, actual entitlements, and remediation timing. If excess access remains after review, the control did not work even if the checklist was completed.

Q: Who should own identity evidence for a SOC 2 audit?

A: Identity evidence should be owned by the teams responsible for the control, not left to last-minute audit coordination. That usually means IAM, security operations, application owners, and NHI governance teams each maintain their own proof of access decisions, reviews, and remediation so the audit trail stays defensible.

Technical breakdown

SOC 2 scope definition and control evidence

SOC 2 scope is the boundary that determines which systems, processes, and identities will be tested against the trust services criteria. In practice, scope must connect declared services, supporting infrastructure, access pathways, and the evidence that shows controls operated as intended. If the scope is too broad, teams lose focus. If it is too narrow, they create gaps between what is promised and what is actually controlled. For IAM and NHI programmes, scope definition is where entitlement ownership, review cadence, and logging expectations become audit artefacts rather than informal practice.

Practical implication: map every in-scope identity and entitlement to a named control owner before evidence collection begins.

Access reviews, least privilege, and SOC 2 readiness

Access review is the audit mechanism that proves entitlement decisions are still valid. SOC 2 auditors care less about whether a review exists on paper and more about whether the review catches excessive access, stale accounts, and unresolved exceptions. That is why least privilege matters here as an operational discipline, not a policy slogan. In identity environments with SaaS, service accounts, and admin roles, the review process must show who approved access, why it remained, and whether remediation actually happened after the review window closed.

Practical implication: use review evidence to prove access reduction, not just review completion.

Trust service criteria and the identity control model

The five trust service criteria frame how organisations prove security, availability, processing integrity, confidentiality, and privacy. Security is mandatory, but the other criteria often expose identity weaknesses indirectly, especially when access governance affects data handling or service continuity. For example, a weak joiner-mover-leaver process can produce lingering access that undermines confidentiality and security at the same time. For IAM leaders, SOC 2 is therefore not a separate compliance project. It is a structured test of whether identity controls are designed, operated, and evidenced as a system.

Practical implication: align identity control evidence to each selected trust service criterion before the audit fieldwork starts.

NHI Mgmt Group analysis

SOC 2 readiness breaks when access governance is treated as documentation instead of control execution. The article makes clear that audit success depends on actual operating effectiveness, not policy volume. That distinction matters because identity teams often produce evidence after the fact, then discover that privilege scope, review completion, and remediation timing do not line up. Practitioners should treat SOC 2 as a test of control reality, not paper compliance.

Access review is the control most likely to expose weak identity hygiene during SOC 2 preparation. Reviews only help when they identify excessive privilege, stale entitlements, and unresolved exceptions quickly enough to change the access posture before the audit. The article's checklist points directly at that pressure point. IAM and NHI teams should expect auditors to ask whether review outcomes altered access, not whether the review was scheduled.

Review evidence gap: SOC 2 exposes the common assumption that a completed access review equals a secure entitlement model. That assumption fails when reviews are ceremonial, exceptions persist, or service accounts sit outside the review process altogether. The implication is that governance teams must stop equating process completion with access control effectiveness.

SOC 2 pulls machine identities into the same assurance conversation as human users. The article focuses on broad organisational controls, but service accounts, API keys, and privileged automation are part of the same evidence chain once they can reach production systems or sensitive data. That means NHI governance cannot sit outside the audit model. Practitioners should expect the audit boundary to expand to every identity that can affect trust service criteria.

Named concept, audit evidence drift: evidence drift is the gap between what controls are said to do and what current access records can actually prove. In SOC 2 programmes, that gap widens when entitlement records, review outputs, and remediation tracking live in separate places. The practical conclusion is that identity governance teams need one defensible evidence model, not three disconnected reports.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to NHI Mgmt Group research.
• For a deeper control lens, see NHI Lifecycle Management Guide and use it to tighten provisioning, rotation, and offboarding evidence.

What this signals

Audit readiness is becoming an identity evidence problem, not just a compliance calendar problem. Teams that cannot show where access lives, who approved it, and how quickly it was remediated will struggle to defend SOC 2 scope with confidence. In practice, this pushes IAM, security, and GRC closer together around a shared control record, with Ultimate Guide to NHIs , Regulatory and Audit Perspectives as a useful reference point.

Service accounts now need the same audit discipline as human access. The gap is not whether machine identities exist, but whether the organisation can prove they are inventoried, reviewed, and revoked on time. That is why NHI Lifecycle Management Guide is directly relevant for teams building defensible SOC 2 evidence.

SOC 2 programmes that rely on manual spreadsheets will keep missing the same evidence drift. Identity teams should expect auditors to test remediation latency, exception handling, and entitlement ownership across both human and non-human access paths.

For practitioners

• Align SOC 2 scope to identity ownership Build the audit scope from actual identity and entitlement ownership, including human admins, service accounts, and third-party access. Each in-scope system should have a clear owner, review cadence, and evidence source before fieldwork begins.
• Prove access review outcomes, not attendance Retain evidence that shows what changed after each review cycle: removals, reductions, exceptions, and approvals. A completed review without remediation history is weak audit evidence for least privilege.
• Pull service accounts into the same evidence model Inventory non-human identities that can touch customer data, production workloads, or audit-relevant systems, then include them in the same governance and review workflow as human privileged access.
• Validate trust service criteria against control operation For every selected trust service criterion, keep a direct line from the control statement to the log, review record, or approval artifact that proves it operated during the audit period.

Key takeaways

• SOC 2 exposes whether identity controls actually operate, not whether they are written down.
• Access reviews are only useful when they change entitlements or document a real exception path.
• Service accounts and privileged automation must be included in the audit evidence model, or the control story will be incomplete.

Key terms

• SOC 2 Audit Scope: The defined set of systems, processes, and identities that will be evaluated against SOC 2 trust service criteria. Good scope is precise enough to be testable and broad enough to include the identities that can actually affect security, confidentiality, availability, and privacy outcomes.
• Operating Effectiveness: The evidence that a control worked over time, not just that it was designed correctly. In audit terms, operating effectiveness is shown through logs, approvals, review outputs, and remediation records that prove the control functioned during the period being examined.
• Access Review: A formal check of whether an identity still needs the access it has been granted. For SOC 2, access reviews are strongest when they produce measurable change, such as removal of excess privilege, documented exceptions, or verified revocation of stale access.
• Trust Service Criteria: 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.

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 governance maturity, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance 8-Step SOC 2 Audit Checklist. Read the original.