What a SOC 2 Type 2 report should show for identity vendors

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Oak's blog post: Identity vendor SOC 2 Type 2 due diligence should centre on current scope, operating access controls, change management, monitoring and carve-outs.

Why it matters: IAM, IGA and GRC teams need a repeatable way to tell whether a vendor handling identity data can actually operate the controls it claims, especially where third-party access and connector paths expand the risk surface.

👉 Read Oak's guidance on SOC 2 Type 2 due diligence for identity vendors

Context

A SOC 2 Type 2 report is more than a checkbox for vendor procurement. For identity platforms, it is a test of whether the controls protecting identity and entitlement data actually operated across the review window, not just whether they were written down.

That distinction matters because identity vendors sit on sensitive connection paths, including connectors, APIs and administrative consoles. When the platform controls the map of who can reach what, the quality of the vendor's own access, monitoring and change discipline becomes part of your governance model.

The recurring question is not whether the vendor has a report, but whether the report covers the production service, the interfaces that touch your environment, and any third parties behind carve-outs.

Key questions

Q: What should security teams verify first in a SOC 2 report?

A: Start with the management assertion and the system description, because those sections define what the report actually covers. If the boundary, period, or service description does not match the environment you are buying, the rest of the report cannot be treated as reliable evidence for your risk decision.

Q: Why does a Type 2 report matter more than a Type 1 report for vendors?

A: A Type 2 report matters more because it covers whether a vendor’s controls operated effectively over a period, not just whether they were designed well on a single date. For NHI assurance, that gives stronger evidence on controls such as access review, secret handling, logging, and change management around service accounts, API keys, and tokens.

Q: How do carve-outs affect vendor assurance evidence?

A: Carve-outs reduce assurance because they exclude parts of the vendor’s environment, processes, or subservice organisations from the evidence being tested. That means the report may not fully cover controls over secrets, privileged access, logging, or offboarding for the exact systems, service accounts, or APIs you rely on, so the excluded scope must be checked separately.

Q: Who should own complementary user entity controls when responsibility spans provider and customer teams?

A: Ownership should sit with the service provider for defining and disclosing the CUEC, but the user entity must own implementation on its side. In practice, both parties need named accountability. The provider should describe the requirement clearly, while the customer should assign an internal owner to track, review, and evidence each control across onboarding, operations, and audit cycles.

Technical breakdown

Type 1 vs Type 2 in identity vendor assurance

A Type 1 report asks whether controls are suitably designed at a point in time. A Type 2 report asks whether those controls were operated consistently over a defined period, using sampled evidence. For identity vendors, that difference is critical because tenant access, termination workflows, and connector approvals are operational behaviours, not static declarations. A design-only view cannot show whether privileged access was actually removed, whether emergency changes were reviewed after the fact, or whether monitoring alerts were acted on during the period under test.

Practical implication: Require a Type 2 report when the vendor will process identity data or sit on critical connection paths.

Scope, carve-outs and bridge letters in SOC 2 reviews

Scope tells you what the auditor actually tested. In identity vendor reviews, the production service and every interface that touches your systems matter, including connectors, on-prem agents and APIs. Carve-outs change the meaning of the report because the vendor excludes a subservice organisation's controls, so you have to inspect that provider separately. Bridge letters fill the gap between the report period and your review date, which helps you avoid relying on stale evidence when procurement and deployment timelines drift. See the SOC 2 Guide.

Practical implication: Check that the system description matches every live interface before you connect production systems.

Complementary user entity controls for identity platforms

Complementary user entity controls are the customer-side controls the vendor assumes will exist for its own controls to work as intended. In an identity context, these often include admin access governance, SSO and MFA configuration, connector credential custody, and ownership of service accounts or AI agents. If the customer does not run those controls, the vendor's report can still be clean while the operational risk remains unresolved. That is why the report should be read as a shared control model, not a vendor-only assurance artefact. See the SOC 2 Readiness Checklist.

Practical implication: Map every CUEC to an internal owner and evidence source before you rely on the report.

NHI Mgmt Group analysis

Type 2 evidence is the minimum viable trust signal for identity vendors: A design-only report does not tell a buyer whether access removal, change approval or monitoring actually happened when it mattered. Identity platforms store entitlement maps and connector credentials, so the control question is behavioural, not documentary. Buyers should treat operating effectiveness as the baseline for any platform that can alter their identity control plane.

Scope drift is the quiet failure mode in vendor assurance: The production service is only one part of the picture; connector engines, cloud hosting, on-prem agents and carved-out subservice providers can all sit on the path to customer data. If those components are not clearly represented in the report, the assurance boundary is too narrow to support a procurement decision. That is a scope problem, not a paperwork problem.

Shared responsibility is visible in complementary user entity controls: A vendor can test its own logical access and monitoring controls while still depending on the customer to govern admin roles, MFA settings and connector credential custody. That means the assurance conversation must shift from

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.
• More than 95% of infrastructure-as-a-service accounts use less than 3% of the entitlements they are granted, according to Gartner.
• Read next: SOC 2 Guide

What this signals

Shared control boundaries now define vendor trust: Identity buyers cannot separate vendor assurance from their own governance any longer, because admin roles, connector custody and notice handling often sit on the customer side of the control line. That makes the assurance review a joint operating model question rather than a document review exercise.

Third-party exposure remains a useful reminder of why this matters: 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs. The practical implication is simple. If the vendor's report does not make the production boundary and every dependent interface explicit, your risk review is incomplete.

For practitioners

• Request the latest Type 2 report before any production connection Do not treat a design-only report as enough when the platform will touch identity or entitlement data. Ask for the most recent Type 2 period, the opinion, and the exception list before you allow live access.
• Validate the system description against every connection path Compare the report scope with the production service, connector interfaces, on-prem agents and APIs you actually plan to use. If any path is missing, treat the assurance boundary as incomplete.
• Assign owners for every complementary user entity control Map each customer-side control in the report to an internal owner, an evidence source and a review cadence. That includes admin access, MFA configuration, connector credential custody and vendor notice handling.
• Read exceptions by control, not by opinion alone A clean opinion does not erase sampled failures. Focus on repeated exceptions in logical access, change management and monitoring, because those are the controls most likely to affect live identity data.

Key takeaways

• Identity vendor assurance has to prove operating effectiveness, not just control design, when the platform can influence access and entitlement data.
• Scope, carve-outs and complementary user entity controls are the three places where vendor trust breaks down in practice.
• A usable SOC 2 Type 2 review turns procurement into a control-by-control decision that auditors and boards can follow.

Related NHI Mgmt Group resources: How to Read a SOC 2 Report Guide · SOC 2 Readiness Checklist · SOC 2 Guide · Audit, Assurance and Compliance Guide

Key terms

• 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.
• Type 2 Report: A Type 2 report tests whether controls worked over a period, not just whether they were designed correctly on one date. In identity governance, this means auditors look for sustained evidence of approvals, reviews, offboarding, and monitoring rather than one-off screenshots or policy statements.
• Complementary User Entity Controls: Complementary User Entity Controls are the customer-side controls that must be in place for a provider’s controls to work as intended. They usually cover configuration, access management, monitoring, and other responsibilities assigned to the customer. If they are missing, the provider’s assurance does not fully translate into compliance for the customer.
• Carve-Out: A carve-out is the separation of a business unit, subsidiary, or asset from a parent organisation into a distinct operating environment. In identity security, it forces a rapid redesign of access, directories, privileged accounts, and governance so the new entity can function independently without inheriting unnecessary risk.

What's in the full article

Oak's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step questions to ask about logical access, change management and monitoring evidence
• Detailed guidance on reading carve-outs, bridge letters and exception language in a vendor report
• Practical questionnaire wording for RFPs, demos and procurement workflows
• Examples of complementary user entity controls that should be assigned to your team

👉 The full Oak post walks through report scope, carve-outs, exceptions and customer-owned controls in more detail.

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.