TL;DR: Oak's latest guidance shows identity vendors can hold the crown jewels of entitlement data, so a current SOC 2 Type 2 report matters more than a design-only review. Type 2 evidence should prove operating access controls, change management, monitoring and subservice governance over the review period, not just policy intent.
Editorial analysis by NHI Mgmt Group, based on content published by Oak: “What SOC 2 Type 2 Report to Ask an Identity Vendor For”.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
Bottom line: Identity vendor assurance has to prove operating effectiveness, not just control design, when the platform can influence access and entitlement data.
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
👉 Read Oak's guidance on SOC 2 Type 2 due diligence for identity vendors →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: What a SOC 2 Type 2 report should show for identity vendors