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

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 in our controls list.

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 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 and therefore what your auditor tests and discloses.

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.

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.

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 rather than a point-in-time Type I.

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 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; for EU personal data, ensure the DPA reflects data processing agreements and Article 28 subprocessor obligations.

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

A vendor's SOC 2 coverage period rarely lines up with your audit period. To cover the gap between the end of the vendor's report and your review date, request a bridge letter (gap letter) in which the vendor's management affirms no material control changes. A bridge letter supplements but never replaces a full report, and in common auditor practice — corroborated by firms such as Drata and Linford & Co — it is generally accepted only for a short gap of roughly up to three months. That threshold is a practice norm, not a codified AICPA rule.

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.

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.

The third is relying on stale vendor SOC 2 reports — a report whose coverage period ended eighteen months ago, with no bridge letter and no follow-up. The fourth is missing CSOC and CUEC mapping: you disclosed a subservice organization but never connected its expected controls to yours, or never implemented the user-entity controls its report required. The fifth is no offboarding evidence, and the sixth is no bridge letter for gap periods, leaving an unexplained hole in your reliance on a vendor's report. Every one of these is preventable with the register, the tiering rationale, and a monitoring log.

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 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 overview.