Describe a short, real process: a list of vendors with what data each touches, a tier based on that exposure, checks proportionate to the tier, and a review cycle. Name an owner. Small companies do not need an elaborate program, but they do need to show they know who their suppliers are.
What the buyer is trying to learn
Your customers' data often passes through your suppliers: hosting, email delivery, analytics, support tools, AI providers. The buyer cannot assess each of them, so they ask whether you do. NIST's guidance on cybersecurity supply chain risk management notes that risk arises from reduced visibility into how acquired technology is developed, integrated and deployed. Your answer shows how you restore some of that visibility for the parts you buy.
The four parts of a credible process
- Inventory. Every vendor, what service it provides, what data it receives, who in your company owns the relationship, and the contract date.
- Tiering. Sort by what happens if the vendor is breached or fails, not by spend. A cheap tool with access to customer data outranks an expensive tool with none. See TPRM vendor tiering by blast radius, not spend.
- Checks by tier. For the top tier, review a security report or questionnaire, check the data processing terms, confirm breach notice terms, and check for single sign-on. For lower tiers, a lighter check.
- Review cycle. Revisit top tier vendors yearly and on any news of an incident. See annual vendor security review cadence.
A table you can adapt
| Tier | Example | Checks | Review |
|---|---|---|---|
| 1 | Hosting, identity provider, data processors | Security report or questionnaire, contract terms, incident notice | Yearly |
| 2 | Tools with limited data | Short questionnaire, SSO check | Every two years |
| 3 | No data access | Contract basics | On renewal |
Include open source and fourth parties
Buyers increasingly ask about software components too. Say whether you keep an inventory of dependencies, scan them for known vulnerabilities, and track licenses. Mention that your key vendors have vendors of their own and that you ask about material subprocessors. See fourth party risk explained.
Honest wording for a small team
"We keep a vendor register with data exposure and an owner for each entry. Vendors that handle customer data are reviewed before onboarding and yearly after, using their security reports and our standard questionnaire. Other vendors receive a lighter review. We track vendor incidents and review affected suppliers."
If you do not do yearly reviews yet, say "reviewed at onboarding, with a yearly cycle starting on a stated date." Never describe a process in the present tense that has not begun.
Evidence to attach
- The vendor register, with names redacted if needed.
- Your vendor management policy.
- One example review with the outcome.
- Your public subprocessor list. See publish a subprocessor list: what to include.
Common mistakes
- Treating a vendor's certificate as the end of the review. Read what it covers.
- No offboarding step. Revoke access and confirm data deletion when you leave a vendor.
- A register that nobody updates after onboarding.
Try it yourself
Open the dependency inventory demo and see how third party components are listed with versions. This is the software side of the same supplier visibility question.
Click through it at your own pace, or open it full screen.
Safeguard offers SBOM and dependency scanning, which give you an inventory of the open source components in your own product.
Quick check
Do we need a tool to run vendor reviews?
No. A spreadsheet and a calendar work for a small vendor count. Move to a tool when the volume makes updates slip.
Is a vendor's SOC 2 report enough?
It is useful evidence, but read its scope, period and any exceptions, and check that the services you use are covered.
Sources
Last reviewed: 19 October 2026.
