SOC 2 CC9.2: Vendor and Business Partner Risk Management

SOC 2 CC9.2 is the vendor and business partner risk criterion: it requires an organization to assess and manage the risks that come from the third parties it depends on. It sits in the CC9 series (Risk Mitigation), covers everything from a SaaS subprocessor to a colocation data center, and is where auditors check that vendor decisions are risk-based rather than either ignored or applied equally to every vendor.

What does SOC 2 CC9.2 require?

In plain terms, SOC 2 CC9.2 asks whether the organization knows which third parties carry risk, has assessed that risk proportionately, and manages the relationship over its full life, from onboarding through review to termination. The criterion covers vendors that host or process data, business partners that connect into systems, and the subservice organizations that operate part of the infrastructure the audited service relies on.

CC9.2 is a scoping discipline as much as an assessment discipline. It does not require a full security review of every vendor. It requires informed decisions about which vendors matter and why. A bank that processes payroll through a separate HR system is a different risk than a subprocessor with production data access, and CC9.2 expects the assessment depth to follow the risk rather than treating both the same.

For most companies today, the meaningful vendors are SaaS providers, so CC9.2 leans on the vendor's own attestations. Reviewing a vendor's SOC 2 report, confirming the scope and audit period, and reading its Complementary User Entity Controls section is the core of a modern vendor assessment. The obligation never fully transfers: the organization still owns vendor selection, the contracts, and turning on the right controls in each platform.

What are the CC9.2 points of focus?

The AICPA defines 8 points of focus for CC9.2 that apply to all engagements, plus additional points for engagements that include the Confidentiality and Privacy categories. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Requirements and assessment. The organization establishes security and operational requirements for vendor and business partner engagements, and assesses each third party's risk against those requirements before and during the relationship.
• Responsibility and communication. Responsibility and accountability for managing vendors are assigned to named owners, and communication protocols are established so expectations and issues move in both directions.
• Exceptions and performance. Procedures handle exceptions raised by vendors, and vendor performance against the agreed requirements is assessed over the life of the relationship.
• Issue handling and termination. Issues found during vendor assessments are addressed through defined procedures, and there is a process for terminating vendor and business partner relationships cleanly, including revoking access and recovering data.

Confidentiality engagements add points of focus covering confidentiality commitments from vendors and checking compliance with them; Privacy engagements add the equivalent for personal information. The recurring theme across all of them is proportionality: named owners, documented decisions, and a depth of assessment that tracks the vendor's actual access to systems and data.

How do you meet CC9.2 for SaaS and cloud vendors?

Cloud and SaaS vendor risk is met by classifying vendors by data access, then reviewing the higher-risk ones through their own attestations. The building blocks are consistent regardless of platform:

• A vendor inventory classified by data access. Sort each vendor by what it touches: production data, development data, employee information, or generic business information. A vendor touching none of the sensitive categories is low risk and needs only a recorded risk level, which keeps the assessment effort where the risk is.
• SOC 2 report review for material vendors. For vendors with production or sensitive data access, review the SOC 2 report, confirm the scope and trust criteria, check the audit period and the exceptions section, and read the Complementary User Entity Controls the vendor expects the organization to operate.
• Contracts that carry the requirements. Data processing agreements, confidentiality commitments, and breach notification clauses put the security requirements into enforceable form.
• Enabling controls on the buyer side. Enterprise third-party risk teams increasingly evaluate whether a product lets the buyer stay secure: SSO, role-based access mapped to directory groups, exportable security logs, and session termination. Turning these on for the vendors the organization itself uses is part of managing the relationship.
• A review cadence tied to risk. High-risk vendors are reassessed on a set schedule and when something material changes, such as a new subprocessor or a plan-tier change that alters the data the vendor can hold.

How do you meet CC9.2 on-prem?

On-prem vendor risk centers on the colocation or hosting provider, which SOC 2 treats as a subservice organization. The data center vendor management guide covers the full implementation; the shape is:

• Recognize the subservice organization. When a colocation or hosting provider operates the facility, its physical security, power, cooling, and network uplinks are part of the audited system even though the provider runs them. That makes the provider a subservice organization whose risk CC9.2 requires the organization to manage.
• Use the carve-out method. For commercial colocation and hosting, the provider's controls are carved out and tested by the provider's own auditor. The organization names the provider, identifies the expected control categories, and reviews the provider's SOC 2 or equivalent report annually.
• Operate the Complementary User Entity Controls. The carve-out comes with obligations on the organization's side: logical access over provider-managed interfaces, personnel change notifications for facility access, monitoring its own workloads, and notifying the provider of shared-infrastructure incidents. The provider's CUEC section is a row-by-row input to the security program.
• Confirm the contractual commitments. Breach notification, data residency, and availability commitments from the provider are the parts of the relationship the organization has to hold the vendor to.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC9.2?

A common gap that comes up during readiness assessments is over-scoping the vendor list. One company preparing for SOC 2 had entered every vendor it used into its GRC platform, including its bank, open-source tools used locally, and low-risk marketing utilities. The vendor section showed dozens of vendors with incomplete assessments, which made the company look behind when most of those vendors did not need a formal assessment at all. A one-hour data access classification, sorting each vendor by whether it touches production, development, employee, or generic information, identified the handful that were truly in scope and cut the workload in half. The auditor wants to see informed decisions about vendor risk, not an equal assessment of every vendor.

A related gap appears at the other end of the scale. For a SaaS-heavy healthtech company, a gap assessment found more than 400 applications in active use, far beyond what anyone had inventoried, with patient data spread across chat tools, spreadsheets, and collaboration workspaces. At that scale vendor risk management is the spine of the program rather than a small chapter, and one collaboration platform sat on a plan tier that did not match how it was being used with sensitive data, a mismatch nobody had caught because tier selection had never been treated as a compliance decision. Knowing where regulated data lives across the vendor estate is the prerequisite CC9.2 depends on.

How does CC9.2 map to ISO 27001:2022?

The overlap is full, so organizations pursuing both frameworks can reuse CC9.2 evidence almost wholesale for these Annex A controls. One caveat: A 5.21 (ICT supply chain security) goes further than typical SOC 2 vendor management, requiring an inventory of ICT suppliers and security requirements embedded in procurement, so it usually needs supplementing. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC9.2 manages third-party risk; the adjacent criteria manage the risks around it. CC9.1 covers risk mitigation for business disruptions, including the disruptions a failed vendor can cause, and is documented in the SOC 2 CC9.1 guide. CC8.1 covers change management for the organization's own changes, a useful contrast with the vendor-side changes CC9.2 monitors, and is documented in the SOC 2 CC8.1 guide. The Trust Services Criteria guide summarizes every series, and the risk identification that feeds vendor scoping lives in CC3.2.

Frequently Asked Questions

What does SOC 2 CC9.2 mean?

SOC 2 CC9.2 requires an organization to assess and manage the risks associated with vendors and business partners. It covers scoping vendors by risk, assessing material vendors through their attestations and contracts, assigning owners, and managing each relationship from onboarding through review to termination.

What evidence satisfies CC9.2?

Typical CC9.2 evidence includes a vendor inventory classified by data access, vendor risk assessments for material vendors, vendor SOC 2 review records, a Vendor Risk Management Policy, data processing and confidentiality agreements, and offboarding records showing access was revoked and data recovered.

Does SOC 2 CC9.2 require assessing every vendor?

No. CC9.2 requires informed, risk-based decisions, not an equal assessment of every vendor. Vendors that touch no production or sensitive data can be recorded at a low risk level with a brief justification, while vendors with production or sensitive data access get documented assessments.

How do you assess a SaaS vendor for CC9.2?

Review the vendor's SOC 2 report, confirm the scope and trust criteria, check the audit period and the exceptions section, and read the Complementary User Entity Controls the vendor expects you to operate. Pair that with a data processing agreement and confidentiality and breach notification clauses in the contract.

How does CC9.2 handle a colocation or data center provider?

A colocation or hosting provider that operates part of the audited system is a subservice organization. The common treatment is the carve-out method: name the provider, review its SOC 2 or CSAE 3000 report annually, and operate the Complementary User Entity Controls the provider's report describes.

This post is part of Truvo's criterion-by-criterion SOC 2 reference series. Browse every criterion in the Framework Explorer or start from the Trust Services Criteria guide. For a second set of eyes on control design before an audit, Truvo runs scoping calls.