How to Verify a Vendor's SOC 2 Compliance

SOC 2 is the most commonly cited compliance credential in SaaS sales conversations, but it's also one of the most frequently misrepresented. There's no central authority that publishes a list of SOC 2 compliant companies. The AICPA, which developed the SOC framework, does not maintain a registry. This means anyone can claim SOC 2 compliance on their website without independent verification.

The problem is compounded by confusion between SOC 2 Type I and Type II reports. A Type I report evaluates the design of controls at a single point in time. A Type II report evaluates the operating effectiveness of those controls over a period — typically 6 to 12 months. A vendor with a Type I report has demonstrated that their controls are designed appropriately, but hasn't proven they actually work consistently. Many vendors cite "SOC 2 compliance" when they only hold a Type I, or when their report has expired.

For your TPRM program to satisfy audit requirements — particularly SOC 2 CC9.2, which governs vendor risk management — you need documented evidence that you verified each vendor's compliance claims. A checkbox on an intake form isn't sufficient. You need a repeatable process that produces artifacts your auditors can review.

The most reliable verification method is requesting a copy of the vendor's SOC 2 Type II report. This is the full audit report produced by their CPA firm, and it contains everything you need to evaluate their compliance posture. Most vendors will share this under NDA, since the report contains detailed information about their control environment.

When you request the report, be specific. Ask for the most recent SOC 2 Type II report, the period it covers, the Trust Services Criteria in scope (Security, Availability, Processing Integrity, Confidentiality, Privacy), and whether there's a bridge letter covering any gap between the report period and today. A vendor that can produce all of this promptly is a good sign. A vendor that stalls, redirects you to a marketing page, or offers a Type I report instead warrants closer scrutiny.

Once you have the report, you'll need to read it carefully — not just confirm it exists. Pay attention to the auditor's opinion, any exceptions noted, the scope of systems covered, and the Complementary User Entity Controls (CUECs) that define your responsibilities as the customer.

Document the date you requested the report, the date you received it, who reviewed it, and the key findings. This documentation trail is exactly what your auditors will look for during your own SOC 2 examination.

Several platforms aggregate vendor compliance information and can accelerate the verification process. Services like ThirdProof scan vendor trust pages, cross-reference certification claims against public registries where they exist, and flag discrepancies between what a vendor claims and what can be independently verified.

The advantage of using a third-party platform is consistency and speed. Instead of manually requesting reports from every vendor and tracking follow-up emails, you get a standardized risk profile that distinguishes between independently verified certifications and vendor self-attestations. ThirdProof, for example, labels evidence as "Independently Verified" when it can be confirmed through public registries or audit reports, and "Vendor Attested" when the only source is the vendor's own website.

This distinction matters because it directly maps to the level of assurance your auditors will assign. An independently verified SOC 2 report carries full weight. A vendor's claim on their security page, without supporting evidence, carries significantly less. Having a platform that makes this distinction automatically saves your team from making judgment calls on every vendor.

Platforms also provide continuous monitoring — if a vendor's trust page changes, or if their compliance claims are updated, you'll know without waiting for the next annual review cycle.

Many vendors publish a trust or security page — often at domains like trust.vendor.com or vendor.com/security — that lists their compliance certifications, links to audit reports, and provides details about their security program. Scanning these pages is a useful starting point, but it shouldn't be your only verification method.

Trust pages are marketing materials. They're maintained by the vendor and reflect what the vendor wants prospects to see. That doesn't mean they're inaccurate, but it does mean you're relying on self-attestation. Look for specific details: the name of the auditing firm, the report period, the Trust Services Criteria covered, and whether they offer direct access to reports through a portal or upon request.

Some vendors use trust platforms like Vanta Trust, Drata Trust Center, or SafeBase to publish their compliance posture. These platforms add a layer of credibility because the data is typically pulled from the vendor's actual compliance tooling, but they're still vendor-controlled. The vendor chooses what to publish and what to withhold.

For vendors like Stripe, Dropbox, and Datadog, trust pages are well-maintained and typically provide access to SOC 2 reports through a request workflow. For smaller vendors, the trust page may be sparse or outdated. When the trust page doesn't give you enough confidence, escalate to a direct report request.

If your organization is pursuing its own SOC 2 compliance, you're subject to Common Criteria 9.2 (CC9.2), which requires you to assess and manage risks associated with vendors and business partners. This isn't optional — it's a control point your auditors will evaluate.

CC9.2 requires that you have a process for evaluating the risks of third-party service providers, that you monitor their compliance on an ongoing basis, and that you document your assessments. The key phrase is "ongoing basis" — a one-time check at vendor onboarding isn't sufficient. Your auditors want to see evidence of periodic reassessment, typically annually.

What counts as adequate documentation? At minimum: a vendor inventory that identifies which vendors are in scope for your SOC 2, the date of your most recent assessment for each vendor, the compliance certifications you verified, any risks identified, and how those risks were addressed. If a vendor doesn't have a SOC 2, you need to document what alternative controls or risk mitigations you've put in place.

This is where many organizations stumble. They have a vendor list, but no documented assessment process. Or they assessed vendors at onboarding but never reassessed. Building a repeatable verification workflow — whether manual or through a platform like ThirdProof — ensures you can demonstrate compliance with CC9.2 at any point during your audit window.

Not all SOC 2 claims are created equal. Here are the specific red flags that should trigger additional scrutiny during your verification process.

Type I presented as full compliance. A SOC 2 Type I report is a starting point, not a finish line. If a vendor only has a Type I and has been operating for more than a year, ask why they haven't progressed to Type II. There may be a valid reason — they may be in their first audit cycle — but it's worth understanding.

Expired reports. SOC 2 reports cover a specific period, typically 12 months. If the most recent report ended more than 15 months ago and there's no bridge letter, the vendor's current control environment is unverified. Ask for their re-audit timeline.

Scope gaps. A SOC 2 report covers specific systems and Trust Services Criteria. If you're relying on a vendor for data processing but their SOC 2 only covers the Security criterion and not Confidentiality or Processing Integrity, there's a scope gap. Similarly, if the report covers their primary product but you're using a different product line, the report may not apply to your use case.

Reluctance to share. A vendor that refuses to share their SOC 2 report — even under NDA — is a significant red flag. The report exists to be shared with customers and their auditors. If the vendor won't provide it, document that refusal and escalate the risk assessment.

No auditor named. Legitimate SOC 2 reports are issued by CPA firms registered with the AICPA. If the vendor can't name their auditor, or if the auditing firm isn't a recognized CPA firm, treat the claim with skepticism.