SOC 2 compliance is a governance model, not a certification

At a glance

What this is: SOC 2 is an attestation framework that evaluates whether a provider’s controls over data and systems are designed and operating effectively.

Why it matters: It matters because IAM, PAM, and NHI governance teams often use SOC 2 as a vendor assurance signal, but the report only helps if they understand what it proves and what it does not.

By the numbers:

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

👉 Read Keeper Security's guide to SOC 2 compliance and report interpretation

Context

SOC 2 is a control assurance framework, not a product feature or a certificate of trust. For identity and access teams, the useful question is whether the provider can show that access, change, and data-handling controls operate consistently over time, especially where third-party service delivery depends on cloud access, privileged workflows, and data processing.

The confusion around SOC 2 usually starts when teams treat the report as a pass-fail badge rather than an attestation with scope, period, and control coverage. That misunderstanding matters for IAM, PAM, and NHI programmes because it can hide gaps in entitlement governance, offboarding discipline, and audit evidence quality even when the vendor says it is SOC 2 aligned.

Key questions

Q: How should security teams use a SOC 2 report in third-party risk reviews?

A: Use it as evidence that a vendor’s controls were examined by an independent auditor over a defined scope and period. Then verify whether the scope covers the services, data flows, and identity controls that matter to your organisation. A SOC 2 report reduces uncertainty, but it does not replace contract review, technical validation, or ongoing vendor monitoring.

Q: What is the difference between a SOC 2 Type 1 and Type 2 report?

A: A Type 1 report checks whether controls are suitably designed at a point in time. A Type 2 report tests whether those controls operated effectively over months, which makes it a stronger signal for operational assurance. For high-risk vendors, Type 2 is usually the more useful document because it shows control behaviour, not just control intent.

Q: What should IAM teams look for in a vendor’s SOC 2 evidence?

A: IAM teams should look for proof of least privilege, role-based access, prompt offboarding, logging, and change management. Those are the control areas most likely to reveal whether identity governance is actually operating. If the report only provides a high-level assurance statement, ask for the specific tests, exceptions, and remediation notes behind it.

Q: Who is accountable when a vendor with SOC 2 suffers a breach?

A: Accountability remains shared and context-dependent. The vendor remains responsible for its control environment, but the customer still owns due diligence, contracting, access scoping, and ongoing oversight. SOC 2 is evidence, not immunity, so a compliant report does not eliminate the need to assess residual risk and determine whether the service fits your control requirements.

Technical breakdown

SOC 2 attestation vs certification

SOC 2 is part of the AICPA’s reporting framework and is based on management’s assertion that controls are in place, followed by an independent CPA examination of those claims. That makes it an attestation report, not a certification. The distinction matters because certification implies a fixed external stamp, while attestation reflects a scoped audit opinion tied to the controls and period examined. Security, availability, processing integrity, confidentiality, and privacy are the Trust Services Principles, but only security is mandatory in every SOC 2 engagement.

Practical implication: ask vendors which principles were in scope, which were excluded, and what control evidence supported the auditor’s opinion.

SOC 2 Type 1 vs Type 2

Type 1 assesses whether controls are suitably designed at a single point in time. Type 2 goes further and tests whether those controls operated effectively across a coverage period, usually six to 12 months. For governance teams, that difference is the difference between a stated control and a demonstrated control. A Type 1 report can be useful for a newer provider, but it does not prove operational consistency. Type 2 is more relevant when the vendor handles sensitive identity, access, or customer data over time.

Practical implication: prefer Type 2 for high-risk vendors and treat Type 1 as design evidence only, not operational proof.

How SOC 2 relates to access governance

SOC 2 does not prescribe specific technologies, but its security expectations map closely to access control, least privilege, offboarding, logging, and change management. That makes it relevant to IAM and PAM review because the report should reveal whether access was constrained to job function, whether departures were handled promptly, and whether control evidence was available for the auditor. For NHI governance, the same logic applies to service accounts and machine access because auditability depends on lifecycle control, not just policy language.

Practical implication: use the report to test whether identity lifecycle controls are actually operating, not just documented in policy.

NHI Mgmt Group analysis

SOC 2 is often treated as a vendor trust shortcut, but it is really an evidence test for control discipline. The report only tells you whether a provider can demonstrate operating controls over a defined period and scope. That makes it useful, but only if procurement and security teams read it as an attestation about evidence quality rather than a blanket statement of security maturity. The practitioner conclusion is simple: SOC 2 should inform due diligence, not replace it.

Identity governance is one of the strongest hidden threads in SOC 2 reporting. The controls that make SOC 2 credible are the same controls IAM, PAM, and NHI teams care about: least privilege, offboarding, logging, and change discipline. A vendor can satisfy the framework without perfect security, but it cannot satisfy the framework without being able to prove control operation. The practitioner conclusion is to inspect identity evidence, not just the opinion line.

Type 2 coverage is the more meaningful signal because it proves control behaviour over time, not control intent. Type 1 answers whether a control exists; Type 2 answers whether it survived real operating conditions across months. That difference matters for third-party risk reviews, where a point-in-time design statement can mask lifecycle gaps that only emerge in production. The practitioner conclusion is to calibrate assurance requirements to service criticality.

SOC 2 does not remove accountability for vendor risk, especially when the vendor handles customer data or privileged access. A clean report can reduce uncertainty, but it does not transfer responsibility for contract scope, access review, or offboarding discipline. Governance teams still need to determine whether the provider’s controls match their own risk model and data sensitivity. The practitioner conclusion is to use SOC 2 as one input in a broader assurance decision, not the decision itself.

From our research:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap is one reason readers should also review Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs for the operational controls behind assurance.

What this signals

Identity evidence will matter more, not less, as third-party assurance becomes a procurement gate. Teams that cannot map SOC 2 claims to access reviews, offboarding, and privileged workflow evidence will keep inheriting risk they cannot explain. For broader programme context, revisit Ultimate Guide to NHIs - Regulatory and Audit Perspectives when building vendor review criteria.

The confidence gap in machine identity governance is large enough to distort how teams read external assurance. When 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, a clean audit report should be treated as one input, not proof that lifecycle risk has been solved.

Vendor due diligence will increasingly shift from document collection to control verification. That is where identity teams should anchor their programme maturity work to the NIST Cybersecurity Framework 2.0, especially where access control, governance, and continuous monitoring need to be evidenced rather than assumed.

For practitioners

• Verify the audit type and coverage period Confirm whether the vendor has a Type 1 or Type 2 report, then check the coverage period, issue date, and control scope before relying on it in a risk review.
• Map SOC 2 evidence to identity controls Look for explicit evidence of least privilege, access provisioning, offboarding, logging, and change management rather than accepting broad security statements.
• Use the report to challenge third-party access assumptions Ask whether the provider’s controls cover customer data access, privileged operations, and subprocessors with the same discipline you require internally.
• Treat a qualified opinion as a hard risk signal If the report includes a qualified opinion or material deficiency, escalate it as a control failure and require compensating controls or a different sourcing decision.

Key takeaways

• SOC 2 is an attestation about control operation, not a certification that a vendor is secure.
• Type 2 reports are more useful than Type 1 for third-party assurance because they show controls working over time.
• IAM, PAM, and NHI teams should read SOC 2 for identity evidence, not just the opinion line.

Key terms

• SOC 2 Attestation: A SOC 2 attestation is an independent CPA examination of a service provider’s management assertion about internal controls. It does not certify security. Instead, it provides a scoped opinion on whether the controls were designed and, in Type 2, operated effectively during the audited period.
• Trust Services Principles: The Trust Services Principles are the control categories used in a SOC 2 examination: security, availability, processing integrity, confidentiality, and privacy. Security is mandatory, while the others are included only when they are relevant to the service and the auditor’s scope.
• Type 2 Audit Coverage Period: The Type 2 audit coverage period is the span of time during which a provider’s controls are tested for operating effectiveness. It is different from the report issue date, which is when the auditor finishes the work and issues the opinion. Teams use this distinction to judge report freshness.
• Qualified Opinion: A qualified opinion is an audit outcome indicating a material misstatement or material control deficiency. In SOC 2 terms, it means the provider did not fully satisfy the audit criteria. For buyers, it is a strong signal to re-evaluate risk, scope, and compensating controls.

Deepen your knowledge

NHI governance, agentic AI identity, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.

This post draws on content published by Keeper Security: What Is SOC 2? Your Guide to Understanding Compliance. Read the original.