Vendor Security Risk Assessment: Tiers, Questions and Evidence
A vendor security risk assessment sorts your suppliers by how much damage they could cause, then checks the risky ones more thoroughly before you sign and each year after. Tier vendors first. Then ask questions and request evidence in proportion to the tier.
Most small companies fail at this by sending every vendor the same long questionnaire or by skipping the review entirely. The template below avoids both.
Vendors Covered in this Article
Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.
How do you tier vendors by risk?
Ask two questions about each vendor: what data can they reach, and what happens to you if they fail? Then assign a tier:
- Tier 1, high. Handles customer or regulated data, or an outage would stop your service. Examples: cloud host, identity provider, payments, customer support platform with ticket contents.
- Tier 2, medium. Handles internal business data, or you can work around a failure for a few days. Examples: project tracker, HR system.
- Tier 3, low. No sensitive data and easy to replace. Examples: a design font service, a public-data research tool.
Record the tier, the data types involved and the business owner in a vendor inventory. New vendors should enter the inventory before purchase, so security review happens before the contract, not after.
What do you ask at each tier?
Match effort to risk:
- Tier 3: a basic check. Does the vendor have a published security page and privacy policy, and do they support single sign-on if employees will use it?
- Tier 2: a short questionnaire, plus a review of any independent report they share.
- Tier 1: the full review: independent audit reports, a detailed questionnaire, contract terms and a named internal owner.
For Tier 1, typical questions cover encryption in transit and at rest, access controls for the vendor's own staff, how they handle vulnerabilities, incident notification timing, subprocessors, data location, backups and deletion at contract end. If the vendor answers with generic marketing, ask for evidence. Also ask what they need from you: a shared responsibility split matters, such as who configures access on your side.
How do you read a SOC 2 report someone sends you?
A report is only useful if you read the right parts:
- Scope. Does the report cover the product you actually use, or a different service?
- Period and type. Does it cover a period that ends recently enough, and is it Type 2?
- Criteria. Which Trust Services Criteria are covered? A report on security alone won't address availability.
- Exceptions. Look at the auditor's tested controls for deviations, and read the vendor's responses.
- Complementary user entity controls. These are controls the vendor expects you to run yourself, such as reviewing your own user access. If you don't do them, the report's assurance doesn't fully apply.
- Subservice organizations. Which parts rely on another provider's controls?
Write a two-line summary in your inventory: what's covered, what isn't, and what you must do on your side.
Which contract terms belong in the assessment?
Security review and contract review should meet. For Tier 1 vendors, check with your attorney that the agreement addresses:
- A data processing agreement where personal data is involved, and a business associate agreement if health data is.
- Breach notification timing and content.
- Subprocessor lists and a way to be told of changes.
- Data return and deletion when the contract ends, in a usable format.
- Audit or evidence rights, and the vendor's obligation to keep its attestations current.
- Liability terms proportional to the risk.
Requirements for regulated data come from your obligations: see the HIPAA risk assessment worksheet for health data. If exit will be difficult, consider the lock-in points, as covered in vendor lock-in exit planning for developer platforms.
How do you keep assessments alive after onboarding?
Put reviews on a schedule instead of relying on memory:
- Review Tier 1 vendors yearly and Tier 2 vendors every other year, or sooner after a reported incident.
- Renew evidence: request the latest report and check its scope again.
- Track renewal dates and reassess before auto-renewal.
- Offboard cleanly: revoke access, retrieve or delete data and record the confirmation.
- Log vendor incidents and what you did about them.
A compliance platform such as Vanta or Drata can help you keep the inventory, review reminders and reports together, which helps when customers ask how you manage suppliers. Your own customers will send you the same questions in reverse, so keep your answers to security questionnaires consistent with how you treat your suppliers.
What Good Looks Like
Every vendor is in an inventory with a tier, an owner and a review date, and high-risk vendors have evidence on file.
Building The Capability (5-Stage Skill Ladder)
How to Get Started
Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.
Frequently Asked Questions
What is a vendor risk assessment?
It's a structured review of a supplier's security and reliability before you rely on them and periodically afterward. It sorts vendors by risk, asks proportionate questions, checks evidence such as audit reports and reviews contract terms on data handling and breach notice.
How many vendors should I assess?
Inventory all of them, but assess in depth only those that handle sensitive data or whose failure would disrupt you. You'll likely find only a handful of high-risk vendors. Tiering lets you spend time where it matters instead of reviewing everything equally.
What if a vendor won't share a security report?
Ask why, and whether they'll share it under NDA. If they can't provide independent evidence, ask detailed questions and consider limiting the data you give them. For high-risk uses, lack of transparency is a valid reason to choose another vendor.
How often should vendor assessments be repeated?
Yearly for high-risk vendors and less often for lower tiers, plus whenever something changes, such as a breach, an acquisition or a new type of data shared. Tie reviews to renewal dates so they happen before you commit again.
About the numbers
This guide doesn't quote a sourced benchmark. Figures in it are estimates or general guidance, so check them against your own numbers.
Related Guides
HIPAA Security Risk Assessment: A Worksheet for Small Teams
Run a HIPAA security risk analysis in six steps: inventory ePHI, find threats, rate risk, plan fixes and keep records. Worksheet columns included.
The Real Cost of Vendor Lock-In (and When to Actually Migrate)
How to tell whether a vendor dependency is a real business risk or just an inconvenience, and what a realistic exit actually costs you.
How to Answer Security Questionnaires Faster With an Answer Library
Build a reusable security questionnaire response library: answer format, evidence links, owners and review rules so sales reviews close in days, not weeks.
The Vendor Exit Checklist: What to Verify Before You Depend on a Platform
A checklist for CTOs to run before adopting a platform vendor, covering the export paths, contract terms, and pitfalls that turn dependence into lock-in.
The Portability Audit: What It Costs to Leave a Vendor
A checklist for finding out what it would really take to leave a cloud vendor or platform, before you're forced to find out during a price increase.
Spotting Vendor Lock-In Before It Costs You an Exit
A practical checklist for spotting vendor lock-in in your identity, API, and infrastructure stack before switching costs become the deciding factor.