SOC 2 vendor management: third-party risk done right
How CC9 expects you to inventory, classify, vet, and monitor vendors, plus what subservice organizations and the carve-out versus inclusive choice mean for your report.
Where vendor risk lives in SOC 2
Third-party risk is addressed primarily under CC9 in the common criteria, with CC9.2 expecting the service organization to assess and manage the risks associated with vendors and business partners across the full lifecycle of each relationship. The premise is straightforward: when you hand data or critical functionality to a third party, their weaknesses become your weaknesses, and your customers are trusting you to manage that exposure on their behalf. CC9 therefore looks for a program rather than a one-off questionnaire, covering how you identify vendors, decide how much scrutiny each one deserves, perform due diligence, lock obligations into contracts, and keep watching after the ink dries. It connects naturally to your CC3 risk assessment, since vendors are simply another category of risk to be identified, scored, and treated. Auditors expect this to be a deliberate, documented function, not a collection of ad hoc decisions scattered across email threads.
Inventory and risk-based classification
Everything starts with a complete vendor inventory, because you cannot manage risk from third parties you have not catalogued, and incomplete inventories are a frequent source of audit pain. Once you have the list, the discipline that makes a program scalable is tiering vendors by the risk they actually pose rather than treating every supplier identically. A common and effective model uses three tiers: critical vendors that host or process sensitive customer data or are part of your production system, important vendors that support the business but touch less sensitive data, and low-risk vendors with minimal access. Classification should turn on data sensitivity and operational criticality, so the cloud provider running your production workloads sits in the top tier while a marketing analytics tool with no customer data sits near the bottom. This tiering then drives the depth of due diligence and the frequency of reassessment, letting you spend scrutiny where it matters.
Due diligence and reviewing vendors' SOC 2 reports
For higher-tier vendors, the centerpiece of due diligence is reviewing their own assurance artifacts, and a vendor's SOC 2 report is the most common one you will receive. Reading it well means more than confirming a report exists: you should check that the scope and Trust Services Criteria match the service you actually consume, that the report period is current rather than expired, and that you understand any exceptions the auditor noted and whether they affect you. Critically, every SOC 2 report includes complementary user entity controls, the controls the vendor assumes you will operate on your side for the overall system to work, and you are responsible for confirming those are actually in place in your environment. Where a SOC 2 report is unavailable you fall back to ISO 27001 certificates, penetration test summaries, or a security questionnaire, but you should document why the substitute was acceptable. Auditors want to see that the review happened, who did it, and what was concluded.
Subservice organizations, carve-out, and inclusive methods
Some vendors are not just suppliers but subservice organizations, meaning their controls are genuinely part of your system because your ability to meet your own Trust Services Criteria depends on them, with a cloud hosting provider being the classic example. Your SOC 2 report must address these subservice organizations using one of two methods. Under the far more common carve-out method, the subservice organization's controls are described and named in your report but excluded from your auditor's direct testing; instead you rely on their own SOC 2 report and implement complementary subservice organization controls on your side. Under the inclusive method, the subservice organization's controls are pulled into your audit scope and your auditor tests them directly, which offers customers more transparency but demands heavy coordination and cooperation from the provider. Most organizations choose carve-out because it keeps scope manageable and works cleanly whenever the subservice organization maintains its own report you can lean on.
Contracts, DPAs, and ongoing monitoring
Due diligence at onboarding is necessary but not sufficient, because vendor risk shifts over time and CC9 expects you to manage the relationship through its full term. Contracts and data processing agreements are where you turn expectations into enforceable obligations, so a strong DPA should address permitted purpose, confidentiality, sub-processor disclosure and approval, breach notification timelines, audit rights, data retention and deletion, and the vendor's duty to assist you with security and privacy obligations. Beyond paper, you need a monitoring rhythm: refreshing critical vendors' SOC 2 reports as new ones are issued, watching for changes to their subprocessor lists and trust pages, and reassessing whenever a triggering event occurs such as a breach, a major product change, a new sub-processor, or an acquisition. A workable cadence reassesses your highest-risk vendors at least annually and lower-risk ones less often, with event-driven reviews layered on top. The goal is a program that keeps producing fresh evidence rather than a binder that ages quietly.
Evidence and the gaps that cause findings
When an auditor tests CC9, they generally want the vendor inventory, your tiering or classification logic, the due diligence records for sampled vendors, the executed contracts and DPAs, and proof of monitoring activity during the examination period. The recurring failures are predictable and avoidable. Inventories miss vendors, especially shadow IT and tools onboarded by individual teams; classification is absent or arbitrary so everything gets the same treatment; SOC 2 reviews are collected but never actually read, leaving exceptions and complementary user entity controls unaddressed; and reassessment lapses so the only evidence is a stale onboarding questionnaire from years ago. Carve-out reliance also breaks down when the team never confirms the subservice organization's report is current or never implements the complementary controls that reliance assumes. Treating vendor management as a continuous operational process, with dated records and clear ownership, turns CC9 from an audit scramble into a routine that defends itself.