SOC 2 Vendor Management: Third-Party Risk Requirements

Your SOC 2 report is only as strong as your weakest vendor. Every SaaS company relies on third parties — cloud infrastructure providers, payment processors, authentication services, monitoring tools, HR platforms. SOC 2 explicitly requires you to identify, evaluate, and monitor these relationships because a vendor’s security failure can become your security failure.

This isn’t theoretical. When a SaaS company suffers a breach through a compromised vendor, their SOC 2 report’s credibility is at stake. Auditors know this, which is why third-party risk management is one of the most thoroughly tested control areas in a SOC 2 engagement. If you can’t demonstrate that you manage vendor risk systematically, you’ll have findings in your report.

This guide covers the SOC 2 requirements for vendor management, how to build a program that satisfies auditors, and the specific pitfalls that trip up SaaS companies.

SOC 2 and Sub-Service Organizations

SOC 2 uses precise terminology. What you call “vendors” or “third parties,” the AICPA calls “sub-service organizations” — specifically, entities that provide services that are part of your system and relevant to your SOC 2 report scope.

Not every vendor is a sub-service organization. Your office coffee supplier doesn’t factor into your SOC 2 scope. But AWS, where your production environment runs? That’s a sub-service organization. Stripe, which processes your customers’ payments? Sub-service organization. Okta, which handles your authentication? Sub-service organization.

The distinction matters because SOC 2 requires you to address sub-service organizations in your system description, and you have two methods for doing so.

The Inclusive Method

What it means: The sub-service organization’s controls are included in the scope of your SOC 2 report. Your auditor examines both your controls and the vendor’s controls as part of a single engagement.

In practice: This is rare and complex. It requires the vendor’s full cooperation, your auditor’s access to the vendor’s systems, and significant coordination. Most SaaS companies never use the inclusive method because major vendors like AWS and Stripe aren’t going to grant your auditor direct access to their infrastructure.

The Carve-Out Method

What it means: The sub-service organization’s controls are excluded from your SOC 2 report scope, but the report acknowledges the dependency and references the vendor’s own SOC 2 report. You rely on the vendor’s independent SOC 2 attestation to cover their controls.

In practice: This is the standard approach for SaaS companies. You identify AWS as a sub-service organization, carve them out of your scope, and reference AWS’s own SOC 2 Type II report as evidence that their controls are adequate. Your system description explicitly states which controls are your responsibility and which are the vendor’s.

Your system description must clearly identify all sub-service organizations and state which method you’re using for each. Auditors will verify that this section is accurate and complete.

Relevant Common Criteria

Vendor management touches several areas of the SOC 2 Common Criteria. Understanding which criteria apply helps you build a program that maps directly to what auditors test.

CC2.3 — Communication with External Parties. Your organization must communicate with external parties — including vendors — about matters affecting the functioning of internal controls. This includes security requirements, incident notification expectations, and changes that affect service delivery.

CC3.1 through CC3.4 — Risk Assessment. Your risk assessment process must consider risks arising from third-party relationships. Vendor risk isn’t separate from organizational risk — it’s a component of it. Your risk register should include vendor-related risks, and your risk treatment plans should address them.

CC9.2 — Risk Mitigation. This criterion specifically addresses vendor and business partner risk. You must evaluate and manage risks associated with vendors who provide services that are part of your system. This includes ongoing assessment, not just initial due diligence.

Together, these criteria create a clear mandate: identify your vendors, assess their risk, communicate your expectations, and monitor them over time.

Building a Vendor Management Program

A SOC 2-compliant vendor management program has four phases: inventory, due diligence, contractual alignment, and ongoing monitoring. Each phase produces evidence that auditors will examine.

Step 1: Vendor Inventory

You can’t manage what you haven’t identified. Start with a complete inventory of every vendor that interacts with your systems or data.

How to build it: Work with engineering, IT, finance, and department leads to catalog every tool, service, and platform your organization uses. Finance records (invoices, subscriptions) are the most reliable source — they reveal vendors that individual teams adopted without centralized procurement.

Classify by risk level. Not every vendor carries the same risk. Assign risk levels based on data access, system criticality, and business impact:

• Critical: Vendors that host your production infrastructure, process customer data, or would cause significant business disruption if unavailable (AWS, GCP, your primary database provider)
• High: Vendors that access sensitive data or provide security-critical services (identity providers, monitoring tools, payment processors)
• Medium: Vendors that access internal data but not customer data (HR platforms, internal communication tools, project management software)
• Low: Vendors with no data access and minimal system interaction (office supplies, design tools with no data integration)

Common SaaS vendor categories to inventory:

• Cloud infrastructure: AWS, GCP, Azure
• Identity and access management: Okta, Auth0, Google Workspace
• Source control and CI/CD: GitHub, GitLab, CircleCI
• Monitoring and logging: Datadog, PagerDuty, Splunk
• Communication: Slack, Microsoft Teams
• Customer data processing: Stripe, Segment, Twilio
• HR and people operations: Rippling, Gusto, BambooHR
• Security tools: CrowdStrike, SentinelOne, Snyk

Shadow IT is the biggest gap in most vendor inventories. Engineering teams spin up SaaS tools with a credit card and never tell security. Finance reconciliation catches these, but you should also run periodic discovery scans of SSO logs, browser extensions, and OAuth application grants to find unauthorized tools.

Step 2: Vendor Due Diligence

Once you’ve inventoried your vendors, you need to evaluate each one’s security posture. The depth of due diligence should match the vendor’s risk level.

For critical and high-risk vendors:

• Request their SOC 2 Type II report. This is the gold standard. A current SOC 2 Type II report means an independent auditor has evaluated the vendor’s controls over a period of time. Type II is preferred over Type I because it demonstrates sustained operational effectiveness, not just point-in-time design.
• Review the report thoroughly. Don’t just confirm it exists. Read the auditor’s opinion, check for qualifications or exceptions, review the control descriptions, and — critically — read the Complementary User Entity Controls (CUECs). CUECs are controls that the vendor expects you to implement. If AWS says encryption is a customer responsibility, that’s a CUEC, and your auditor will check whether you’ve implemented it.
• Evaluate security questionnaires. For vendors without SOC 2 reports, use standardized questionnaires like SIG (Standard Information Gathering), CAIQ (Consensus Assessments Initiative Questionnaire), or your own custom questionnaire covering encryption, access controls, incident response, and data handling.
• Review sub-processors. Your vendor’s vendors matter too. Check whether the vendor discloses their sub-processors and how they manage sub-processor risk. This is especially relevant if you’re also subject to GDPR, which has explicit sub-processor requirements.
• Assess business continuity. Understand the vendor’s disaster recovery capabilities, SLA commitments, and historical uptime. A critical vendor without adequate DR puts your availability at risk.

For medium-risk vendors:

• Request a SOC 2 report or ISO 27001 certificate
• Send a security questionnaire
• Review their public security page and privacy policy

For low-risk vendors:

• Confirm basic security practices (HTTPS, authentication)
• Document the risk acceptance rationale for reduced due diligence

Document every assessment. Auditors need to see that you performed due diligence for each vendor in scope, and the depth of assessment should correspond to the risk classification.

Step 3: Contractual Requirements

Due diligence evaluates a vendor’s current security posture. Contracts enforce ongoing obligations. Your vendor agreements should include specific security and compliance provisions.

Security requirements. Contracts with critical and high-risk vendors should specify security expectations: encryption standards, access control requirements, vulnerability management obligations, and compliance with relevant frameworks.

Data Processing Agreements. If the vendor processes personal data — especially if you have customers in the EU — you need a Data Processing Agreement (DPA). This is both a SOC 2 best practice and a GDPR requirement. DPAs should specify data processing purposes, security measures, sub-processor constraints, and data deletion obligations.

Right to audit. Include contractual provisions that give you the right to audit the vendor’s security practices or request evidence of compliance. For large vendors (AWS, Google), their SOC 2 report serves this purpose. For smaller vendors, you may need the ability to conduct direct assessments.

Incident notification. Require vendors to notify you of security incidents within a defined timeframe — 24 to 72 hours is standard for critical vendors. Specify what constitutes a reportable incident and the notification method.

Data handling and deletion. Define how the vendor stores, processes, and ultimately deletes your data. Include retention limits and require confirmation of data deletion upon contract termination. This is particularly important for vendors processing customer data.

Step 4: Ongoing Monitoring

Initial due diligence is not enough. SOC 2 requires ongoing monitoring of your vendor relationships, and auditors will test whether you actually conducted monitoring activities during the observation period.

Annual SOC 2 report review. For critical and high-risk vendors with SOC 2 reports, review the updated report annually when it’s published. Check for new exceptions, changes in scope, or modified CUECs. Document the review with the reviewer’s name, date, and findings.

Track vendor security incidents. Monitor for public disclosures of vendor breaches or security incidents. Subscribe to vendor security bulletins and status pages. When a vendor has an incident, document your assessment of the impact on your systems and data.

Monitor material changes. Watch for vendor acquisitions, leadership changes, sub-processor additions, and significant service changes. Any of these can affect the vendor’s risk profile and may require reassessment.

Periodic reassessment. Reassess vendors based on their risk level:

• Critical: Annual comprehensive review with updated SOC 2 report, contract review, and sub-processor check
• High: Annual SOC 2 report review and questionnaire update
• Medium: Biennial review or triggered by material changes
• Low: Review only when triggered by changes or incidents

What Auditors Test

During a SOC 2 engagement, your auditor will examine vendor management across several dimensions. Knowing what they test helps you prepare.

Vendor inventory completeness. Auditors will compare your vendor inventory against other evidence sources — financial records, system configurations, SSO logs — to verify you’ve identified all relevant vendors. Missing a critical vendor is a significant finding.

Evidence of due diligence. For critical vendors, auditors expect to see documented assessments: SOC 2 report reviews with notes, completed security questionnaires, and risk classification justifications. A vendor classified as critical with no due diligence record is a control failure.

SOC 2 report reviews. Auditors will verify that you actually read vendor SOC 2 reports — not just collected them. They’ll ask who reviewed the report, when, what the conclusions were, and whether CUECs were evaluated. Storing a PDF you never opened doesn’t satisfy the requirement.

Contractual agreements. Auditors will sample vendor contracts and check for security provisions, DPAs, and incident notification clauses. This is especially thorough for vendors processing customer data.

Monitoring activities. For Type II reports, auditors need evidence of ongoing monitoring across the observation period. An annual review that happened in month one with no follow-up for the remaining eleven months may be insufficient depending on the vendor’s risk level and your policy commitments.

Common Pitfalls

SaaS companies consistently stumble in the same areas of vendor management. Knowing these pitfalls helps you avoid them.

Not tracking all vendors. Shadow IT is the biggest offender. Engineering teams adopt SaaS tools, connect them via OAuth, and never loop in security. These tools may access source code, customer data, or internal communications — and they’re invisible to your vendor management program. Regular OAuth grant audits and SSO log reviews catch most of these.

Accepting SOC 2 Type I when Type II is available. A Type I report is a point-in-time snapshot — it tells you controls were designed correctly on a single date. A Type II report proves those controls operated effectively over months. If a vendor has a Type II available, always request it. Settling for Type I when Type II exists signals to auditors that your due diligence process isn’t thorough.

Not reviewing Complementary User Entity Controls. CUECs are the controls a vendor expects you to implement on your end. AWS’s SOC 2 report, for example, lists CUECs around encryption key management, network security, and access controls. If you rely on AWS but haven’t implemented their CUECs, there’s a gap in your control environment that auditors will identify.

Missing vendors added mid-audit period. If you onboard a new critical vendor during your observation period, that vendor needs to go through your due diligence process and appear in your inventory. Auditors are looking at the full observation period, not just a snapshot at the end.

No process for vendor offboarding. When you stop using a vendor, you need to revoke their access, confirm data deletion, and update your vendor inventory. Vendors with lingering access to your systems after contract termination are a security risk and an audit finding.

Treating vendor management as an annual project. Vendor management is continuous. If your entire program consists of a once-a-year review sprint before audit season, you’ll have gaps. Material vendor changes, new vendor onboarding, and incident monitoring need to happen in real time throughout the year. Linking vendor management to your continuous monitoring program makes this sustainable.

How GRCTrail Helps

GRCTrail gives SaaS teams a structured, auditable vendor management program that satisfies SOC 2 requirements without sprawling spreadsheets.

• Centralized vendor registry with risk classification, so every vendor is inventoried, categorized, and trackable in one place
• SOC 2 report collection and review tracking that records who reviewed each vendor’s report, when, and what they found — giving auditors the evidence trail they need
• Automated reminders for annual reviews triggered by vendor risk level, so critical vendor reviews never slip past their due date
• Contract and DPA management linked to each vendor record, making it easy to verify that contractual provisions are in place for every in-scope relationship
• Sub-processor change monitoring that alerts you when vendors update their sub-processor lists, so you can reassess risk before your auditor asks about it

Get started with GRCTrail →

Related Guides

• What Is SOC 2? A Practical Guide for SaaS Companies
• SOC 2 Policies and Procedures: What You Need to Document
• SOC 2 Risk Assessment Guide
• GDPR Data Processing Agreements: A Complete Guide
• ISO 27001 Supplier Management: Third-Party Risk Requirements