# SOC 2 Vendor Management: The Third-Party Risk Program Auditors Actually Test

> SOC 2 vendor management explained — how CC9.2 governs third-party risk, vendor vs. subservice organizations, tiering, due diligence, CSOCs, and the evidence auditors test.

- Canonical: https://auditsuisse.com/vendor-management-for-soc-2-compliance
- Language: en
- Author: Sébastien Ruosch, CPA — Director of Audits
- Published: 2026-02-22
- Updated: 2026-10-18

SOC 2

A CPA firm's guide to criterion CC9.2 — how to inventory, tier, vet, contract, and monitor third parties, and how vendors differ from the subservice organizations that appear in your report.

 The short answer

**SOC 2 vendor management** is how you satisfy Trust Services Criterion **CC9.2**: “The entity assesses and manages risks associated with vendors and business partners.” In practice that means a complete vendor inventory, risk-based tiering, tier-appropriate due diligence, contract controls, and ongoing monitoring. A special subset of vendors — **subservice organizations** like your cloud host — also require **CSOCs** in your report and continuous monitoring of their SOC 2.

## Key takeaways

- **CC9.2 is the governing criterion.** It requires you to both *assess* and *manage* vendor and business-partner risk — supported by CC2.3, CC3.2, CC3.4, and (when Privacy is in scope) P6.4 and P6.5.
- **A subservice organization is not the same as a vendor.** Only subservice organizations — whose controls are *necessary* to meet your commitments — get carve-out or inclusive treatment and require CSOC disclosure under DC7.
- **Tier before you assess.** Match diligence to risk: a current SOC 2 Type II from critical vendors that touch production data; lighter attestations for low-risk vendors reviewed at renewal.
- Acceptable report age and any bridge-letter interval are set by the recipient's requirements and risk assessment; a bridge letter does not add auditor-tested coverage.

## What SOC 2 requires for vendor management (CC9.2 in plain English)

CC9.2 is the primary Trust Services Criterion for third-party risk. Its text is short and worth quoting exactly: **“The entity assesses and manages risks associated with vendors and business partners.”** Two verbs carry the weight. *Assess* means you understand what each vendor does, what data it touches, and what could go wrong. *Manage* means you act on that assessment — through contracts, monitoring, and remediation — on a continuing basis, not once at onboarding.

CC9.2 does not stand alone. When auditors test vendor management, they read it alongside several supporting criteria that describe how third-party risk connects to your broader control environment. The Privacy criteria (P6.4 and P6.5) apply **only when the Privacy category is in scope**; the CC criteria apply to every SOC 2 engagement because they sit within the Common Criteria. You can see how CC9.2 fits [CC9.2 within the full Trust Services Criteria](https://auditsuisse.com/soc-2-controls-list-by-trust-services-criteria) in our controls list.

CC9.2 and the criteria auditors map to vendor management

| Criterion | What it addresses | Vendor-management connection |
| --- | --- | --- |
| CC9.2 | Assessing and managing risks from vendors and business partners | The primary criterion — the whole program hangs here |
| CC2.3 | Communicating with external parties on matters affecting internal control | Contractual obligations, breach notifications, and control commitments exchanged with vendors |
| CC3.2 | Identifying and analyzing risks to objectives | Provides the basis for your vendor risk assessment and tiering rationale |
| CC3.4 | Identifying and assessing changes that could affect the system | Detecting when a vendor changes ownership, subprocessors, or its own controls |
| P6.4 P6.5 | Third-party privacy commitments and breach-notification commitments (Privacy category only) | Obtaining and periodically assessing privacy and breach-notification commitments from third parties handling personal information |

The 2017 Trust Services Criteria, with the 2022 revised points of focus, are published by the AICPA in TSP section 100. The exact points-of-focus wording for P6.4 and P6.5 lives in that source; treat any competitor paraphrase as a signpost, not a quote. Missing or thin vendor monitoring is a recurring exception — [incomplete vendor monitoring is a common SOC 2 finding](https://auditsuisse.com/soc-2-common-findings-and-how-to-fix-them) that surfaces late in fieldwork.

## Vendor vs. subservice organization: the distinction auditors care about most

Not every third party is treated the same way in a SOC 2 report. A **subservice organization** is a vendor whose controls are *necessary*, in combination with your own, to meet your service commitments and system requirements. Your cloud infrastructure provider — AWS, Google Cloud, or Azure hosting a SaaS product — is the classic example: if their controls fail, your commitments fail. An ordinary **vendor or business partner** (a payroll tool, a marketing platform, an office-badging service) matters to risk but is not necessary to meet your service commitments, so it stays out of the report's system description.

This distinction drives real mechanics. Only subservice organizations receive carve-out or inclusive treatment and require Complementary Subservice Organization Controls (CSOCs). Getting the classification right starts with scope: [scoping decisions determine which vendors become subservice organizations](https://auditsuisse.com/how-to-scope-systems-for-soc-2) and therefore what your auditor tests and discloses.

Vendor / business partner vs. subservice organization

| Attribute | Vendor / business partner | Subservice organization |
| --- | --- | --- |
| Definition | A third party you rely on operationally but whose controls are not required to meet your commitments | A vendor whose controls are necessary, with yours, to meet your service commitments |
| Necessary to meet service commitments? | No | Yes |
| Example | Payroll SaaS, CRM, marketing analytics | AWS, Google Cloud, or Azure hosting your product |
| SOC 2 report treatment | Managed under CC9.2 as vendor risk; no carve-out/inclusive method | Carve-out or inclusive method; CSOCs disclosed (types disclosed under carve-out) |
| Appears in your report's description? | No | Yes — identified as a subservice organization |

A worked example helps. Imagine a healthtech SaaS running on AWS, using Snowflake for its data warehouse, Stripe for payments, Twilio for messaging, Datadog for observability, and a marketing analytics tool. AWS and Snowflake process production data and are likely subservice organizations. Stripe and Twilio process regulated data and are critical vendors. Datadog ingests logs (potentially sensitive) and is high-risk. The marketing tool with no production-data access is low-risk. Same company, five very different treatments — that mapping is exactly what tiering formalizes.

### Carve-out vs. inclusive method and CSOCs

Once a vendor is a subservice organization, you choose how to present it. Under the **carve-out method**, the subservice organization's controls are excluded from your system description, and you disclose the *types* of CSOCs you expect it to perform. Under the **inclusive method**, the subservice organization's controls are described and tested inside your report. Carve-out is by far the more common choice because it is simpler and does not require the subservice organization's cooperation with your auditor.

Carve-out method vs. inclusive method for subservice organizations

| Dimension | Carve-out method | Inclusive method |
| --- | --- | --- |
| What's described | Your controls only; subservice org excluded | Your controls plus the subservice org's controls |
| What's tested | Your controls only | Both organizations' controls |
| CSOCs disclosed | Yes — the *types* of expected CSOCs | Not applicable; controls are described directly |
| When to use | Large cloud providers that won't participate in your audit | A closely integrated subservice org willing to be examined |
| Prevalence | Far more common | Rare |
| Impact on your fieldwork | You must evidence how you *monitor* the subservice org | Coordinated testing and a shared audit period |

Two points auditors insist on. First, the AICPA Description Criteria (DC section 200, criterion **DC7**) require your system description to disclose the subservice organizations and, under carve-out, the *types* of CSOCs — not the specific controls. Second, and most missed: regardless of method, **you remain responsible for monitoring the effectiveness of the subservice organization's controls** — typically by reviewing its SOC 2 Type II annually, mapping CSOCs, and following up on deviations.

### The flip side: Complementary User Entity Controls (CUECs)

CSOCs describe what you expect *from* a subservice organization. Complementary User Entity Controls (CUECs) are the reverse: controls the subservice organization expects *you* to operate for its report to be relied on — for example, enabling MFA, managing your own encryption keys, or configuring access correctly. When you rely on a vendor's SOC 2 report, you must read its CUEC section and implement the applicable controls. Skipping this is one of the most common operational gaps auditors catch, because a beautiful vendor report is worthless to you if you never met its user-entity conditions.

> “Your SOC 2 report is only as strong as your weakest vendor. We repeatedly see companies with excellent internal controls fall short because they never mapped their cloud provider's CSOCs — or never implemented the user-entity controls that provider's own report required of them.”
>
>  — Sébastien Ruosch, CPA, Director of Audits at Auditsuisse

## Step 1 — Build a complete vendor inventory

You cannot assess what you cannot see, so the program starts with a single, authoritative **vendor register**. It should list every third party that touches your systems or data, along with the data classification involved, the business owner, the system or process the vendor supports, and whether the vendor is a candidate subservice organization. Completeness is the control auditors test first: shadow SaaS purchased on a corporate card is the usual source of gaps.

Pull the initial list from expense and procurement systems, SSO/identity logs (which apps are federated), and DNS/egress data if you have it. Reconcile those sources so a vendor that never went through procurement still lands in the register. This register becomes the backbone artifact for CC9.2 and the anchor for every table that follows.

## Step 2 — Tier vendors by data sensitivity and criticality

Tiering is how you make CC9.2 proportionate. Classify each vendor by the sensitivity of the data it accesses and how critical it is to delivering your service, then attach a diligence and monitoring requirement to each tier. Critical vendors that process production data or PII warrant the most scrutiny; a low-risk marketing tool with no data access does not. Record the *rationale* for each placement — auditors test the reasoning, not just the label.

Vendor tiering matrix

| Tier | Definition & data access | Example vendors | Diligence required | Re-assessment cadence | Approval authority |
| --- | --- | --- | --- | --- | --- |
| Critical | Processes production data / PII; failure breaks service commitments (often a subservice org) | AWS, Snowflake, Stripe | Current SOC 2 Type II + DDQ + CSOC/CUEC mapping | Annual | CISO / risk committee |
| High | Accesses sensitive but non-production data, or logs | Datadog, Twilio | SOC 2 Type II or ISO 27001 + SIG Lite | Annual | Security lead |
| Moderate | Limited internal or business data | CRM, HR SaaS | SIG Lite or completed DDQ + DPA | Biennial | Security lead |
| Low | No production or personal data | Marketing analytics, design tools | Self-attestation reviewed at renewal | At renewal | Business owner |

## Step 3 — Run tier-based due diligence

With tiers set, collect proportionate evidence. The most efficient path is to accept a vendor's independent attestations — a current SOC 2 Type II or ISO 27001 certificate — and supplement with a questionnaire only where gaps remain. Standardized questionnaires reduce back-and-forth: the Shared Assessments **SIG** and its shorter **SIG Lite**, and the Cloud Security Alliance **CAIQ** (Consensus Assessments Initiative Questionnaire, aligned to the Cloud Controls Matrix). Confirm the current SIG release year and CAIQ version before you send one, since naming a stale version is a dated signal. Because critical vendors carry your production data, you should [require a Type II report from critical vendors](https://auditsuisse.com/soc-2-type-1-vs-type-2) rather than a point-in-time Type I.

Due-diligence artifact by tier

| Artifact | When required | What the auditor looks for | Where to store evidence |
| --- | --- | --- | --- |
| SOC 2 Type II report | Critical & high tiers; subservice orgs | Reporting period, relevant criteria, findings and recipient requirements | Vendor GRC folder / evidence repository |
| SOC 3 report | When a Type II is unavailable publicly | Confirms scope but lacks test detail — weaker reliance | Vendor GRC folder |
| ISO 27001 certificate | Alternative to SOC 2, esp. for EU vendors | Valid certificate, in-scope statement of applicability | Vendor GRC folder |
| Penetration test summary | High/critical vendors handling sensitive data | Recent test date, remediation of high findings | Vendor GRC folder |
| DDQ / SIG / SIG Lite / CAIQ | When attestations don't cover your questions | Complete answers, evidence attached, no unaddressed gaps | GRC platform |
| Data Processing Agreement (DPA) | Any vendor processing personal data | Executed DPA, subprocessor terms, transfer mechanism | Contract repository |
| Cyber-insurance COI | Critical vendors (risk transfer) | Coverage limits, current policy period | Contract repository |

A practical DDQ core for a critical vendor covers eight to twelve areas: Do you hold a current SOC 2 Type II or ISO 27001? What data will you access and where is it stored/processed? Is data encrypted in transit and at rest? Who are your subprocessors, and how do you manage them? What is your breach-notification SLA? How do you handle access control and MFA? What is your incident-response and BCP/DR posture? Do you carry cyber insurance? How and when will you return or delete our data on termination? Keep the answers — [store vendor due-diligence evidence](https://auditsuisse.com/audit-evidence-management-best-practices) in a governed repository so you can reproduce it during fieldwork.

## Step 4 — Embed CC9.2 controls in contracts and SLAs

Assessment without contractual teeth is not management. The contract is where CC9.2 obligations become enforceable, so critical and high-tier agreements should carry a defined clause set. If a vendor handles protected health information, pair the DPA with a HIPAA [business associate agreement](https://auditsuisse.com/hipaa); for EU personal data, ensure the DPA reflects [data processing agreements and Article 28 subprocessor obligations](https://auditsuisse.com/gdpr).

Contract / SLA clause checklist for CC9.2

| Clause | Why CC9.2 cares | Typical benchmark |
| --- | --- | --- |
| Right to audit / evidence | Lets you obtain SOC 2 reports and verify controls | Annual SOC 2 Type II delivery on request |
| Breach-notification SLA | Enables timely incident response and your own obligations | Notification within 72 hours of discovery |
| Subprocessor disclosure | Surfaces nth-party (fourth-party) risk and change | Advance notice of new subprocessors + objection right |
| Data return / deletion on termination | Supports clean offboarding evidence | Certified deletion within 30–90 days |
| Encryption commitment | Baseline safeguard for data in transit and at rest | TLS 1.2+ in transit; AES-256 at rest |
| SOC 2 report delivery | Formalizes your ongoing monitoring input | Acceptable report age and any bridge-letter interval are set by the recipient's requirements and risk assessment; a bridge letter does not add auditor-tested coverage. |

The subprocessor clause is where **nth-party risk** is controlled. A carve-out vendor's own subcontractors can inherit your data, so require advance notice of new subprocessors and the right to object. Under the inclusive method, contract terms should oblige the vendor to manage its subcontractors to an equivalent standard.

## Step 5 — Monitor vendors continuously

CC9.2 is a lifecycle obligation, so monitoring is where most programs live or die. For subservice organizations, review each vendor's SOC 2 Type II every year: confirm the coverage period, map the CSOCs to your own controls, implement the CUECs, and follow up on any deviations. Point-in-time questionnaires answer the past; **security-ratings and continuous-monitoring tools** (the category includes BitSight, SecurityScorecard, and UpGuard) provide an external signal between assessments. Use continuous monitoring for critical vendors and questionnaires at defined intervals for the rest.

### When a coverage period has gaps: bridge letters

Acceptable report age and any bridge-letter interval are set by the recipient's requirements and risk assessment; a bridge letter does not add auditor-tested coverage.

Bridge-letter gap analysis

| Vendor SOC 2 coverage period | Your audit period | Gap months | Mitigation | Auditor acceptance |
| --- | --- | --- | --- | --- |
| Jan–Dec 2025 | Ends Mar 2026 | ~3 months | Discuss report age, subsequent changes and required evidence with the recipient. | Recipient assessment required |
| Jan–Dec 2025 | Ends Aug 2026 | ~8 months | Discuss report age, subsequent changes and required evidence with the recipient. | Recipient assessment required |
| Jan–Jun 2025 | Ends Dec 2026 | ~18 months | Discuss report age, subsequent changes and required evidence with the recipient. | Recipient assessment required |

### When a vendor's report has exceptions or a qualified opinion

Receiving a SOC 2 report is not the end of the review — you have to read it. If the report contains testing exceptions or a qualified or adverse opinion, evaluate whether the affected controls are relevant to *your* service commitments. If they are, document compensating controls, follow up with the vendor on remediation, and record the decision. An exception in a control you do not rely on may be immaterial; an exception in access management for a vendor holding production data is not. Auditors test that you actually triaged the report rather than filing it unread.

### Concentration and business-disruption risk

CC9.2 also covers what happens when a critical vendor goes down, is acquired, or is breached. Single-vendor dependency and concentration risk deserve an explicit treatment: an exit strategy or fallback for each critical vendor, and risk transfer through cyber insurance where a control gap cannot be fully closed. This is a legitimate CC9.2 sub-topic, and mature programs document it rather than assuming a vendor will always be available.

## Step 6 — Re-assess annually and offboard vendors cleanly

Re-assessment cadence follows the tier: annual for critical and high vendors, biennial or at-renewal for lower tiers. Re-assessment is not a rubber stamp — it should confirm the SOC 2 report is still current, subprocessors have not changed materially, and the vendor still belongs in its assigned tier.

Offboarding is the step most programs forget to evidence. When a vendor relationship ends, revoke access (API keys, SSO, admin accounts), confirm data return or certified deletion per the contract, and close the vendor in the register. Keep the deletion certificate and the access-revocation record — auditors ask for offboarding evidence, and its absence is a clean, easily avoided finding.

## Evidence auditors request for CC9.2

Vendor management is tested through artifacts, not intentions. The table below maps each lifecycle stage to the control activity, the evidence auditors typically request, and the likely owner. Storing these consistently is what turns a policy into a passable control.

Vendor lifecycle stage to CC9.2 evidence

| Lifecycle stage | Control activity | Evidence auditors request | Owner |
| --- | --- | --- | --- |
| Intake / onboarding | Inventory, tiering, initial risk assessment | Vendor register, tiering rationale, completed DDQ/SIG | Security |
| Contracting | Embed CC9.2 clauses, DPA/BAA | Executed contracts with clause set, DPA, BAA where applicable | Legal |
| Ongoing monitoring | SOC 2 review, CSOC mapping, exception triage | Reviewed SOC 2 reports, CSOC/CUEC mapping, bridge letters, security-rating logs | Security |
| Renewal / re-assessment | Periodic re-review at tier cadence | Dated re-assessment records, updated attestations | Security / Procurement |
| Offboarding | Access revocation, data return/deletion | Deprovisioning records, certified deletion evidence | Security / Procurement |

## Common vendor management pitfalls

The first pitfall is **no tiering** — treating a marketing tool and a cloud host with the same (or no) diligence. This either wastes effort or, worse, under-vets a critical vendor. The second is **treating every subservice organization as carve-out and then never monitoring it**; carve-out removes the vendor from your description, not your monitoring obligation.

Acceptable report age and any bridge-letter interval are set by the recipient's requirements and risk assessment; a bridge letter does not add auditor-tested coverage.

## How vendor management connects to your broader SOC 2 program

Vendor management is one spoke of a larger program. The classification of a vendor as a subservice organization is a *scoping* decision, the CSOCs you disclose depend on your *controls list*, and the reports you require from critical vendors depend on the *Type I vs Type II* distinction. Treat these as one connected system rather than separate projects. If you are early, [add vendor management to your readiness checklist](https://auditsuisse.com/soc-2-readiness-checklist-2026) and build the register before fieldwork rather than during it. For the full picture of scope, criteria, and reporting, start from our [SOC 2 audit services](https://auditsuisse.com/soc-2) overview.

## Frequently asked questions

### What is SOC 2 vendor management?

SOC 2 vendor management is the process of assessing and controlling risk from third parties under criterion CC9.2, which states the entity assesses and manages risks associated with vendors and business partners. It spans vendor inventory, risk tiering, due diligence, contract controls, and ongoing monitoring of each vendor's security posture.

### Which SOC 2 control covers vendor management?

CC9.2 is the primary control: “The entity assesses and manages risks associated with vendors and business partners.” Auditors also map vendor risk to CC2.3 (external communication), CC3.2 and CC3.4 (risk and change assessment), and P6.4 and P6.5 when the Privacy category is in scope.

### What is the difference between a vendor and a subservice organization in SOC 2?

A subservice organization is a vendor whose controls are necessary to meet your service commitments, such as your cloud host (AWS, GCP, Azure). Ordinary vendors are not. Only subservice organizations receive carve-out or inclusive treatment and require Complementary Subservice Organization Controls (CSOCs) to be disclosed in your report.

### What is the carve-out method vs the inclusive method in SOC 2?

Under the carve-out method, a subservice organization's controls are excluded from your report's description but the types of CSOCs are disclosed; under the inclusive method, the subservice organization's controls are described and tested within your report. Carve-out is far more common. Either way you must still monitor the subservice organization.

### How do you tier vendors for SOC 2?

Classify vendors by the sensitivity of data they access and their criticality to your service. Critical vendors that process production data or PII require a current SOC 2 Type II report plus a due-diligence questionnaire and annual re-assessment; low-risk vendors may need only a self-attestation reviewed at renewal.

### Do my vendors need their own SOC 2 report?

Not all of them. Critical and high-risk vendors — especially subservice organizations that handle your production data — should provide a current SOC 2 Type II or ISO 27001 report you review annually. Lower-tier vendors can be covered by questionnaires, DPAs, or self-attestations proportionate to the risk they carry.

### What is a bridge letter for a vendor's SOC 2 report?

Acceptable report age and any bridge-letter interval are set by the recipient's requirements and risk assessment; a bridge letter does not add auditor-tested coverage.

## Sources & further reading

1. AICPA & CIMA — [2017 Trust Services Criteria (with Revised Points of Focus — 2022), TSP section 100](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022) — source of CC9.2, CC2.3, CC3.2, CC3.4, and P6.4/P6.5.
2. AICPA & CIMA — [SOC 2® — SOC for Service Organizations](https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2) — Description Criteria (DC section 200, incl. DC7) for subservice-organization and CSOC disclosure.
3. Shared Assessments — [Standardized Information Gathering (SIG / SIG Lite) questionnaire](https://sharedassessments.org/sig/).
4. Cloud Security Alliance — [Cloud Controls Matrix and CAIQ (Consensus Assessments Initiative Questionnaire)](https://cloudsecurityalliance.org/research/cloud-controls-matrix).

 Continue Reading

## Related Resources

 [### Common SOC 2 Findings and How to Fix Them The most frequent audit findings and practical steps to remediate them. Read More →](https://auditsuisse.com/soc-2-common-findings-and-how-to-fix-them) [### Audit Evidence Management Best Practices How to collect, organize, and maintain audit evidence efficiently. Read More →](https://auditsuisse.com/audit-evidence-management-best-practices) [### How to Scope Systems for SOC 2 Define your SOC 2 boundaries without over-auditing. Read More →](https://auditsuisse.com/how-to-scope-systems-for-soc-2)

---
Source: https://auditsuisse.com/vendor-management-for-soc-2-compliance · This Markdown edition is generated from the same content as the HTML page.