Can I pass SOC 2 without a vendor SOC 2 report?

Generally yes, if you document why the report is unavailable and what you did instead. Auditors regularly deal with vendors that have no SOC 2 report. What fails an audit is an undocumented gap, not a documented one with compensating controls, a named owner and a re-review date. Assemble the vendor security documentation, DPA and subprocessor list, contractual terms, shared-responsibility mapping and your own continuous monitoring records, then record the missing report as an exception with residual risk noted. Your auditor makes the final call, so raise it early rather than at fieldwork.

Should I switch vendors if they will not share their SOC 2 report?

Rarely worth it on that basis alone. Migrating infrastructure to satisfy a document request usually costs more in engineering time and introduces more new risk than documenting the exception. It is worth reconsidering if the vendor is critical, handles regulated data, and refuses every alternative form of assurance including ISO 27001 certification or a penetration test summary.

Your Vendor Won't Share Their SOC 2 Report. Here's What to

Q: What is the difference between vendor due diligence and vendor monitoring?

Vendor due diligence is the assessment performed before and at onboarding, covering audit reports, contracts and security documentation. Vendor monitoring is the ongoing evidence that you kept watching the vendor afterward, such as timestamped availability records, incident logs and alert-delivery records. SOC 2 CC9.2 covers both halves, and teams that complete thorough onboarding due diligence often have nothing to show for the ongoing monitoring half.

Q: Does status page monitoring count as a compensating control for SOC 2?

It can count as a compensating control for availability risk specifically, provided the records are continuous and timestamped rather than screenshots reconstructed before the audit. It does not compensate for unverified security controls such as encryption, access management or personnel screening. Describe the scope accurately in the exception record and let the auditor weigh it against the residual risk.

Disclaimer: This post is educational content for engineers and teams preparing for SOC 2 audits. It is not legal or compliance advice. For guidance specific to your organization, consult a qualified auditor or compliance professional.

A founder posted on Reddit this week with a problem that keeps turning up in different clothes.

They're early-stage B2B, going through SOC 2 Type II readiness with Vanta. Vanta asks them to review their critical vendors' SOC 2 reports. One of those vendors — a core piece of their infrastructure — only hands the report to customers on a higher plan, which for them meant roughly $575/month more than they were paying, purely to read a PDF.

"It is literally a report all other vendors provided for free, zero problems."

They're right, and that's the part worth sitting with. Asking for the vendor's SOC 2 report is the correct first move, and no monitoring tool is a substitute for it. If you can get the report, get the report. This post is about the situation where you've asked, you've filled in the form, and the answer is still no.

First, the answers that actually worked in that thread

Two of them, and they're both worth trying before anything else.

Upgrade, collect, downgrade. Several people said they did exactly this. It's inelegant and you're paying for a document, but if the report is a hard blocker and one month of a higher tier unblocks it, that's the cheapest path. One caveat from the thread that people miss: vendor review is recurring. Confirm the evidence stays accessible to you next year, or you're buying the same month again every audit cycle.

Ask the vendor for the startup or early-stage exception. The vendor's own staff turned up in that thread offering a workaround through their startup program — the answer existed, it just wasn't on the pricing page. Most vendors have some version of this and almost nobody asks. A support ticket costs you ten minutes.

If either works, stop reading — you don't need the rest of this.

What your auditor is actually testing

Here's the reframe that gets teams unstuck.

CC9.2 says: the entity assesses and manages risks associated with vendors and business partners. Read it again and notice what's missing. It does not say "the entity collects SOC 2 reports."

The report is one evidence path for a control, not the control itself. The control is that you identified your vendors, judged their risk, did something proportionate about it, and can show your work. A Type II report is the most convenient way to satisfy the "judged their risk" part, because someone else already did the assessment for you. It is not the only way, and auditors know that — they deal with vendors who have no SOC 2 report at all, every single engagement.

So the question stops being "how do I get the PDF" and becomes "what else demonstrates that I assessed and managed this risk."

The substitute evidence package

This is the list the best answer in that Reddit thread laid out. Collect what exists, note what doesn't.

Evidence	Where to get it	What it demonstrates
Security & architecture documentation	Vendor's trust center or public docs	They have described controls, and you read them
DPA and subprocessor list	Usually public or on request	Data-handling terms are contractually bound
Encryption & access-control descriptions	Vendor docs	Technical controls exist for your data
Backup and recovery commitments	Docs or contract	Availability risk is bounded by something
Contractual terms and SLA	Your own signed agreement	Remedies and obligations are enforceable
Shared-responsibility mapping	You write this	You know which controls are yours vs. theirs
Incident and status history	Your monitoring records	The risk is being watched continuously, with dates
Penetration test summary or ISO 27001 cert	Ask — many vendors share these when they won't share SOC 2	Independent assurance from a different angle

Most vendors publish a trust center these days, and in that thread it was someone pointing at the vendor's trust center that unblocked the person asking. Start there and you'll fill five of those eight rows in an afternoon.

That last row is underrated. A vendor that won't give you a SOC 2 report will often hand over an ISO 27001 certificate or a pen test summary without blinking, because those don't carry the same distribution restrictions.

Then write the exception down

This is the step teams skip, and it's the one that decides whether the package holds.

The commenter in that thread who actually got certified described it plainly: they marked it as a known risk with a mitigation plan — upgrade to the tier that includes the report once revenue targets are hit in six months — and passed.

Auditors are not looking for a clean sheet. They're looking for a gap you found yourself, wrote down, and are managing. An undocumented gap is a finding. A documented gap with an owner and a date is a risk decision, which is a thing a functioning company is allowed to make.

Your exception record needs these fields:

The gap — "SOC 2 Type II report unavailable; vendor restricts distribution to Team plan and above."
What you did instead — the evidence package above, listed item by item.
Residual risk — what you still can't verify. Be honest here; a record that claims zero residual risk isn't credible.
Compensating controls — what reduces the risk in the meantime. Continuous availability monitoring, alerting, a documented failover or degradation path.
Owner — a named person.
Re-review trigger — a date, or a condition like "at renewal" or "when we cross the plan threshold."

Six fields. It fits on half a page, and that half page is the difference between an exception and a finding.

Where continuous monitoring fits — and where it doesn't

I build a vendor monitoring tool, so take this with the appropriate amount of salt. I'd rather be precise about the boundary than oversell it.

Continuous status monitoring produces exactly one row of that table: incident and status history, timestamped, running the length of the period you monitored. It's a compensating control on the availability dimension of vendor risk, and it maps to the ongoing-monitoring half of CC9.2 — the half that says you keep watching after onboarding, not just on day one.

That matters more than it sounds, because the recurring-review problem is real. A report you read once in March says nothing about what the vendor did in September. A monitoring record covers every day in between without anyone remembering to check.

It's also the one row on that list you cannot produce retroactively. You can request a DPA in an afternoon and write a shared-responsibility mapping in a morning. You cannot go back and observe what a vendor's status page said at 03:00 last February — either something was recording it or that period is gone.

Here's what it does not do, and I want this in writing:

It does not substitute for the SOC 2 report. If your auditor requires a Type II for a vendor handling regulated data, monitoring will not close that.
It does not tell you anything about their internal controls — encryption at rest, personnel screening, change management, access reviews. Availability is one dimension of vendor risk and not usually the scariest one.
It does not make the exception disappear. It's a line item under "compensating controls," not a replacement for the record.

If your critical vendor is a payments processor or holds PHI, and they won't produce a report, the honest answer is that you may have a vendor problem rather than an evidence problem.

Doing it in Statusfield

One row of that table is the one you can't reconstruct after the fact, and it's the row Statusfield exists to fill: timestamped incident and status history for every vendor, across the period you monitored them.

Concretely, that's a vendor inventory with criticality tags, a status record per vendor written as changes happen, an incident log with detection and resolution times, and alert-delivery records showing your team was actually notified — not just that an alert was configured.

The honest bound on that: the record starts the day you add the vendor, and history on the Team plan goes back a year. If your audit window opened before you started monitoring, the report states the period it actually covers rather than implying coverage it doesn't have. Which is the other reason to start before you need it.

That last one is the piece most teams can't produce. "We had alerts set up" is a screenshot; "the alert reached this person at 03:17 UTC" is evidence.

To be explicit, because this is a space where vague wording does real damage: Statusfield is not an auditor or a certification body. We don't certify you and we can't make you "SOC 2 compliant" — a SOC 2 attestation comes from a licensed CPA firm, an ISO 27001 certificate from an accredited body. We produce one input your auditor evaluates. Whether it satisfies a given control is their call.

You can export it as a PDF for the audit period or hand your auditor a share link. If you're building the exception record described above, it slots into the compensating-controls field and the incident-and-status-history row of the table.

See how the compliance reports work — they're on the Team plan, with a free trial. If you just want the monitoring and alerting without the report export, that starts on the free tier.

FAQ

Can I pass SOC 2 without a vendor's SOC 2 report? Generally yes, if you document why it's unavailable and what you did instead. Auditors deal with vendors that have no SOC 2 report constantly. What fails an audit is an undocumented gap, not a documented one with compensating controls, an owner, and a re-review date. Your auditor makes the final call, so raise it with them early rather than at fieldwork.

Why do vendors put their SOC 2 report behind a paid plan? Distribution is usually restricted by the report itself and by the vendor's own legal terms — SOC 2 reports are typically shared under NDA with customers, not published. Some vendors also use report access as a paid-tier feature. Neither is unusual, and it isn't necessarily a red flag about their security posture.

What's the difference between vendor due diligence and vendor monitoring? Due diligence is the assessment you do before and at onboarding — reports, contracts, security documentation. Monitoring is the ongoing evidence that you kept watching afterward. CC9.2 covers both, and teams that nail the first often have nothing for the second.

Does status page monitoring count as a compensating control? It can, for availability risk specifically, if the records are continuous and timestamped rather than reconstructed screenshots. It doesn't compensate for unverified security controls like encryption or access management. Describe it accurately in your exception record and let the auditor weigh it.

Should I switch vendors if they won't share their report? Rarely worth it on this alone. Migrating infrastructure to satisfy a document request usually costs far more in engineering time and new risk than documenting the exception. Revisit it if the vendor is critical, handles regulated data, and refuses every alternative form of assurance.

The Bottom Line

Ask for the report. Try the upgrade-and-downgrade route. Ask for the startup exception.

If all three fail, you don't have an audit blocker — you have a paragraph to write. Assemble what the vendor does publish, add your own continuous record of how they've actually behaved, write down the gap with an owner and a date, and bring it to your auditor before fieldwork instead of during it.

The teams that get burned here aren't the ones missing a PDF. They're the ones who left the gap undocumented and hoped nobody would ask.

Start monitoring your vendors free — no credit card required. Compliance report exports live on the Team plan when you need the audit artifact.

Going through your first SOC 2 and stuck on the vendor-monitoring evidence? Tell me what your auditor is asking for at support@statusfield.com — I answer these myself.

Your Vendor Won't Share Their SOC 2 Report. Here's What to Document Instead.