SOC 2 Vendor Assessment Guide

SOC 2 Type I evaluates whether controls are suitably designed at a specific point in time. It answers: "Does the vendor have appropriate controls in place?"

SOC 2 Type II evaluates whether controls operated effectively over a period of time, typically 6-12 months. It answers: "Did the controls actually work consistently?"

Type II is significantly more valuable for vendor assessment because it demonstrates sustained operational effectiveness, not just the existence of controls. When evaluating vendors, always request Type II. A vendor offering only Type I may be early in their compliance journey or may have operational gaps they haven't resolved.

Security (Common Criteria) — Required for all SOC 2 reports. Covers access controls, system monitoring, incident response, risk management, and change management. This is the baseline.

Availability — Addresses system uptime, disaster recovery, and business continuity. Critical for infrastructure and SaaS vendors where downtime impacts your operations.

Processing Integrity — Ensures data is processed completely, accurately, and in a timely manner. Important for payment processors, data pipelines, and analytics vendors.

Confidentiality — Protects confidential information through encryption, access restrictions, and data classification. Essential for vendors handling trade secrets, financial data, or strategic information.

Privacy — Governs collection, use, retention, and disposal of personal information per the entity's privacy notice. Critical for vendors processing customer PII.

When reviewing a vendor's SOC 2 report, focus on these areas:

Report date and period — Is the report current? A SOC 2 older than 12 months has limited value. Check the period covered and whether there is a gap between the report period end and today.

Scope and boundaries — Which systems and services are covered? Vendors may scope their SOC 2 narrowly to exclude the specific service you use.

Trust criteria included — Does the report cover criteria relevant to your use case? Security-only reports may be insufficient if you need availability or privacy assurance.

Exceptions and qualifications — Read the auditor's opinion. Any qualified opinion or noted exceptions require investigation. Ask the vendor how they remediated exceptions.

Complementary user entity controls (CUECs) — These are controls that the vendor expects you to implement. Failure to implement CUECs weakens the overall control environment.

Subservice organizations — Does the vendor rely on subprocessors? If so, are those subprocessors included in the SOC 2 scope or carved out?

A SOC 2 report has important limitations. It does not cover: sanctions risk, adverse media, financial stability, business legitimacy verification, domain security posture, network exposure, or subprocessor supply chain risk. A vendor with a clean SOC 2 can still be on sanctions lists, have open critical vulnerabilities, be involved in active litigation, or rely on subprocessors with poor security.

Comprehensive vendor assessment requires SOC 2 as one input among many. Independent investigation across sanctions databases, cyber risk indicators, regulatory filings, and public records provides the full picture that a SOC 2 alone cannot. For example, ThirdProof's investigation of Stripe covers SOC 2 certificate verification alongside sanctions screening, cyber risk scoring, and additional intelligence sources — all in a single automated assessment. The same applies to marketing platforms like HubSpot — where HubSpot SOC 2 compliance status should be verified alongside cyber risk and adverse media checks — and productivity suites like Google Workspace, where Google Workspace SOC 2 status matters for organizations processing sensitive data. For vendors in regulated industries, you should also consider FedRAMP authorization status and sanctions screening requirements.

To illustrate how autonomous investigation supports CC9.2 evidence, here is what ThirdProof found when investigating Stripe.

ThirdProof queried 22 intelligence sources in parallel and returned a Tier 4 — Low Risk rating at 98% confidence in under under 2 minutes. Key findings: sanctions screening cleared 5 potential matches against OFAC, EU, and UN lists — none confirmed. Domain reputation was clean across 93 security engines. SSL/TLS configuration scored A+. HTTP security headers scored A+ (105/100). Infrastructure exposure showed only 2 open ports with zero known CVEs. Three compliance certifications — SOC 2, SOC 1, and GDPR — were identified on Stripe's trust page and classified as vendor-attested (not independently verifiable through a public registry).

The recommended actions mapped directly to CC9.2 evidence requirements: obtain Stripe's PCI-DSS Level 1 Attestation of Compliance for the TPSP file, request the SOC 2 Type II report to convert the vendor-attested claim to independently verified, and execute a Data Processing Agreement under GDPR Article 28. Each action includes a specific timeline and compliance citation — exactly what your auditor needs to see in the vendor assessment file.

During SOC 2 fieldwork, your auditor will request evidence for CC9.2 (Risk Assessment of Third Parties). Here is what they expect to find in your evidence binder, and what they will test.

Risk register entry. Every vendor with data access should appear in your risk register with a risk tier, data classification, last assessment date, and next reassessment date. The auditor will sample 5-15 vendors and ask for the assessment file for each.

Assessment methodology documentation. A written policy describing how you evaluate vendors — what sources you check, how you assign risk tiers, and what thresholds trigger escalation. Deterministic, rule-based scoring is easier to defend than subjective analyst judgment.

Individual vendor assessment file. For each sampled vendor: the investigation report (PDF with source citations and SHA-256 hash), a list of findings with severity ratings, and documented recommended actions. ThirdProof's reports include all of these elements in a single audit-ready PDF.

Reviewer sign-off. Evidence that a human reviewed each assessment and documented their risk acceptance decision. ThirdProof's Review Certification page captures the reviewer's name, date, and decision — approve, approve with conditions, or reject.

Reassessment cadence. Documentation showing vendors are reassessed on a schedule proportional to their risk tier. Critical vendors annually, standard vendors every 18-24 months. The auditor will check whether reassessments actually happened on schedule.

CUECs are controls that a vendor's SOC 2 report explicitly expects your organization to implement. They appear in Section IV of the SOC 2 report and are easy to overlook — but your auditor will not overlook them. If you rely on a vendor's SOC 2 and fail to implement the CUECs, the control environment has a gap.

Common CUECs for widely-used vendors include: MFA enforcement — Okta and other identity providers expect you to enforce multi-factor authentication for all users accessing their platform. If your Okta tenant allows password-only login, the CUEC is unmet. Access deprovisioning — Slack expects you to deactivate user accounts promptly when employees leave. If terminated employees retain Slack access for weeks, you have a CUEC gap. API key rotation — Stripe expects you to rotate API keys periodically and restrict key permissions to minimum necessary scope.

For each vendor in your CC9.2 evidence file, document which CUECs apply and how your organization satisfies them. ThirdProof's recommended actions flag areas where CUECs are likely required based on the vendor's service type and data access level.

When your vendor relies on subprocessors (fourth parties), their SOC 2 report handles this in one of two ways.

Inclusive method. The vendor's SOC 2 scope includes the subservice organization's controls. The auditor tested both the vendor and its critical subprocessors. This gives you the most assurance but is uncommon — most vendors do not include their cloud provider's controls in their own SOC 2.

Carve-out method. The vendor's SOC 2 explicitly excludes subservice organization controls. The report states which services are carved out (typically AWS, GCP, or Azure) and notes that you should obtain separate assurance for those subprocessors. This is the standard approach for SaaS vendors.

When reviewing a vendor's SOC 2 with a carve-out, your CC9.2 evidence should document: which subprocessors are carved out, whether you have obtained separate SOC 2 reports for those subprocessors, and any compensating controls you rely on. ThirdProof's subprocessor discovery identifies published subprocessor lists and flags vendors with no visible subprocessor documentation — a common gap that auditors increasingly scrutinize.