SOC 2 requires vendor management. Here's exactly what auditors want to see.

SOC 2 is structured around five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Vendor management sits within the Security criterion, specifically under the Common Criteria related to risk management.

The relevant control is CC9.2:

In plain English: you need to know who your vendors are, what risk they present, and what you’re doing about it. Not in theory — in documented, evidenced practice that an auditor can review and test.

CC9.2 is assessed during both Type I (point-in-time design effectiveness) and Type II (operational effectiveness over a period, typically six or twelve months) audits. For Type II in particular, you need to show not just that you have a vendor risk process, but that you’ve actually been operating it — consistently, repeatedly, with evidence.

SOC 2 auditors approach CC9.2 by looking for evidence across four interconnected areas. Understanding what they're testing — rather than just what the control says — is the key to being genuinely prepared rather than just paper-compliant.

Beyond these four areas, auditors are increasingly looking for vendor security certifications on file (do your critical vendors hold SOC 2 or ISO 27001 themselves?), evidence of how you handle vendor offboarding, and your process for assessing new vendors before giving them access to your systems.

Most of the companies that struggle with CC9.2 aren't struggling because of a lack of effort — they're struggling because vendor management falls between roles. It's not quite engineering, not quite legal, not quite ops. The result is that it gets deprioritised until the audit prep sprint, when there's no time to do it properly.

• The vendor list is incomplete. The most common finding. Teams list their obvious vendors — AWS, Stripe, GitHub — but miss the long tail: the HR tool with access to employee data, the analytics platform with a tracking snippet on every page, the freelancer with API credentials. Auditors probe for these gaps specifically.
• Risk assessments exist on paper but not in practice. Many companies have a vendor risk policy that says assessments should happen annually. When asked for evidence of the last assessment, they can't produce it. A policy without evidence of execution is worse than no policy — it demonstrates that the process isn't working.
• Vendor agreements lack security clauses. CC9.2 requires your vendor relationships to address security risk. Clicking through a vendor's standard terms of service doesn't satisfy this — you need agreements with explicit provisions around data protection, breach notification, and security obligations. Many startups don't have these with their critical vendors.
• No evidence of ongoing monitoring. For Type II audits covering a 6–12 month period, you need to show that vendor risk management has been happening continuously — not just in the week before the audit. Without a system that timestamps reviews and monitors for changes, proving ongoing monitoring is very hard.
• Vendor offboarding is undocumented. When a vendor relationship ends, what happens to your data? To their access credentials? SOC 2 auditors are increasingly asking about offboarding processes — and finding that most companies have none documented.

You don't need a dedicated GRC team or a six-figure enterprise platform to satisfy CC9.2. What you need is a system that produces the evidence an auditor needs — consistently and without a lot of manual effort. Here's what that looks like in practice:

A complete, classified vendor register

Every vendor with access to your systems or data should be in your register, classified by their risk level. Critical vendors — those that handle customer data, have direct system access, or are essential to service delivery — should be reviewed more frequently and in more depth than lower-risk tools. The classification doesn't need to be complex; a simple Critical/High/Medium/Low taxonomy is enough for most SOC 2 audits.

Formal risk assessments with a paper trail

For each vendor, especially critical ones, you should be able to show a risk assessment — what data they access, what their security posture looks like, what certifications they hold, and what your residual risk judgement is. The assessment doesn't need to be exhaustive, but it needs to be documented, dated, and attributed. "We looked at this" is not evidence. "We assessed this on this date, the outcome was this, and it was reviewed by this person" is.

Vendor agreements with security provisions

For any vendor handling personal data, you need a Data Processing Agreement (DPA). For critical vendors more broadly, your contracts should include provisions around security obligations, breach notification timeframes, and your right to audit or receive security certifications. Getting these in place is a one-time effort per vendor, but it’s one that many companies have avoided. The SOC 2 process is often the forcing function that gets it done.

Ongoing monitoring and an audit trail

Ongoing monitoring means something happened after the initial assessment. For Type II audits, you need to demonstrate that vendor risk is reviewed at least annually for all vendors and more frequently for critical ones — and that you have a mechanism for detecting and responding to material changes, such as a vendor suffering a security breach or coming under sanctions.

A clear offboarding process

When a vendor relationship ends, you should be able to show what happened: access was revoked, data was retrieved or deleted per the contract terms, and the vendor was marked as inactive in your register. This doesn't require a complex process, but it does need to be documented and consistently followed.

Vendorapp is built around the evidence that SOC 2 auditors need. Everything it produces — vendor registers, risk assessments, monitoring records, contract registers, audit trails — is designed to be exportable and auditor-ready from day one.

1. 1

   Build a complete vendor register

   Search 22M+ vendors by name or URL and add your entire vendor stack in minutes. Every vendor gets a profile with their risk classification, contact information, contract status, and full assessment history. Nothing falls through the cracks because there's no spreadsheet to maintain.

2. 2

   Run automated risk assessments

   Vendorapp Intelligence scores every vendor automatically on security posture, data exposure, ESG risk, and sanctions exposure. Each assessment is timestamped and stored — giving you the dated, attributable evidence that Type II auditors look for. You can also add your own inherent and residual risk scores to create a complete dual-rating picture.

3. 3

   Centralise contracts and DPAs

   Upload your vendor contracts and Vendorapp Intelligence extracts key terms automatically — contract type, value, expiry date, renewal terms. Your DPAs and security agreements are stored alongside your vendor profiles, findable in seconds during an audit evidence request.

4. 4

   Monitor continuously without manual effort

   Smart alerts notify you of vendor security incidents, sanctions changes, and contract expiries automatically. Continuous screening against OFAC, UN, EU, UK OFSI, and DFAT watchlists runs in the background. Your ongoing monitoring is happening whether or not anyone remembers to do it — and there's an audit trail to prove it.

5. 5

   Export audit-ready evidence on demand

   When your auditor asks for CC9.2 evidence, you export — not scramble. Vendorapp generates complete vendor risk reports with your register, classifications, assessment history, monitoring records, and contract status. Inactive vendors are preserved in your history, never deleted, so your offboarding record is automatic.

What your auditor will be able to see

• Complete vendor register with risk classifications
• Timestamped risk assessments with inherent and residual scores
• Ongoing sanctions and watchlist screening history
• Contract register with expiry dates and DPA status
• Security breach and incident monitoring records
• Full audit trail of all vendor changes, assessments, and decisions
• Inactive vendor history — offboarding preserved, never deleted

If you're using Vanta, Drata, Sprinto, Secureframe, or a similar SOC 2 automation platform, you'll know that they surface CC9.2 as a control that requires active management — but they don't manage your vendor risk for you. They tell you the control needs to be satisfied; Vendorapp is how you satisfy it.

The typical workflow is: your SOC 2 platform flags vendor management as a required control, you manage your vendor risk in Vendorapp, and when your auditor needs evidence you export from Vendorapp and provide it as part of your SOC 2 evidence package. Many teams share their Vendorapp reports directly with their auditors or link them as evidence within their SOC 2 platform.