SOC 2 audits expose the control gaps behind cloud trust claims

At a glance

What this is: SOC 2 audits test whether a service organisation can prove its controls protect customer data and operate as documented.

Why it matters: For IAM, NHI, and broader identity programmes, SOC 2 turns access governance, evidence quality, and control consistency into auditable obligations rather than informal security intent.

By the numbers:

• SOC 2 Type 2 audits assess controls over a longer period of time, typically 6 to 12 months.
• A SOC 2 audit report is valid for 12 months following the date the report was issued.

👉 Read StrongDM's complete guide to SOC 2 audits and compliance

Context

SOC 2 is an audit framework for service organisations that need to prove their internal controls are operating as described. For identity teams, that makes access governance, evidence retention, and control ownership part of the compliance baseline rather than a back-office reporting exercise.

The practical challenge is that audit readiness is usually treated as a project, while identity control effectiveness has to hold continuously. That gap matters across human access, non-human identities, and service-provider access because an auditor is testing whether controls are both designed and operated consistently.

For teams aligning identity controls to external assurance, the relevant question is not whether controls exist, but whether they can be demonstrated under review. That is why lifecycle discipline, review evidence, and documented scope matter as much as the control itself.

Key questions

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

A: Start by mapping every in-scope system to its access owners, approval paths, logging sources, and offboarding process. Then collect evidence that shows those controls operated consistently over the review period. Auditors care less about policy statements than about whether the organisation can prove repeatable execution across human and non-human access.

Q: Why do non-human identities matter in SOC 2 audits?

A: Service accounts, API keys, and tokens often carry access that can bypass the visibility and review patterns built for humans. If they are missing from the control inventory, the SOC 2 evidence story is incomplete. Auditors may see a strong human access process while the real operational risk sits in unattended machine credentials.

Q: What breaks when access reviews are treated as a one-time audit task?

A: The organisation loses operating proof. A one-time review can show that controls existed on a given date, but Type 2 evidence requires recurring execution, consistent follow-through, and traceable outcomes. Without that, the audit may expose gaps in review cadence, ownership, or remediation that a point-in-time snapshot hides.

Q: Who is accountable when SOC 2 evidence is incomplete?

A: Accountability sits with the control owner, the business sponsor, and the team responsible for producing evidence, not with the auditor. If logs, approvals, or offboarding records are missing, the organisation has failed to demonstrate control operation. Framework alignment and ownership clarity should be established before the audit window opens.

Technical breakdown

SOC 2 audit scope and trust services criteria

A SOC 2 audit starts by defining which Trust Services Principles apply to the organisation’s services. Those principles are security, availability, processing integrity, confidentiality, and privacy. The scope is critical because the auditor only evaluates controls that fall inside it. For identity practitioners, this means access management, logging, and evidence collection must be mapped to the services actually in scope, not to an assumed enterprise-wide control set. The audit is less about passing a checklist and more about proving that the selected controls are relevant, documented, and consistently operated.

Practical implication: map identity controls to the exact in-scope services before audit work begins.

SOC 2 Type 1 vs Type 2 evidence model

Type 1 audits examine controls at a point in time, while Type 2 audits assess whether those controls operated effectively over a longer period, typically six to twelve months. That difference changes the identity burden substantially. A point-in-time control can look complete even if reviews, offboarding, or access changes are inconsistent later. For NHI and human access governance, Type 2 places more weight on recurring evidence such as review logs, change records, and approval trails. The organisation must show that access control is not a one-day state but a sustained operating pattern.

Practical implication: build evidence collection around operating history, not only current configuration.

Audit execution, testing, and opinion outcomes

During execution, the CPA reviews scope, builds a plan, tests design and operating effectiveness, documents findings, and issues an opinion. The opinion can be unqualified, qualified, adverse, or a disclaimer if evidence is insufficient. For identity teams, this means missing logs, unclear ownership, or inconsistent approvals can affect the report even when technical controls exist. The audit is therefore a governance test as much as a security test. Identity evidence must be traceable, complete, and understandable enough for an external assessor to reproduce the control story without internal context.

Practical implication: treat evidence quality and traceability as audit controls in their own right.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Zacks Investment Research breach — Zacks breach exposed 12M customer records including credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SOC 2 turns identity governance into an evidence discipline, not just a control discipline. The framework asks organisations to prove that access decisions, policy enforcement, and review activity are operating over time. That matters because identity controls are often strongest at provisioning and weakest at sustained proof. Practitioners should treat auditability as a design requirement, not a reporting task.

Audit readiness exposes where lifecycle governance still depends on manual follow-through. SOC 2 preparation commonly reveals gaps in offboarding, review cadence, and policy documentation because those are the points where evidence fragments. In practice, the problem is rarely that controls do not exist. The problem is that the control owner cannot show consistent execution under scrutiny.

Control scope is the real boundary of assurance, and identity teams often underestimate how narrow that boundary can be. SOC 2 only evaluates what the organisation explicitly includes, which means undocumented access paths and unmanaged service identities can sit outside the assurance story. That makes scope definition a governance decision, not an administrative formality. Practitioners should assume the auditor will test the weakest evidence path inside scope.

Audit programmes that ignore non-human access leave a material blind spot in the trust story. Cloud services depend heavily on service accounts, API keys, and automation identities, yet those identities are often governed less consistently than human users. When evidence is built only around employee access, the report can overstate security maturity. Identity leaders should align SOC 2 evidence collection across human and non-human access paths.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• From our research: 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, according to Ultimate Guide to NHIs.
• From our research: The NHI Lifecycle Management Guide helps teams turn identity lifecycle controls into evidence that can survive audit scrutiny.

What this signals

SOC 2 pressure is moving identity teams toward continuous proof, not periodic documentation. The organisations that will struggle most are those still treating access reviews and offboarding as quarterly paperwork rather than controlled evidence streams. In practice, audit readiness is becoming a byproduct of disciplined identity operations, not a separate compliance project.

The strongest programmes will connect human access governance, NHI inventory, and service ownership into one evidence model. That reduces the chance that a clean employee access review masks an unmanaged machine credential path, which is where assurance often breaks down.

For practitioners, the next step is to align SOC 2 evidence collection with lifecycle controls already described in the NHI Lifecycle Management Guide and the NIST Cybersecurity Framework 2.0. That gives auditors a control story they can trace from policy to operation.

For practitioners

• Map SOC 2 scope to identity control ownership Document which services, systems, and identity flows are inside the audit boundary, then assign named owners for provisioning, review, and offboarding evidence.
• Build evidence packs for recurring access decisions Capture approvals, review results, and offboarding records in a format that can be reproduced across the full Type 2 period, not just at audit time.
• Include non-human identities in the control inventory List service accounts, API keys, tokens, and certificates alongside human accounts so the auditor sees the full access surface, not only employee identity.
• Separate control design from operating proof Keep policy documents, implementation evidence, and review artefacts distinct so the organisation can show both what should happen and what did happen.

Key takeaways

• SOC 2 is as much about proving identity control operation as it is about documenting security policy.
• Type 2 audits expose whether access governance, offboarding, and evidence collection remain consistent over time.
• Identity teams should treat non-human access as part of the audit boundary or risk leaving a material assurance gap.

Key terms

• SOC 2 Type 1: A SOC 2 Type 1 audit evaluates whether controls are designed appropriately at a specific point in time. It does not prove long-term operating consistency, so it is useful for baseline assurance but weaker for showing that identity processes actually held up across normal business activity.
• SOC 2 Type 2: A SOC 2 Type 2 audit tests whether controls operated effectively over a defined period, usually six to twelve months. For identity governance, that means the organisation must show repeatable evidence for approvals, access reviews, logging, and offboarding rather than relying on a single snapshot.
• Trust Services Principles: The Trust Services Principles are the criteria SOC 2 uses to evaluate a service organisation’s controls. They cover security, availability, processing integrity, confidentiality, and privacy, and each organisation must determine which principles actually apply to the services and data it handles.
• Control evidence: Control evidence is the documentation or system output that proves a control was designed and operated as claimed. In identity programmes, this includes approvals, logs, review records, and offboarding artefacts that allow an external auditor to trace decisions without relying on internal assumptions.

Deepen your knowledge

SOC 2 evidence mapping, access governance, and lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are translating audit requirements into repeatable identity operations, it is worth exploring.

This post draws on content published by StrongDM: Security Everything You Need to Know About SOC 2 Audits. Read the original.