Direct answer: SOC 2 CC9.2 requires you to assess and manage vendor risk, and a spreadsheet with logos in it does not satisfy it. We published our full program as vendor-risk-assessment-toolkit: a tiering methodology, an inventory template, a security questionnaire of more than seventy questions, a scoring rubric with domain weights, due diligence and offboarding checklists, a data processing agreement review checklist, and a Python tracker that flags overdue reviews. MIT licensed.
What CC9.2 actually requires
The criterion asks you to assess and manage the risks associated with vendors and business partners. It does not tell you how, which is why implementations vary so widely and why so many of them fail.
What an auditor tests is narrower than the wording suggests. They want to see a current inventory of vendors with some sense of what each one can reach. They want a risk-based approach, meaning you treat a vendor holding customer data differently from a vendor selling you office snacks. They want evidence that assessments happened at the frequency you claim, for the vendors your own methodology says warrant them. And they want to see that something happened when an assessment turned up a problem.
The same expectation appears almost verbatim across frameworks. ISO 27001:2022 covers it in A.5.19 through A.5.22. HIPAA handles it through business associate agreements at 164.308(b) and 164.314. PCI DSS uses 12.8 and 12.9. NIST CSF puts it under supply chain risk management. GDPR gets at it through Articles 28 and 32. One program, built once, satisfies all of them, which is the entire reason to build it deliberately rather than per audit.
Tiering is the decision that makes the rest work
The failure mode in most vendor programs is uniform treatment. Either every vendor gets the full questionnaire, which means the program collapses under its own weight by vendor number thirty, or nobody does, which means there is no evidence at all.
Tiering fixes it by making the depth of assessment follow the risk. The toolkit's framework tiers on what the vendor can actually reach: whether they hold or process customer data, whether they have access to production systems, whether an outage of theirs takes you down, and what a compromise of them would mean for your customers.
A vendor processing customer personal information in production is a different object from a design tool your marketing team uses, and treating them the same is not rigor, it is a misallocation that guarantees the important review does not get the attention it needs. Tier one gets the full questionnaire, evidence review and an annual reassessment. The bottom tier gets a recorded decision and a periodic check that it is still the bottom tier.
One refinement worth adopting: tier the use case, not just the logo. The same vendor can be low risk for one team and high risk for another, and the register entry should say what the intended use was so a later reviewer can notice when reality has drifted from it.
The questionnaire, and how to not annoy your vendors
The included questionnaire runs to more than seventy questions across the domains an auditor cares about: governance, access control, data protection and encryption, infrastructure and network security, software development, logging and monitoring, incident response, business continuity, personnel security, and sub-processor management.
Send all seventy to every vendor and you will get slow, low quality responses, because the person answering is doing it for the fortieth time this quarter. Two things make a real difference to response rate.
First, accept existing evidence instead of asking for prose. If a vendor has a current SOC 2 Type II or ISO 27001 certificate, read it, note which of your questions it answers, and only ask about what it does not cover. A report review is better evidence than a self-attested questionnaire anyway, and vendors respond quickly to being asked for a document they already have.
Second, send the tier-appropriate subset. The repository includes a completed example so you can see what a good response looks like before you send your first one.
If you would rather assemble the questionnaire interactively, the vendor questionnaire builder produces one scoped to the tier.
Scoring, so the answer is not a feeling
The scoring guide assigns weights by domain and gives explicit criteria for what a strong, adequate and weak answer looks like in each. This matters less for the score itself than for consistency: two people assessing the same vendor should land in roughly the same place, and next year's reviewer should be able to see why this year's reviewer decided what they decided.
It also gives you something to point at when the answer is uncomfortable. Telling a colleague that their preferred tool scored poorly on data protection with the rubric attached is a very different conversation from telling them you have a bad feeling about it.
The tracker, because the calendar is where programs die
The Python script in the automation directory reads the inventory and flags what needs attention: reviews past due, vendors missing documentation their tier requires, and agreements approaching expiry.
This is deliberately unglamorous, and it addresses the most common failure we see. Somebody builds an excellent vendor register during a compliance push and nobody opens it for eleven months. Then fieldwork arrives, the auditor asks for evidence of the annual reassessments, and there are none.
The fix is not discipline. It is attaching the review to something that already happens. Quarterly access reviews are the natural host, since you are already going vendor by vendor through who has access to what. Run the tracker in the same week, and the two chores share a calendar slot instead of competing for one.
Where these programs actually fail
The register that was never true. Built from memory rather than from evidence. Pull the application list from your identity provider and the last two quarters of card statements, and you will find vendors nobody remembered. Do that first, before designing anything.
Assessment without consequence. A vendor scores badly and nothing happens, because nobody owns the decision to accept, mitigate or replace. An assessment that cannot change an outcome is paperwork, and auditors notice when every assessment concludes acceptable.
Onboarding covered, offboarding forgotten. The terminated vendor still has an integration token in production. This is why the toolkit includes an offboarding checklist, and it is the item most home-built programs are missing.
AI vendors treated as a separate regime. They are not. They are vendors with specific extra questions attached: whether your data trains a model, where inference happens, and whether you can disable processing per tenant. Our writeups on agentic AI vendor risk cover the questions worth adding. Running two registers that disagree is worse than running one.
Take it
Everything is at github.com/TrazTech-Inc/vendor-risk-assessment-toolkit, MIT licensed, including the framework mapping document that shows which component satisfies which requirement in each standard. Start with the inventory, tier what you find, and assess downward from the top tier until you run out of vendors that matter.
Vendor review due and nobody owns it? We stand the program up, run the assessments, and keep the register true between audits.
Vendor risk managementOr how we work on retainer