SOC 2 CC9.2: vendor risk, explained for startups

What usually proves it

An auditor wants records from the period being examined, pulled from the systems that hold them rather than written up afterwards. Dates matter. A record with a date and a named owner carries more weight than a screenshot with neither. For CC9.2, the usual records are these.

• A vendor register with risk tiers
• Vendor SOC 2 reports and your review notes
• Contracts or data processing agreements with security terms

What Polara asks about it

The free readiness assessment asks 8 questions that bear on CC9.2. A yes becomes a task to show the proof. A no becomes a task to fix the gap, with the steps written out.

• Can you provide SOC reports or complete our risk questionnaire for each subservice org? If yes, show it: SOC 2 report cover page from a hosting provider, completed vendor security questionnaire, trust center download record, or a filed note naming the report and its date. If no, the fix: request the current SOC 2 report or a completed risk questionnaire from each subservice organization and file the review.
• Do you review the SOC 2 report or security attestation of each subservice organization annually? If yes, show it: dated review note naming the report period and the exceptions found, vendor review log entry, or a completed subservice review checklist. If no, the fix: review each subservice organization report every year and file the review with its date and its conclusion.
• Do you maintain an inventory of production systems, data stores, and SaaS applications with an owner for each? If yes, show it: spreadsheet listing each production system, data store and SaaS application with an owner, a configuration management database export, or a cloud resource inventory with owner tags. If no, the fix: build one inventory of production systems, data stores and SaaS applications, assign an owner to each entry, and export it.
• Vendor risk reviews performed before onboarding and yearly? If yes, show it: vendor security questionnaire, vendor risk register, SOC 2 report file, or vendor review log. If no, the fix: review each vendor before onboarding and annually, and record the outcome in a vendor register.
• List each vendor with production data access, its criticality, and the date of its last review. If yes, show it: signed vendor register, a vendor inventory spreadsheet with criticality and review dates, a procurement list limited to vendors with data access, or a vendor review log. If no, the fix: list every vendor with production data access in a register with its criticality and the date of its last review, and keep the register current.

It also asks, for context:

• Cloud provider used for production.
• List hosting, identity, code repo, and collaboration vendors used in production.
• Use the carve-out method for subservice organizations?

Policies, templates and connected evidence

A policy states the rule, a template gives you the record to keep, and a connected system pulls the proof from the source. An auditor checks that the three agree: the cadence in the policy, the dates in the record and what the system shows.

In the policy pack, the Third Party and Vendor Management Policy and Asset Management Policy cover CC9.2.

Free templates that help, printed in full with Word, PDF or Excel downloads:

• Vendor management policy template
• Vendor security questionnaire template
• Vendor register template

If you also run ISO 27001, the Annex A controls A.5.19, supplier security, A.5.20, security in supplier contracts, A.5.21, technology supply chain, A.5.22, watching your suppliers, A.5.23, cloud services and A.8.30, outsourced development ask for overlapping evidence. One record can serve both when it names what it proves.

Where it goes wrong

One gap a remediation playbook covers here is vendor Risk Assessment. The fix: create a vendor inventory and assess at least one critical vendor. The proof: completed vendor assessment form for one critical vendor.

An auditor asks two things about it. Is there a documented vendor risk assessment process? Has at least one critical vendor been assessed using the documented process?

Is it in your scope?

Yes, always. CC9.2 is one of the 33 common criteria, and the common criteria are in every SOC 2 report, Type 1 or Type 2. The common criteria. Every SOC 2 report covers them, whatever else you add: governance, risk, access, operations, change and vendors. Most of the work in any SOC 2 sits here.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Risk mitigation: the criteria around it

CC9.2 is one of 2 criteria in risk mitigation, CC9.1 to CC9.2. Reading a group together shows how its outcomes fit, and one record often serves more than one of them.

• CC9.1, disruption risk
• CC9.2, this page

Before it: CC9.1, disruption risk. After it: A1.1, capacity planning. All the criteria are on the Trust Services Criteria page, grouped by category.