A SOC 2 report exists for exactly one reason: so a vendor gets audited once and every customer reads the same report instead of running their own audit. Audit once, distribute many. That was the entire pitch when the AICPA retired SAS 70 and gave us SOC 2 in 2011. One examination, one opinion, shared across the customer base.
So how did we arrive at 2025 with Okta needing to launch a program where multiple customers collectively fund a SOC 2 examination of a shared vendor — a pooled audit — as if this were a novel idea? Because we broke the original one. This is the postmortem on that failure, and the retrospective Okta just published is the part where we admit the workaround needed a workaround.
How the shared report stopped being shared
Here is the failure, in slow motion, and if you’ve done vendor security review you’ve lived every frame of it.
A connector vendor — say a SCIM provisioning bridge or a workflow automation partner sitting in your Okta tenant — produces a SOC 2 Type II report. Good. Then the risk management industry decided that report wasn’t enough. Every enterprise customer layered its own bespoke security questionnaire on top: 300 rows of spreadsheet asking whether the vendor encrypts data at rest, then asking it again in slightly different words on row 214. The Shared Assessments SIG existed to standardize this. Nobody used the standard version. They forked it.
So a small integration vendor with 40 enterprise customers now fields 40 questionnaires a year, 40 sets of follow-up calls, 40 requests to fill in a customer’s proprietary risk portal — all asking questions the SOC 2 report already answered. The report was supposed to end this. Instead it became the appendix nobody read while everyone re-litigated the same controls by email.
The vendor’s security team spends Q1 answering questionnaires instead of doing security. The customer’s GRC team spends Q1 reading answers they can’t independently verify anyway. Multiply across the ecosystem and you get what the industry politely calls “audit fatigue” and what I call a self-inflicted denial-of-service attack on the people you’re trusting with provisioning into your directory.
The three things people keep confusing
Quick, because the retro assumes you know this and half your compliance team doesn’t:
- A vendor security questionnaire is the vendor grading its own homework. Self-attested, unverified, useful mostly as a liability paper trail. It proves someone typed “yes.”
- A SOC 2 Type II is an independent CPA firm testing whether stated controls actually operated over a period — usually 6 or 12 months. Type I is a point-in-time snapshot; Type II is the one that matters because it covers duration. This is evidence, not attestation.
- A penetration test is someone trying to break the thing. Narrow scope, deep signal. It answers a different question than SOC 2 and doesn’t replace it.
Pooled audits are a play on the middle one. Instead of each customer separately pressuring a shared vendor for evidence — or worse, commissioning their own one-off assessment — a group of Okta customers co-sponsors a single SOC 2 Type II with scope they collectively agree on, run by an auditor they collectively accept.
What the first year actually shows
Okta’s one-year retrospective is refreshingly modest, which is how you know it’s real. This is not a hockey-stick chart. The program covered a small set of shared integration vendors in year one — the kind of number where “handful” is the honest word, not “dozens.” Anyone quoting you a huge count is selling something.
The vendors that benefited most were exactly the ones you’d predict: SCIM provisioning providers, workflow and lifecycle automation partners, and the busier SaaS connectors — integrations with broad customer overlap and deep access. A connector that reads and writes to your directory is precisely where redundant scrutiny concentrates, so it’s precisely where pooling pays off. Long tail of niche integrations with three customers each? Pooling does nothing for those. There’s no pool.
The savings are real but they’re not primarily dollars. The dollar cost of a SOC 2 was already sunk on the vendor side. What pooling recovers is time — the vendor stops answering 40 versions of the same question, and participating customers stop each running the review from scratch. Call it the elimination of duplicated diligence rather than a discount. Anyone promising quantified per-customer cash savings is rounding aggressively.
The question that decides whether any of this works
Will your auditor accept a pooled report? That’s the whole ballgame, and it’s where the first breakages showed up.
A pooled SOC 2 is still a SOC 2 — same standard, same CPA opinion — so in principle it drops straight into your evidence package. In practice, three things bite:
Scope. A pooled audit covers the scope the pool agreed on. If your control environment depends on something outside that scope, the report doesn’t cover you, and a good auditor will notice. Read Section 3. Read what was excluded.
Complementary user entity controls. This is the one that comes back to haunt you in month six. Every SOC 2 lists CUECs — controls the report assumes you are running on your side. A pooled report doesn’t change that. If the report assumes you enforce MFA and least-privilege on the service account the connector uses, and you didn’t, the auditor’s clean opinion is not your clean opinion. The gap is yours.
The opinion type and the bridge letter. Check whether it’s an unqualified (clean) opinion or a qualified one, and whether the coverage period aligns with your audit window. If there’s a gap between the report’s end date and yours, you need a bridge letter from the vendor. Pooling doesn’t exempt you from the boring parts.
What to actually do with this
- Treat a pooled report exactly like any SOC 2 — because it is one. The pooling is a procurement detail. The evidentiary weight comes from the auditor’s opinion, not the funding model. Don’t discount it for being shared; don’t over-trust it for being fancy.
- Read Section 3 and the CUEC table before you read anything else. Scope and complementary controls decide whether the report covers your reality. The executive summary is marketing; the scope section is the contract.
- Push your own vendors toward this, but only where overlap is real. If a connector serves you and 30 peers, ask whether a pooled examination exists. If it serves you and two others, don’t bother — there’s no efficiency to capture.
- Stop sending questionnaires that duplicate the report. This is the actual fix. The audit fatigue was never the auditors’ fault. It was ours, for treating an independent CPA opinion as a warm-up act to a spreadsheet.
Should Entra, Auth0 and Google Workspace copy this? Yes, and it’s telling that the marketplace with the messiest connector sprawl moved first. But let’s be honest about the size of the win. This isn’t a new security model. It’s the industry rediscovering that SOC 2 already was the pooled audit — we just spent a decade burying it under questionnaires and calling that diligence. The lesson we keep relearning is the cheapest one there is: read the report you already paid for.