What SOC 2 Type 2 Report to Ask an Identity Vendor For

Introduction

For identity vendor SOC 2 Type 2 due diligence, request the vendor's most recent Type 2 report covering the Security criteria. Check that the review period is current, the full production system is in scope, and a bridge letter covers any gap.

Then read the controls in four areas first: logical access, change management, monitoring, and vendor management.

The reason is what the platform will hold. An identity security platform typically stores your identity and entitlement data, so its own controls protect your most sensitive inventory.

Third parties are a proven path in. A third party was involved in 48% of breaches, a 60% increase on the previous year, according to the Verizon 2026 DBIR.

This SOC 2 Type 2 report checklist is for CISOs, IAM leads, and GRC leads evaluating Oak, the AI-native identity operating system. The same checks apply to any platform that will sit beside the IGA you run.

Key takeaways

• Type 2 is the bar: Type 1 shows design; Type 2 shows controls actually operated.
• Scope first: the production service and each connector interface belong in scope.
• Your controls count: complementary user entity controls are yours to run and evidence.
• Shortlisting Oak: run this identity vendor SOC 2 Type 2 checklist in your demo.

What a Type 2 report proves that a Type 1 does not

A SOC 2 Type 1 report evaluates whether controls are suitably designed on a single date. A Type 2 report tests design and operating effectiveness over a defined review period.

For an identity vendor, that difference decides the question. Of the two report types, only a Type 2 shows that staff access was actually removed at termination and that code changes were actually approved before release.

The controls that matter for a vendor holding identity data

An identity security platform holds the map of who and what can reach your systems. Read four control areas first, because those controls guard that map.

Oak's Identity Risk Visibility & Intelligence builds it. It continuously correlates what every identity can access with what it actually uses, then routes risk-prioritized decisions to the right reviewers.

Logical access (CC6)

Logical access controls answer one question: who at the vendor can reach your tenant data, and how is that reach removed?

• Production access: named staff reach customer tenant data only through approved roles, with access logged.
• Privileged access: administrative access is granted just in time or tightly restricted, with approvals sampled.
• Termination: access is removed when staff leave, with sampled leavers tested against removal dates.
• MFA: multi-factor authentication is enforced on production and administrative consoles.
• Staff access reviews: vendor staff access is reviewed periodically, with evidence that reviewers acted on findings.

Change management (CC8)

Connector and code changes sit on your data path. A bad change can expose or corrupt the entitlement data the platform holds.

Check that sampled changes show approval, testing, and segregation between whoever writes code and whoever deploys it. Read how emergency changes are approved and reviewed afterward, because that path often skips normal gates.

Monitoring and vendor management (CC7, CC9)

Monitoring controls show whether the vendor detects anomalous access to production and tests its incident response. A documented plan that was never exercised is a weak control.

Vendor management controls show how the vendor governs its own subservice providers. Your data inherits their risk.

The cost of a miss is concrete. The IBM Cost of a Data Breach Report 2026 put the global average breach at a record $4.99 million, up 12%.

Review period, scope and carve-outs

Start with dates. The review period should have ended recently, and a bridge letter should cover the gap between period end and your review.

Next, read the system description. It should cover the production service you will buy and each interface that touches your systems, including connectors, on-prem agents, and APIs.

Identity platforms typically rely on subservice organizations, such as cloud hosting providers. The carve-out method means the vendor's report excludes a subservice organization's controls, so you review that provider's report separately.

The inclusive method brings those controls into the vendor's own report and testing. When a report uses carve-outs, request each carved-out provider's report and note which vendor controls depend on it.

List each connection path a platform uses and match it to the system description. Oak's ConnectAny connector engine reaches on-prem, homegrown, and custom systems, so those paths are the interfaces to raise in any identity vendor's review.

Complementary user entity controls you must run

Complementary user entity controls are the controls a vendor's report assumes you operate, without which its own controls may not meet their objectives. Your auditor may ask for your evidence on them, separate from the vendor's.

Ownership is where identity programs often slip. Oak maps each discovered AI agent to an accountable human owner as part of governing AI agent identities, yet confirming that owner remains your control.

How to read exceptions

Start with the opinion.

An unqualified opinion means the auditor found controls suitably designed and operating effectively. A qualified opinion means the auditor found a material problem or could not test something.

An exception is a deviation found in testing. A report with an unqualified opinion can still list several.

• The control: which control failed and which criterion it supports.
• The deviation rate: how many samples failed out of how many were tested.
• Management's response: what the vendor changed, and whether the fix was retested.
• Logical access link: whether the failure touches who can reach customer data.

Repeated exceptions in termination or privileged access deserve a follow-up call.

Questions to ask in identity vendor SOC 2 Type 2 due diligence

These questions double as an IGA vendor certification checklist. Send them with your security questionnaire and ask for written answers.

• Review period: when did the period start and end, and does a bridge letter cover the gap?
• Scope: does the system description cover the production service and each interface that touches your systems?
• Criteria: which Trust Services Criteria beyond Security are covered, such as Availability or Confidentiality?
• Subservice organizations: which ones are carved out, and can you review their reports?
• Exceptions: what exceptions were found, and how was each remediated and retested?
• CUECs: which complementary user entity controls does the report assign to you?
• ISO 27001 status: is the vendor ISO 27001 certified, or aligned to the standard?

According to Oak's privacy policy, the platform is SOC 2 Type II certified and ISO 27001 aligned. Bring the questions above to a demo.

How the report fits a proof of concept and an RFP

Request the report under NDA before you connect production systems to a proof of concept. A POC connection is real access to your identity data, so the vendor's controls apply from the first connection.

Limit POC connections to interfaces the system description covers. Anything outside it needs a documented exception from your GRC lead.

The rest of the evaluation follows the criteria in What to Require in an Identity Security Proof of Concept.

In the RFP, turn the report into scored rows rather than a single yes or no.

• Report type and currency: a Type 2 report with a recent period end and a bridge letter.
• Scope fit: the production service and each connection interface appear in the system description.
• Exception profile: no unresolved exceptions in logical access or change management.
• CUEC load: customer controls your team can operate and evidence today.

Already running an IGA? Oak connects to the IGA you already run and covers what it cannot reach.

That connection into your IGA is itself an interface to score under scope fit.

Conclusion

Read against scope, carve-outs, exceptions, and your controls, a current identity vendor SOC 2 Type 2 report shows whether a platform can hold your data.

For a CISO or IAM lead, the outcome is a vendor decision you can defend to auditors and the board. The vendor's controls and yours sit documented side by side.

Oak offers a free white-glove implementation program for qualifying large enterprises. The Oak White Gloves team builds, migrates, and manages identity programs end to end, embedded in your organization.

Get a demo to take your report questions to Oak.

Frequently asked questions

Is a SOC 3 report enough for identity vendor SOC 2 Type 2 due diligence?

No, a SOC 3 report is not enough for identity vendor SOC 2 Type 2 due diligence. A SOC 3 is a general-use summary that omits the control descriptions, test procedures, and exceptions you need to judge logical access. Treat it as a sign that a SOC 2 exists, then request the full report. When Oak is on your shortlist, raise the report on a demo call.

How recent should an identity vendor SOC 2 Type 2 report be?

An identity vendor SOC 2 Type 2 report should be the latest one issued, and you should ask when the next one is due. Write delivery of each new report into the contract so evidence never lapses. Oak runs continuous, risk-driven access reviews, because periodic reviews tell you what happened, never what is happening. Oak remediates from the source the moment an identity deviates.

Can you share an identity vendor SOC 2 Type 2 report with your auditors?

Yes, you can typically share an identity vendor SOC 2 Type 2 report with your own auditors. Its restricted-use language usually names user entities and their auditors as intended readers. Confirm the NDA preserves that right, because your auditor may test how you rely on the vendor. Ask Oak, like any shortlisted vendor, to confirm its sharing terms early.

Should you shortlist an identity vendor without a SOC 2 Type 2 report?

You can shortlist an identity vendor without a SOC 2 Type 2 report, on conditions. Require a Type 1 in hand, a Type 2 audit under way, and a contract clause requiring delivery. Until then, limit live credentials and start from exported data. Confirm which report each shortlisted vendor holds, Oak included.

How does ISO 27001 differ from SOC 2 Type 2 for an identity vendor?

ISO 27001 and SOC 2 Type 2 answer different questions about an identity vendor. ISO 27001 certification attests to an information security management system. A SOC 2 Type 2 report tests specific controls over a review period and lists the exceptions found. Neither substitutes for the other in due diligence. With Oak, as with any vendor, ask during the demo how its controls map across both frameworks.