Why this matters
Vendor risk management sits in one criterion with a lot of reach. CC9.2 in the Trust Services Criteria asks you to assess and manage risks that come from vendors and business partners. Your auditor tests it by pulling a sample from your vendor list and asking for proof: the review you did before signing, the contract terms you agreed, the security report you read and what you did about it.
A vendor is where your data goes when it leaves your building. If a payroll provider holds employee records, or a logging service sits in production, that vendor's controls carry part of your risk. SOC 2 does not ask you to audit them. It asks you to show that you picked them with your eyes open and keep watching.
Most failures here are not about missing tools. They are about a list built the week before fieldwork, with no dates, no owners and nothing showing what you found. An auditor cannot test a decision that was never written down.
One thing to get right early. If a vendor performs part of your system of record, it counts as a subservice organization, and your report has to describe how you monitor its controls. That description has to match what you actually do.
Before you start
Decide what counts as a vendor. Separate the ones that receive your data or touch production, the contractors who get system access, and everyone else. Only the first two groups need real work. Write the definition down so the list stays stable.
Choose a rating scale before you rate anything. Two inputs do most of the work: data sensitivity, meaning whether the vendor sees customer data, personal data or source code, and access, meaning whether it can reach production. Three tiers is plenty. Five will stall the process.
Build the first list from three sources. Export the vendor list from accounts payable, the app catalog from your identity provider, and cloud and SaaS billing. The lists will disagree, and the gaps are the interesting part: a service someone expensed on a card, an old app still wired into SSO, a contractor paid through another system.
Name an owner for the program and an owner for each vendor record. A vendor with no owner is the one that will be missing a contract when the sample lands.
How to do it
Treat this as a small process with fixed inputs, not a project. Each vendor record should answer three questions. What data or access does it have. What did we check before we signed. When did we last look again.
The strongest programs borrow from finance. A vendor cannot get paid the first time until its record is complete. That puts the control in front of the money instead of in front of the auditor.
- Reconcile the vendor list. Merge the accounts payable export, the SSO app catalog and billing into one sheet. Remove duplicates, then mark each row with an owner. Anything without an owner gets resolved before you go further.
- Rate each vendor. Score data sensitivity and access, then place the vendor in a tier. Record the reason in one line, for example holds customer backups, production read access. The reason matters more than the score.
- Write the requirements per tier. Decide what each tier must have before signing: a security questionnaire, a SOC 2 report, a data processing addendum, breach notice terms. Keep the list short enough that people follow it.
- Read the vendor report properly. Open the opinion first, then the tested controls and any exceptions. Check the period covered, the services in scope and whether a bridge letter fills the gap since the report ended. A qualified opinion or exceptions in access control should change your decision.
- Check the carve-out. If the report uses the carve-out method, it lists complementary controls your side has to run, such as reviewing who at your company can reach the vendor's admin panel. Add those to your own control set with evidence.
- Get the contract terms right. Cover the security addendum, the breach notification window, subprocessor notice, and data return and deletion on exit. Finance and legal should see the tier so the terms match the risk instead of the template.
- Record the decision. One line per vendor: tier, what you reviewed, findings, accepted or rejected, who approved, date. Store it next to the contract, not in a mailbox.
- Set review and offboarding dates. Schedule a review one year out for high tier vendors and at renewal for low tier. When a contract ends, revoke SSO access, get deletion confirmed in writing and close the record.
How to check it worked
Pick five vendors, one high tier, two medium, two low, and try to pull each full record in ten minutes without emailing anyone. If you have to ask a person, the evidence lives in a mailbox and will not survive turnover or a sample.
Take your newest vendor and walk backward from the first payment. Confirm the diligence finished before the contract was signed, or that someone accepted a named risk with a date. Out of order is fine when it is written down. Silent is not.
Sit your system description next to your vendor list. If the description names subservice organizations, check that the monitoring you claim is the monitoring you run, at the cadence you state. Auditors read those two documents together.
Run a monthly match between the vendor list and the SSO app catalog. Anything connected but unlisted is either a missing record or a tool that should be switched off.
Mistakes to avoid
The list built for the audit. A register that exists because fieldwork is coming will be wrong within a quarter. Make the same list drive invoice approval and access requests so it stays current by default.
Uniform diligence. A full questionnaire and a report request for a design tool satisfies nobody and burns goodwill with the vendor. Match effort to tier and write down why a vendor sits in the low tier.
Collecting reports and never reading them. Check the opinion, the period covered, the services in scope and any exceptions. A report covering a service you do not use, or one that ended two years ago, proves nothing.
Carve-out reports with no complementary controls on your side. The vendor's report assumes you review your own users, restrict admin access and watch for anomalies. If nobody does that, the control fails on your side of the line. Access left on after the contract ends belongs here too. Offboarding is part of vendor management: revoke SSO, confirm deletion, date the record.
If you want help structuring the vendor piece alongside the rest of your controls, the Cloudverg SOC 2 readiness assessment is a fixed price engagement at $7,500 that runs three weeks and covers scoping, a gap assessment against the Trust Services Criteria and a remediation roadmap. It is one option among several: a consultant, a compliance tool or an internal push can all get you there.
Frequently asked questions
What does SOC 2 require for vendor management?
CC9.2 in the Trust Services Criteria asks you to assess and manage risks from vendors and business partners. In practice, auditors look for a vendor inventory, a risk rating per vendor, documented due diligence before signing, contract terms that cover security, and a periodic review. You are not expected to audit your vendors yourself.
Do I need a SOC 2 report from every vendor?
No. Ask for one from the top tier, meaning vendors that hold customer data or reach production. For smaller vendors, a short questionnaire plus your own written acceptance of the risk is usually enough. Record the tier and the reason so the decision is testable.
How often should vendors be reviewed?
High tier vendors once a year, or at renewal, and sooner after a breach, a new subprocessor or a change in the service you use. Low tier vendors can wait for renewal. The review date and the evidence matter more than the interval.