SOC 221 April 2026 7 min read

SOC 2 Vendor Management: How to Handle Third-Party Risk

SOC 2 CC9.2 requires assessing and monitoring third-party vendors. Learn how to build a vendor management program that satisfies auditors without overwhelming your team.

Key Takeaways

CC9.2 requires assessing third-party vendors before granting access to customer data or critical systems.
Not all vendors need equal assessment depth — tier vendors by risk level and apply proportionate due diligence.
Downloading and reviewing a vendor's SOC 2 report is the standard assessment method for Tier 1 vendors.
A vendor inventory with review dates is the primary evidence — auditors want to see the list and proof of annual review.
Data Processing Agreements (DPAs) are required for any vendor processing personal data — both for SOC 2 CC9.2 and GDPR/DPDP compliance.

In this guide

What CC9.2 Actually Requires
Vendor Tiering: Not All Vendors Are Equal
Assessing Tier 1 Vendors (Critical Access)
Assessing Tier 2 and Tier 3 Vendors
Ongoing Vendor Monitoring
Vendor Contracts and Data Processing Agreements

What CC9.2 Actually Requires

CC9.2 requires that the entity assesses and manages risks from third-party vendors and business partners. The requirement has three components: (1) identifying which vendors have access to in-scope systems or customer data, (2) assessing each vendor's security posture before granting access, and (3) monitoring vendors on an ongoing basis for security changes.

The standard does not specify how detailed the assessment must be — only that it is commensurate with the risk. A vendor with read-only access to non-sensitive internal data warrants less scrutiny than a vendor processing customer PII or with privileged access to your production infrastructure.

CC9.2 is one of the most commonly found gaps in first-time assessments because vendor management is invisible to engineering teams. Developers add SaaS tools frequently and without security review. By the time of the first audit, a 20-person startup may have 30–50 SaaS vendors with some level of access to company systems, none of which have been formally assessed.

Vendor Tiering: Not All Vendors Are Equal

Tier 1 (Critical): vendors with access to customer data or privileged access to production systems. Examples: AWS, Okta, Stripe, Salesforce (if it stores customer contacts), Intercom (if support agents access customer data), GitHub (source code and deployment). These vendors require the most thorough assessment — typically reviewing their SOC 2 report, assessing their security practices, and including security clauses in contracts.

Tier 2 (Significant): vendors with access to internal company data (not customer data) or with the ability to affect service availability. Examples: Slack, Google Workspace, Zoom, Jira. These vendors warrant a standard security questionnaire or review of their published security documentation and policies.

Tier 3 (Standard): vendors with no access to company data and no ability to affect service availability. Examples: marketing analytics tools (if not integrated with customer data), design tools like Figma, HR benefits platforms. Standard contractual terms and a brief review of their privacy policy is typically sufficient.

Assessing Tier 1 Vendors (Critical Access)

For Tier 1 vendors, the standard assessment method is reviewing their SOC 2 Type II report. Download the report from their trust portal, verify it covers the relevant Trust Service Criteria (Security at minimum), check that the observation period is current (within the last 12 months), review the auditor's opinion section for qualifications or exceptions, and note any exceptions that are relevant to your use case.

Record the review in your vendor inventory: vendor name, service provided, data/access level, SOC 2 report date, SOC 2 observation period, opinion (unqualified/qualified), relevant exceptions noted, review date, and next review date. This record is your CC9.2 evidence. Auditors will sample 3–5 vendors from your inventory and ask for the supporting documentation.

For Tier 1 vendors that don't have a SOC 2 report (uncommon for large vendors, more common for specialized tools), use a security questionnaire (SIG Lite, CAIQ, or a custom questionnaire). The completed questionnaire, signed by the vendor's security contact, serves as the assessment evidence. If the vendor refuses to complete a questionnaire, treat that as a risk flag and document your risk acceptance or vendor replacement decision.

Assessing Tier 2 and Tier 3 Vendors

For Tier 2 vendors, a lighter-weight assessment is acceptable. Review their published security documentation (security page, trust center), note their certification status (SOC 2, ISO 27001), review their privacy policy for data processing disclosures, and record the review date in your vendor inventory. This review takes 15–30 minutes per vendor and satisfies CC9.2 proportionality for non-critical vendors.

For Tier 3 vendors, a brief review of their privacy policy and a confirmation that they don't access customer data is typically sufficient. The key documentation is simply having them listed in the vendor inventory with their access classification.

Annual re-assessment is required for all tiers. The cadence can be lighter for lower tiers: Tier 1 vendors should have their SOC 2 report refreshed annually (download new report, note any new exceptions); Tier 2 vendors should have a brief documentation review; Tier 3 vendors should be confirmed as still active and still appropriately classified.

Ongoing Vendor Monitoring

CC9.2 requires ongoing monitoring, not just initial assessment. Ongoing monitoring means: subscribing to vendor security notifications (most major vendors publish a security mailing list or status page), reviewing vendors' annual SOC 2 report updates, being alerted to vendor security incidents, and re-assessing when vendors significantly change their service offering or data access scope.

When a vendor has a major security incident, you need evidence that you were aware of it and assessed the impact on your systems. Your vendor management process should include an incident response step: when a critical vendor reports a security incident, investigate whether your systems or customer data was affected, notify customers if required, and document your investigation and response.

Vendor off-boarding is also part of ongoing monitoring. When you stop using a vendor, their access to your systems must be revoked and any data they held must be deleted per your retention agreements. Failure to offboard vendors leaves stale access paths that auditors will flag.

Vendor Contracts and Data Processing Agreements

CC9.2 requires that vendor relationships are governed by contracts that include security requirements. At minimum, vendor contracts for Tier 1 and Tier 2 vendors should include: confidentiality provisions, security incident notification requirements (notification within 72 hours is the GDPR standard and is often expected by enterprise buyers), data handling restrictions (use only for the agreed purpose), right to audit or receive audit reports, and data deletion upon contract termination.

For any vendor processing personal data, a Data Processing Agreement (DPA) is required — both for SOC 2 Privacy (if in scope) and for GDPR and DPDP Act compliance. The DPA should identify the categories of personal data processed, the purpose and legal basis, sub-processor arrangements, and the vendor's security obligations.

Major vendors like AWS, Stripe, and Google provide standard DPA templates. For smaller vendors, you may need to negotiate DPA terms. Document the existence and execution date of the DPA in your vendor inventory — auditors will ask for DPA evidence for vendors processing personal data.

Frequently Asked Questions

How many vendors does a typical startup need to assess for SOC 2?

Most 10–50 person startups discover 20–50 SaaS vendors in their initial inventory. Of these, 5–15 typically qualify as Tier 1 (critical, requiring SOC 2 report review), 10–20 as Tier 2 (significant, requiring documentation review), and the remainder as Tier 3. The initial inventory and tiering exercise typically takes 4–8 hours for one person doing it for the first time.

What if our critical vendor doesn't have a SOC 2 report?

Request a security questionnaire (SIG Lite is the standard for technology vendor assessments). If the vendor refuses or provides unsatisfactory answers, you have three options: accept the risk with documented justification, implement compensating controls (like restricting the vendor's data access or adding monitoring), or replace the vendor. Document your risk decision in the vendor record. Auditors expect to see risk acceptance documentation for vendors without SOC 2 reports.

Does our law firm or accounting firm need a SOC 2 assessment for CC9.2?

Professional services firms (lawyers, accountants) that receive confidential information typically have professional privilege and duty of confidentiality obligations that serve as their security commitment, rather than SOC 2 reports. For CC9.2, documenting that these firms are engaged under professional services agreements with confidentiality obligations is typically sufficient. They would be Tier 2 vendors in most assessments.

Can we use a standard security questionnaire template for all vendors?

Yes — standard questionnaire templates like the SIG Lite (from Shared Assessments) or CAIQ (from the Cloud Security Alliance) are widely used and recognized. For Tier 1 vendors who have SOC 2 reports, a questionnaire is often redundant — the SOC 2 report already provides a more thorough assessment. Use questionnaires primarily for Tier 1 vendors without SOC 2 reports and as a supplement for vendors with known gaps in their SOC 2 reports.

How do we handle vendors added after the start of the observation period?

New vendors added during the observation period must be assessed before they are granted access to in-scope systems or customer data. This is the CC9.2 timing requirement — assessment is "before granting access," not "within 30 days of granting access." Document the assessment date relative to the access grant date to demonstrate compliance. A common compliance automation workflow: vendor assessment is a required step in the procurement workflow, triggered whenever a new SaaS tool is being onboarded.