Vendor Risk Management for SOC 2: What You Need Before Audit Day

The SaaS Company's Dirty Secret

Most SaaS companies use 50-100 SaaS tools. Most of those tools touch some data — either employee data, company data, or customer data.

When Orion sat down to catalogue their vendor landscape, they found 83 active SaaS subscriptions. Slack. Notion. Figma. GitHub. AWS. Stripe. Intercom. HubSpot. Zoom. Linear. The list went on.

The question is: how many of those vendors need to be in your SOC 2 vendor risk program?

The answer, for most companies: far fewer than you think — but the ones that matter, really matter.

What CC9.2 Actually Requires

The control requires that you assess and manage risks associated with vendors and business partners who provide services that are material to your in-scope service.

The key word is material. Not every vendor matters for SOC 2. The control is focused on vendors whose failure or compromise could affect the security, availability, or confidentiality of your in-scope service.

The Three Tiers of Vendor Risk

Tier 1: Critical / Subservice Organizations

These are vendors whose services are integral to your in-scope product. If they have a security incident or outage, your customers are directly impacted.

Typical examples for cloud SaaS companies:

• AWS / GCP / Azure (cloud infrastructure)
• Okta / Azure AD / Auth0 (identity and access)
• Stripe / Razorpay (payment processing)
• Cloudflare (CDN and DDoS protection)
• GitHub / GitLab (source code and deployment pipeline)

What you need for Tier 1:

• Their current SOC 2 Type II report (or equivalent — ISO 27001 certificate, FedRAMP authorization)
• Documented in your vendor risk register
• Annual review cadence

The good news: Major cloud vendors all have comprehensive SOC 2 programs. AWS, GCP, and Azure are carve-out subservice organizations in your report — you don't audit them, you reference their reports.

Tier 2: High Risk Vendors

These are vendors that access or process your customer data, but aren't core infrastructure.

Examples:

• Customer support tools with access to ticket content (Intercom, Zendesk)
• Analytics platforms that receive event data (Mixpanel, Amplitude)
• Error monitoring that captures user context (Sentry, Datadog)
• Communication tools that store business data (Slack)

What you need for Tier 2:

• Evidence that they have reasonable security practices (SOC 2 report preferred, or security page with explicit data handling commitments)
• Review of their data processing agreement or security addendum
• Annual review

Tier 3: Low Risk Vendors

Everything else — tools used for internal productivity that don't touch customer data.

Examples: Figma, Notion, Canva, HubSpot (if CRM data is not customer platform data), most marketing tools.

What you need for Tier 3: You don't need to formally assess these. Simply document that they're excluded from your vendor risk program and explain why (no access to in-scope customer data).

Orion's Vendor Risk Register

After categorization, Orion's Tier 1 and Tier 2 vendor list looked like this:

| Vendor | Category | Why In Scope | Evidence Collected | Review Date | |---|---|---|---|---| | AWS | Tier 1 | Cloud infrastructure | AWS SOC 2 Type II (2024) | Annual | | Okta | Tier 1 | Identity provider | Okta SOC 2 Type II (2024) | Annual | | GitHub | Tier 1 | Code and deployment | GitHub SOC 2 Type II (2024) | Annual | | Stripe | Tier 1 | Payment processing | Stripe SOC 2 Type II (2024) | Annual | | Cloudflare | Tier 1 | CDN / DDoS | Cloudflare SOC 2 (2024) | Annual | | Intercom | Tier 2 | Customer data in support tickets | SOC 2 Type II report obtained | Annual | | Sentry | Tier 2 | Error monitoring with user context | SOC 2 Type II report obtained | Annual | | Datadog | Tier 2 | Infrastructure monitoring | SOC 2 Type II + ISO 27001 | Annual |

That's 8 vendors — out of 83 active subscriptions. The other 75 were classified as Tier 3 and excluded from the formal vendor risk program.

How to Get SOC 2 Reports From Vendors

Most major vendors don't publicly post their SOC 2 reports (they're business documents with sensitive information). Here's how to get them:

1. Trust portal: Most large vendors now have a trust center (trust.aws.com, security.okta.com, etc.) where you can download or request the report.

2. NDA request: Send an email to the vendor's security team asking for their SOC 2 report under NDA. Most respond within a week.

3. Vendor questionnaire: If the vendor doesn't have a SOC 2, send them a shortened security questionnaire (CAIQ lite or similar) and assess their responses.

What Auditors Test for CC9.2

Expect the auditor to ask:

• "Provide your vendor risk register including all Tier 1 and Tier 2 vendors."
• "Provide evidence of vendor security assessments for your critical vendors."
• "When were these assessments completed?"
• "Are there contracts in place with these vendors that include security or data processing requirements?"

The contract angle: Your vendor contracts (or Data Processing Agreements) should include language about: data security obligations, breach notification requirements, and data deletion upon contract termination. Most major vendors have DPA templates — sign theirs or insist on equivalent protections.

The Minimum Viable Vendor Program

If you're starting from zero, here's the minimum you need before your audit:

1. Vendor inventory — List of all in-scope vendors (Tier 1 and 2) with name, what they do, and why they're in scope.

2. SOC 2 reports collected — Current SOC 2 Type II (or equivalent) report from each Tier 1 vendor. For Tier 2, at minimum a security page review and DPA.

3. Vendor risk register — A spreadsheet or tool tracking each vendor, their risk tier, evidence collected, and last review date.

4. Contracts with security clauses — At minimum, your master service agreements with Tier 1 vendors should reference security obligations.

What Comes Next

You now have your controls operating, your evidence collected, your vendors documented. But what holds it all together? Policies. In the next post, we cover how to write SOC 2 policies that are actually usable — not just compliance theatre.