CC9.2 — Vendor and business partner risk

Risks associated with vendors and business partners are assessed and managed.

Also written as CC 9.2, TSC CC9.2, SOC2 CC9.2, SOC 2 Type 2 CC9.2.

Written by Jett N. · Last reviewed 22 July 2026

What SOC 2 CC9.2 requires

Vendor and business partner risk is one of 2 criteria in the Risk Mitigation (CC9) series of the Security (Common Criteria) category. Risks associated with vendors and business partners are assessed and managed. CC9 covers business disruption and vendor risk, so evidence spans BCDR test results and the third-party review files that show you assess the vendors handling your data.

Audit evidence assessors look for

When preparing for a SOC 2 audit against CC9.2, gather artefacts such as:

Points of focus for CC9.2

The Trust Services Criteria set out points of focus that describe what an auditor considers when assessing CC9.2. They are not themselves requirements, but they shape the testing:

• Vendors and business partners that could affect the system are identified.
• Risks associated with them are assessed before and during the relationship.
• Commitments and requirements are communicated contractually.
• Vendor performance against those commitments is monitored.

How to implement CC9.2

1. Maintain a vendor register that distinguishes criticalityAssessing every vendor to the same depth is unsustainable and dilutes the ones that matter. Tier by data access and business dependency, and let the tier drive the assessment depth. The tiering rationale is itself evidence.
2. Review vendor assurance reports rather than collecting themFiling a supplier SOC 2 report satisfies nothing. Read it, note the exceptions and the complementary user entity controls it assumes you operate, and record that review. The CUEC point is where most organisations are exposed without knowing it.
3. Get security terms into contracts, including sub-processorsSecurity requirements, breach notification timelines and the right to audit or receive assurance reports need to be contractual. Sub-processor disclosure matters because your customers will ask you the same question you should be asking your vendors.
4. Re-assess on a cadence tied to tierAnnual for critical vendors, longer for the rest, plus an event trigger on breach or material change. A one-time onboarding assessment does not evidence ongoing management, which is what the criterion asks for.
5. Include an offboarding stepVendor termination should trigger data return or destruction and access revocation. This is routinely undocumented and is easy evidence to produce once the step exists.

Common audit findings for CC9.2

What actually gets raised against CC9.2, in rough order of how often it comes up:

• Vendor assurance reports collected but with no evidence anyone reviewed them or considered the complementary user entity controls.
• Critical vendors assessed at onboarding years ago and never since.
• No contractual breach-notification requirement, leaving you unable to meet your own customer commitments.
• Vendors onboarded via corporate card or expenses, bypassing the process entirely.

Scoping CC9.2

CC9.2 is Common Criteria and applies to every SOC 2. It maps to ISO 27001 A.5.19 to A.5.22 and to NIST CSF GV.SC, and it is the criterion your own customers are implicitly testing when they ask for your report — so the quality of the answer here has commercial as well as audit value.

ISO 27001 mapping

CC9.2 corresponds to the following ISO 27001:2022 Annex A control(s): A.5.19, A.5.20, A.5.21, A.5.22, A.5.23, A.8.30. If you already run an ISO 27001 ISMS, map your existing evidence for these controls to CC9.2 rather than duplicating work.

Other Risk Mitigation criteria

All CC9 Risk Mitigation criteria →