What SOC 2 Requires for Vendor Risk

CC9.2 of the SOC 2 Trust Services Criteria requires that you assess, monitor, and manage risks associated with third-party vendors and partners — specifically those who have access to or can affect your systems, data, or customers.

This is one of the more open-ended SOC 2 requirements. Unlike IAM configuration where there's a right answer, vendor risk management is about having a documented process and evidence that you followed it. Your process doesn't need to be complex — it needs to exist, be written down, and be executed.

Step 1 — Build Your Vendor Inventory

Before you can manage vendor risk, you need to know which vendors you have. For a typical SaaS company, this includes:

• Cloud providers (AWS, Azure, GCP) — your most critical dependencies
• SaaS tools with customer data access (Salesforce, Intercom, Zendesk, HubSpot)
• Developer tools with production access (GitHub, CI/CD platforms, monitoring tools)
• Payment processors (Stripe, Braintree)
• HR/payroll tools with employee data (Rippling, Gusto, Deel)
• Subcontractors or third-party developers with code or infrastructure access

Create a vendor inventory spreadsheet with columns for: vendor name, service type, data access level (what customer/employee data can they see?), contract status, and last review date.

Step 2 — Classify Vendors by Risk Level

Not every vendor requires the same level of scrutiny. Classify by data sensitivity and criticality:

High Risk:

• Vendors with access to customer PII or sensitive business data
• Vendors who could cause service disruption if their service fails
• Vendors with production infrastructure access

Required for high-risk vendors: SOC 2 Type II report (or equivalent), signed DPA, annual review.

Medium Risk:

• Vendors with access to internal business data (not customer data)
• Vendors whose failure would be disruptive but not catastrophic

Required for medium-risk vendors: SOC 2 or security questionnaire, signed NDA, annual review.

Low Risk:

• Vendors with no data access or access to only anonymized/aggregated data
• Vendors whose failure would be inconvenient but not materially harmful

Required for low-risk vendors: brief review, standard contract terms.

Step 3 — Obtain and Review Security Documentation

For high and medium-risk vendors:

Preferred documentation: SOC 2 Type II report from the vendor. This is the gold standard — a licensed CPA firm already validated their controls. Your job is to read the report, check the observation period (is it current?), and note any exceptions or qualifications.

If no SOC 2: Send a security questionnaire. Use an established format like the SIG (Standardized Information Gathering) questionnaire or a shorter self-assessment covering the domains you care about (access control, encryption, incident response, BC/DR). Review responses and follow up on gaps.

For AWS: AWS's SOC 2 report is publicly available. Include a statement in your documentation acknowledging the Shared Responsibility Model — AWS secures the physical and hypervisor layers, you're responsible for configuration. This satisfies auditors who ask how you assess your largest cloud vendor.

Step 4 — Required Contracts

Every high-risk vendor should have a signed contract that includes:

• Data Processing Agreement (DPA) — if they process personal data (required under GDPR for EU data subjects)
• Security addendum — minimum security requirements they must maintain (encryption, access control, breach notification)
• Breach notification requirement — typically 72 hours or less for notification to you

Check your existing vendor contracts. Many SaaS companies have no data processing addenda with their largest vendors — this is a common gap auditors find.

Step 5 — Annual Review Cadence

Review all high-risk vendors annually:

Pull their latest SOC 2 report or security questionnaire responses

Verify no new critical exceptions or significant changes to their control environment

Confirm the vendor relationship still makes sense from a risk perspective

Update your vendor inventory with the review date and reviewer

Document any issues found and actions taken

Annual reviews should be scheduled calendar events, not ad-hoc scrambles before an audit. For a SOC 2 Type II with a 12-month observation period, you need evidence of at least one full cycle of reviews.

What Auditors Specifically Test

Auditors will request your vendor inventory, ask to see SOC 2 reports for your top vendors, review one or two vendor contracts, and verify your review process ran during the audit period. They're checking:

Do you know who your vendors are?

Are the riskiest ones documented?

Did you review them during the observation period?

Do your contracts include adequate data protection terms?

They're not asking you to have zero risk — they're asking you to have managed risk.