When a vendor in your processing chain has a security incident, the question your auditor will eventually ask is not "what did they do wrong?" It is "what did you do to monitor them?" That question sits squarely inside SOC 2's Common Criteria 9.2, which addresses risk management and vendor relationships. Most teams treat CC9.2 as a paperwork exercise: collect SOC 2 reports from your subprocessors, file them, and move on. Auditors have started to notice.
CC9.2 requires that your organization assess and manage the risks associated with third-party vendors who have access to your systems, data, or processes. That includes cloud infrastructure providers, payment processors, analytics platforms, background check vendors, and any SaaS tool that touches your production environment or customer data. The operative word is manage — not collect.
What CC9.2 Actually Requires
The Trust Services Criteria language for CC9.2 reads: the entity uses a process to identify and assess risks from third-party providers. Breaking that down into auditable evidence means three things:
- A maintained subprocessor inventory. You need a documented list of vendors with access to in-scope systems or data. The list should include vendor name, type of access, data categories involved, and last review date.
- A periodic risk assessment process. Collecting a vendor's SOC 2 report once during procurement is not ongoing assessment. Auditors want to see that you reviewed those reports annually (at minimum), checked whether the vendor's scope changed, and followed up on any qualified opinions or exceptions.
- Evidence of action on findings. If a vendor's Type II report showed repeated exceptions against CC6.1 (logical access controls), what did you do? Did you add compensating controls on your side? Did you require the vendor to remediate before renewal? Doing nothing is a valid finding against your program.
We're not saying you need to audit your vendors yourself — that would be operationally impossible for most growing teams. We're saying the monitoring obligation stays with you regardless of what the vendor's report says.
The Subprocessor Inventory Problem
In practice, subprocessor inventories are the weakest link. Teams tend to build the list once, during their initial SOC 2 readiness program, and then never update it systematically. Engineers add new SaaS tools. Marketing integrates analytics platforms. Customer success spins up a new CRM module. None of these additions flow through a formal change process that triggers an inventory update.
The result: by the time audit season arrives, the subprocessor list is six to eighteen months stale. The auditor compares it against your actual production environment and finds three or four vendors who have access but aren't on the list. That's a CC9.2 gap — and it's one of the easier findings for auditors to surface just by comparing your inventory against IAM logs or integration lists.
One pattern we've seen work: tie subprocessor inventory updates to your change management process. Anytime a new integration is approved via your change control workflow (CC6.8 or equivalent), a corresponding vendor entry is required before the change closes. This converts what was a periodic manual task into an event-driven one, and it means your inventory stays current as a byproduct of normal operations rather than an annual scramble.
Reading Vendor SOC 2 Reports for Actual Risk Signal
Collecting a vendor's SOC 2 Type II report is the baseline. Reading it critically is where most teams fall short. Here's what to look for beyond "do they have a report":
Scope Boundaries
Every SOC 2 report defines a system description that outlines what services and infrastructure are in scope. Your vendor's report might cover their core platform but explicitly exclude the data pipeline component that you actually depend on. Scope carve-outs are common and consequential. Read the scope definition before you rely on a report as risk evidence.
Exception Items in the Testing Results
Auditors list exceptions when they test a control and find it did not operate effectively for part of the observation period. A report with zero exceptions is genuinely good. A report with three exceptions against CC6.1, CC7.2, and CC8.1 is a different story — those map to logical access, incident monitoring, and change management, which are exactly the controls you depend on your subprocessors to maintain. Document what you found, assess the residual risk to your own control environment, and record that assessment.
Observation Window Recency
A Type II report with a 12-month observation window that ended fourteen months ago tells you nothing about current control effectiveness. Audit report coverage gaps are one of the gaps CC9.2 is designed to surface. Know the coverage dates of every vendor report you hold.
A Scenario: Layered Subprocessor Exposure
Consider a B2B SaaS company — call it a 60-person team managing a revenue operations platform — that uses a third-party data enrichment vendor for CRM records. The enrichment vendor uses a sub-subprocessor (a data warehouse provider) to store the enriched records before delivery. The revenue ops platform has the enrichment vendor's SOC 2 report on file. They don't have the sub-subprocessor's report because they don't know it exists — the enrichment vendor's subprocessor list isn't published by default.
During a Type II audit, the auditor reviews the organization's subprocessor inventory and asks about data flows. The data enrichment vendor is listed. But when the auditor asks about the enrichment vendor's own subprocessors, there's no documentation. The vendor agreement doesn't contain a subprocessor flow-down clause requiring the enrichment vendor to maintain their own third-party oversight program. This creates a CC9.2 gap not because the revenue ops company was careless, but because their vendor agreement didn't require transparency about sub-subprocessors. The fix for the next audit cycle: add contractual language requiring primary vendors to provide their own subprocessor list and notify you of material changes within 30 days.
What Contracts Need to Say for CC9.2
Vendor contracts are evidence. Auditors review them. The clauses that matter most for CC9.2:
- Security requirements and right to audit. Your agreement should require the vendor to maintain documented information security controls consistent with their SOC 2 or equivalent certification and to provide updated reports annually.
- Incident notification timelines. Specify the window in which the vendor must notify you of a security incident affecting your data — 48 or 72 hours is standard. This feeds your own incident response obligations under CC7.3.
- Subprocessor disclosure obligation. Require the vendor to disclose their material subprocessors and to notify you of changes. This closes the sub-subprocessor visibility gap.
- Data deletion on termination. Confirm timelines and methods for data destruction when the relationship ends — this is evidence for both CC9.2 and CC6.5 (logical access termination).
Not every vendor will agree to every clause. Large infrastructure providers (hosting, CDN, email delivery) have standardized terms and won't negotiate custom security addenda. For those vendors, your compensating control is relying on their published compliance programs and documenting why that's sufficient given your risk tier. That documentation is also evidence — it shows you thought about the risk rather than ignoring it.
Risk Tiering Your Vendor Portfolio
Not all vendors require the same depth of scrutiny. A risk-tiered approach focuses your limited GRC capacity where it matters. A practical three-tier model:
- Tier 1 — Critical processors: Vendors with direct access to production customer data or core infrastructure. Require annual SOC 2 review, contract review, and documented risk assessment. Examples: your primary cloud provider, database hosting, identity provider.
- Tier 2 — Significant processors: Vendors that access or process customer data indirectly or are involved in supporting operations. Annual SOC 2 review plus contract check. Examples: CRM, data warehouse, email delivery.
- Tier 3 — Low-risk vendors: SaaS tools used for internal productivity that don't touch customer data or production systems. Review during onboarding and at major contract renewal. Examples: design tools, internal wikis, team calendaring.
The tiering criteria — and the rationale for each assignment — are themselves evidence. Your auditor wants to see that you have a principled approach to prioritization, not just a spreadsheet of names.
What Tenurex Connects to This Control
When we built the vendor risk module in Tenurex, the design goal was to make the CC9.2 audit evidence package automatic rather than assembled manually six weeks before the audit window opens. Tenurex tracks your subprocessor inventory, records when each vendor's SOC 2 report was last reviewed, flags when a report is approaching expiration, and generates a timestamped audit log of every review event. That log is what the auditor actually needs — not just the reports themselves, but proof that someone reviewed them on a documented date and recorded a risk judgment.
The operational reality for a small GRC function is that vendor risk management is the most time-consuming compliance activity that also produces the least internal visibility. Teams know it's required, they do the work, but the work happens in email threads and shared folders rather than a system that produces searchable, timestamped evidence. When the auditor asks to see your vendor review evidence, "we sent emails asking for reports" doesn't satisfy CC9.2. The evidence needs to be structured, dated, and traceable to specific control activities.
Vendor risk management for SOC 2 is not primarily about whether your vendors are secure. It's about whether you can demonstrate that you have a functioning process for assessing and monitoring them. Those are related but different requirements — and understanding the distinction is what separates a clean CC9.2 opinion from a qualified one.