SOC 2 compliance is a governance model, not a certification

At a glance

What this is: This is a Keeper Security explainer showing that SOC 2 is an attestation report for cloud service providers, with Type 2 focused on whether controls operate over time rather than at a single point in time.

Why it matters: It matters because IAM, PAM, offboarding, and access evidence are often what auditors and customers examine when deciding whether a service provider can be trusted with sensitive data.

By the numbers:

• Type 2 audits examine controls over a period of six to 12 months.

Context

SOC 2 is a trust and control assurance model for cloud service providers, not a product certification or a one-time security badge. The core question is whether controls for access, operations, confidentiality, and related areas operate as management claims they do.

For identity teams, the important part is that SOC 2 evidence usually depends on who can access systems, how privileges are granted, and how quickly access is removed when roles change or people leave. That makes IAM and PAM evidence central to both audit readiness and vendor assurance.

Keeper Security’s article also highlights a common misunderstanding: a SOC 2 report can be highly useful without being a mandate, and a Type 2 report still reflects a defined coverage period rather than permanent assurance.

Key questions

Q: How should IAM teams use SOC 2 reports when evaluating vendors?

A: Treat the report as evidence that specific controls operated during a defined period, not as a certificate of overall security. Focus on scope, the trust criteria covered, exceptions in the auditor’s opinion, and whether identity controls such as access reviews, offboarding, and privileged access were actually tested.

Q: Why do identity controls matter in a SOC 2 audit?

A: Identity controls show who can access systems, how privilege is approved, and whether access is removed when it is no longer needed. Auditors care about evidence, so access reviews, revocation records, and privileged session logs help prove the control operated consistently during the reporting period.

Q: What breaks when offboarding is not part of SOC 2 evidence?

A: The organisation may be able to describe control design but not prove that access is removed quickly enough to limit exposure. That gap weakens the audit narrative around confidentiality and security, because lingering access shows that the control operated inconsistently during the coverage period.

Q: What should security teams do after a SOC 2 report is issued?

A: Check whether the report’s scope, coverage period, and exceptions still match current operations, then keep collecting evidence until the next audit cycle. SOC 2 assurance decays if access models, vendors, or privileged roles change without corresponding governance updates.

Technical breakdown

SOC 2 attestation vs certification

SOC 2 is an attestation report under the AICPA reporting framework, which means management asserts that controls exist and an independent CPA tests whether that assertion is supported. That is different from certification language, which suggests a binary badge. The report can cover security, availability, confidentiality, processing integrity, and privacy, but security is the only required principle. For practitioners, the relevant question is not whether a vendor has a logo, but whether the report shows tested control operation that matches the services and data at stake.

Practical implication: Use the report as evidence of control operation, not as shorthand for trust.

Why Type 2 matters for identity control evidence

Type 1 describes whether controls are designed at a point in time, while Type 2 tests whether they operated effectively over a defined period, often six to 12 months. That distinction matters for identity because access reviews, least privilege, offboarding, and MFA only prove anything if they work repeatedly, not once. In practice, Type 2 evidence is stronger when it can show access administration, termination handling, and privileged control enforcement across the coverage period rather than a snapshot just before the audit.

Practical implication: Prioritise evidence that shows access controls operating consistently across the audit window.

SOC 2 control families that intersect with IAM and PAM

Keeper Security ties SOC 2 compliance to access control, change management, systems operations, and risk management. In identity terms, that typically surfaces as least privilege, role-based access control, timely deprovisioning, MFA enforcement, and separation of duties around privileged functions. The framework does not prescribe a single tool or implementation pattern, so organizations must demonstrate that their chosen identity controls actually support the stated trust criteria. The audit question is whether those controls reduce exposure and produce defensible evidence, not whether they follow a vendor template.

Practical implication: Map IAM and PAM controls directly to the trust criteria your report covers.

NHI Mgmt Group analysis

SOC 2 is governance evidence, not trust itself: The report matters because it documents whether control operation matches management claims, not because it confers security by branding. That makes identity evidence, especially access grant, review, and removal records, part of the assurance story rather than a separate operational concern. Practitioners should treat SOC 2 as a test of control discipline.

Identity governance is the easiest place for SOC 2 promises to fail: Access controls, privileged access, and offboarding are where control design becomes observable in audit evidence. If those records are inconsistent, the report may still exist, but the assurance value collapses. The practical lesson is that audit readiness depends on lifecycle governance, not only policy text.

Control operation over time is the real signal: Type 2 reporting forces organisations to prove that controls held up across a period, which aligns closely with how identity risk actually behaves. Standing access, stale privileges, and weak termination handling are temporal problems, so snapshot assurance is structurally weaker than time-based evidence. That is why repeated access hygiene matters more than last-minute remediation.

Auditability of access is the governing concept: SOC 2 turns identity into an evidence problem. The question is whether the organisation can show who had access, why, for how long, and under what approval process across the full coverage period. That is the signal IAM teams should optimise for: traceable entitlement decisions, not just compliant policy wording.

SOC 2 assurance is only as strong as the third-party access model behind it: Cloud service providers often rely on external systems, vendors, and administrators, which means the report’s value depends on how those identities are governed. Third-party access without lifecycle discipline weakens the very trust the report is meant to communicate. Practitioners should treat vendor access and privileged delegation as part of the same assurance boundary.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Privileged Access Management Guide

What this signals

Auditability of access is becoming a board-level requirement: SOC 2 pushes identity teams to prove that entitlement decisions are recorded, reviewable, and retained across the period under assessment. That expectation is increasingly relevant beyond cloud providers, because third-party trust now depends on evidence, not assertion.

Control narratives fail when lifecycle governance is thin: A report can describe good design, but if termination, delegated access, or privileged review are not consistently evidenced, assurance degrades fast. That is why IAM and PAM teams should think in terms of demonstrable operation, not policy completion.

For practitioners

• Document control operation across the coverage period Keep evidence that shows access controls, termination handling, and privileged actions operating consistently across the full Type 2 window, not only at audit start or end.
• Tie IAM controls to trust criteria Map least privilege, RBAC, MFA, and deprovisioning directly to the specific SOC 2 trust principles the organisation claims, so the evidence set matches the stated scope.
• Track privileged access evidence separately Maintain distinct records for privileged accounts, emergency access, and delegated administrator activity so auditors can see how elevated access was approved and reviewed.
• Review third-party access as part of assurance Include vendor and partner access paths in the same governance process as internal identities, because third-party access can undermine the credibility of the control environment.

Key takeaways

• SOC 2 is an attestation model that tests whether claimed controls actually operated, so the assurance value depends on evidence rather than branding.
• The most consequential identity controls in this context are access governance, privileged access, and timely offboarding because those controls are easiest to test over time.
• IAM teams should align access evidence, audit scope, and third-party governance so the report reflects real control operation across the coverage period.

Key terms

• SOC 2 Type II Audit: A SOC 2 Type II audit is an independent review of how well an organization protects customer data over a period of time. It evaluates the design and operating effectiveness of controls against the Trust Services Criteria, typically covering security, availability, processing integrity, confidentiality, and privacy, based on evidence collected across months.
• Type II Audit: A Type II audit evaluates whether controls are both designed well and operated effectively over an observation window, usually three to twelve months. This is the format enterprise customers expect because it shows sustained execution, not just a snapshot. It is the more demanding and commercially useful SOC 2 report.
• 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.
• Access Governance: Access governance is the policy and workflow layer that manages how access is requested, approved, certified, and revoked. In SaaS environments it helps standardise control across many applications, reducing inconsistency between teams. It is most effective when it covers both human accounts and non-human identities.

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 building or maturing an IAM programme, it is worth exploring.