Vendor risk management is the process of knowing which outside companies can hurt your business, deciding how much scrutiny each one deserves, and checking them on a schedule. For a small or mid-sized business the whole process fits on two tabs of a spreadsheet: an inventory of every vendor with what they touch, and a short due diligence record for the handful that matter most.
The mistake almost everyone makes is treating every vendor the same. Your payroll processor and your office coffee supplier do not belong in the same workflow. Tiering is what makes the process survivable.
Why vendors became the question customers ask first
When a customer sends you a security questionnaire, a large block of it is about your vendors, not you. The reasoning is simple: your subcontractors inherit whatever access you have, and your customer's data can end up sitting with a company they never chose.
Regulators think the same way. The EU's GDPR requires a written agreement with each processor and holds the controller responsible for choosing competent ones. US financial regulators publish interagency guidance on third-party relationships that applies the same proportionality logic. You do not need to be in a regulated sector for your customers to borrow the standard.
Step one: build the vendor inventory
You cannot manage a list you do not have, and most businesses discover they have two to three times more vendors than they expected.
Pull the list from three places and merge them. Start with your accounting system: every recurring payment to a company is a vendor. Then pull your single sign-on or identity provider for every application anyone has connected. Then ask each team lead what tools they use, because the ones bought on a personal card never appear in the first two sources.
For each vendor, capture six fields and nothing more at this stage:
- Vendor name and what it does in one line
- The internal owner, by name
- What data it can see (none, business data, customer personal data, payment data, credentials)
- Whether it can change or delete your data or only read it
- Whether revenue stops if the vendor stops
- Annual spend
That is the inventory. It is useful on its own, before any assessment work at all, because it answers the two questions you will be asked most: who touches customer data, and what happens if a supplier fails.
Step two: tier your vendors by exposure
Tiering decides how much work each vendor gets. Use three tiers and keep the definitions written down.
| Tier | What puts a vendor here | Due diligence depth | Review cadence |
|---|---|---|---|
| Tier 1 — Critical | Holds customer personal or payment data, has administrative access to your systems, or revenue stops within a day if it fails | Full questionnaire, review of their security documentation, contract terms checked, named contact | Annually, plus on any major change |
| Tier 2 — Important | Holds internal business data, or a failure disrupts operations within a week | Short questionnaire, confirmation of their security page and breach notification terms | Every two years |
| Tier 3 — Low | No access to meaningful data, easily replaced | Inventory record only | On renewal |
Most SMBs find five to fifteen vendors in Tier 1 and the long tail in Tier 3. That ratio is the point. It concentrates your effort where a failure would actually matter.
Two rules keep tiering honest. First, access beats spend: a free tool with administrative rights outranks an expensive one that sees nothing. Second, anyone who can reach production or customer data is Tier 1 regardless of company size, including individual contractors.
Step three: run proportionate due diligence
For Tier 1 vendors, work through a short, fixed set of questions. Asking the same questions every time is what lets you compare answers.
- Where does our data live and who else can see it? You are looking for hosting regions and the vendor's own subprocessor list. A vendor who cannot produce a subprocessor list is telling you something.
- How do they control access internally? Multi-factor authentication for their staff, role-based access, and a joiner-mover-leaver process.
- What do they publish about their own security posture? Many vendors maintain a trust page with their current attestations and policies. Read what it says and note the date. Your job is to record what they claim and when, not to validate it yourself.
- What are the breach notification terms in the contract? You want a defined window and a named route. "Without undue delay" with no contact path is not usable when something happens.
- How do we get our data out? Export formats, retention after termination, and whether deletion is confirmed in writing.
- What is the realistic exit path? Name the alternative vendor and estimate the switching time. A dependency with no named alternative is a risk register row, not a procurement note.
- Who is our named contact and their escalation? Two names. Support queues are not an escalation path during an incident.
Record the answers with the date and who asked. Short answers are fine. The record is the deliverable.
What to do when a vendor will not answer
Small vendors sometimes cannot answer a security questionnaire at all. That is not automatically disqualifying, but it has to go somewhere. Write the gap into your risk register, note the compensating control you are putting in place, and record that you accepted it knowingly. A documented acceptance survives scrutiny. Silence does not.
Step four: get the contract terms right
Four clauses do most of the work, and they are easier to get before you sign than after.
A data processing term that names the purpose, the categories of data and the deletion obligation. A breach notification window with a stated number of hours or days. A subprocessor clause requiring notice before they add new ones. And a termination assistance term covering export and deletion.
For Tier 1 vendors handling personal data, a data processing agreement is usually standard and available on request. Ask for it as a matter of routine.
Step five: review on the cadence you set
Annual review for Tier 1 means a short pass: confirm the owner is still correct, re-read their trust page for changes, check whether their subprocessor list grew, and ask whether any incident occurred in the past year.
Trigger an off-cycle review on four events: the vendor is acquired, they announce a security incident, you expand what data you send them, or your internal owner leaves. These four catch most of the cases where a stale assessment becomes dangerous.
Common vendor risk management mistakes
Assessing at purchase and never again. Vendor risk is not a one-time gate, and the risk profile usually grows as you send them more data.
Confusing a vendor's security posture with your own. Using a well-secured platform does not transfer its posture to you. Your configuration of it is still yours.
Ignoring the sub-vendors. Your Tier 1 vendor's vendors are where surprises live. The subprocessor list is the cheapest early warning available.
Leaving contractors out. Individual freelancers with system access are third parties. Put them in the inventory.
Treating infrastructure as invisible. Hosting, edge security, WAF and DDoS protection, email delivery and identity providers are vendors like any other, and they are usually Tier 1.
Getting the first version done
Spend one afternoon on the inventory. Tier it the same day. Then work through Tier 1 due diligence at a pace of two or three vendors a week until it is done. A complete inventory with five finished Tier 1 assessments is more defensible than a perfect framework with nothing in it.
Once the inventory exists, most of a customer security questionnaire can be answered from it directly, which is usually the moment this work starts paying for itself.
To work through tiering and due diligence against your own vendor list, start with the Risk Management capability page on this site.