Vendor Risk Management (VRM)
Vendor risk management is how you find, judge and keep watching the risks that come from the companies you buy from, such as data leaks, outages, price increases and changed terms. It runs from picking a vendor to leaving it.
What is vendor risk management?
Vendor risk management (VRM) is how you find, judge and keep an eye on the risks that come from the companies you buy from. For a SaaS company, those vendors are mostly other software tools: your cloud host, CRM, payment processor, support desk, analytics and AI tools.
Each vendor can hurt you in a few ways. It can leak your data or your customers' data. It can go down and take part of your product with it. It can raise prices, change its terms, or start using your data in a way you did not agree to when you signed up.
VRM is not only a big-company practice. The NIST Cybersecurity Framework 2.0, a free US government guide, asks that "suppliers are known and prioritized by criticality" (control GV.SC-04). The SOC 2 criteria include CC9.2: "The entity assesses and manages risks associated with vendors and business partners." If you sell to companies that ask for a SOC 2 report, you need a VRM process an auditor can test.
You also do not need a bank-sized program. Even the US bank regulators' 2023 guidance says risk management should be "commensurate with the banking organization's size, complexity, and risk profile". For a 20 to 100 person company, a spreadsheet, a short policy and a few habits will cover most of it.
The five steps for a small company
Most frameworks describe the same life cycle. The 2023 US interagency guidance names planning, due diligence, contract negotiation, ongoing monitoring and termination. Here is the same idea scaled down.
- Inventory. Keep one list of every vendor, what it does, who owns it inside your company and what data it touches. This is your vendor inventory.
- Assessment. Before you sign, check how risky the vendor is. Look at its security reports, its DPA and its subprocessor list. This is a vendor risk assessment.
- Contract. Read the terms that decide what happens later: who can change them, how much notice you get, what happens to your data and what the vendor owes you if something breaks.
- Monitoring. Watch the vendor while you use it. Security reports expire, subprocessors get added and terms get rewritten.
- Exit. When you leave, get your data out, confirm deletion and remove access. This is vendor offboarding.
Not every vendor needs the same effort
NIST's supply chain quick-start guide suggests ranking suppliers by criticality using factors like the sensitivity of data the supplier handles and its access to your systems. In practice, that means sorting vendors into two or three tiers. A vendor that holds customer data or runs your product gets a full review. A design tool with no customer data gets a light one. This is vendor tiering.
Who owns it in a small company
In a 20 to 100 person company, VRM rarely has its own team. Often one person (a security lead, an ops manager or a founder) owns the process, and each vendor has a business owner who uses it day to day. The SOC 2 points of focus for CC9.2 include assigning responsibility and accountability for managing vendors, so write both names down.
The process owner keeps the list, runs reviews and decides when a finding needs action. The business owner answers practical questions: what data goes into the tool, who has access, and whether you still need it.
The step that often gets skipped
Many small teams do steps 1 to 3 once, at purchase, and then stop. Monitoring is the step that falls through, and document changes are an easy part of it to miss.
A security questionnaire is a snapshot taken on the day you bought. The vendor's Terms of Service, privacy policy, DPA and subprocessor list keep moving after that day. A change to any of them can alter what you agreed to without anyone at your company signing anything new.
What it looks like in a vendor's terms
The clause that makes monitoring necessary is the change clause. A typical clause reads like this:
We may modify these Terms from time to time. We will post the updated Terms on our website and update the "Last Updated" date. If a change is material, we will make reasonable efforts to notify you. Your continued use of the Services after the changes take effect means you accept them.
- "We may modify these Terms" is a unilateral amendment clause. The vendor can change the deal without your signature.
- "Post the updated Terms on our website" means the notice may be nothing more than a new version of a web page.
- "If a change is material" lets the vendor decide which changes are big enough to tell you about. See material change.
- "Continued use" tries to treat your silence as agreement. See continued use as acceptance: courts do not always accept it and the rules vary by state, but you should not count on it failing.
Subprocessor changes work the same way. Atlassian's DPA promises notice of new subprocessors "to those emails subscribed, at least thirty (30) days" ahead, through a mechanism you have to sign up for. Stripe's DPA likewise sends notice by email if you subscribe on its subprocessor page. If nobody at your company signed up, the notice goes nowhere.
A real change we caught
Venpo flagged a change to Hotjar's DPA, the contract that governs how Hotjar handles personal data for its customers: Hotjar's DPA can now change without your signature. In the June 2026 version, Contentsquare (which now runs Hotjar) can change the DPA at its sole discretion, and the main sign of a change is a new "Last updated" date. Before, changes needed both sides to agree in writing. If you reviewed that DPA when you bought the tool, the version in your file may no longer be the one that applies.
This is the gap VRM programs miss. The review was done. The contract was signed. Then the document changed, and the vendor file still showed the old answer. We wrote more about this pattern in The hidden risk of vendor legal changes.
Why it matters to you
Money. Vendors change pricing rules, add overage charges or remove renewal caps in their terms. If you only read terms at purchase, you find out at the next invoice.
Your data. A vendor can add a new subprocessor, start training AI on customer content, or keep data longer after you leave. Each of these changes where your data goes and how long it stays there.
Your promises to customers. Your own DPA and privacy policy describe how you handle customer data, including which vendors touch it. If you process personal data on behalf of EU customers, GDPR Article 28(4) says the "initial processor shall remain fully liable" to the customer for the other processors it brings in. When a vendor changes its terms, your promises to your customers can become untrue without you changing a word.
Your audit. A SOC 2 auditor will test whether you follow your own vendor process. A vague rule like "vendors are reviewed periodically" is hard to prove you followed. Write down what you will do and how often, then do it.
What to check
- Your list is complete. Compare your vendor list against card statements, accounts payable and the apps connected to your login provider. Anything missing is a vendor nobody reviewed.
- Each vendor has a tier and an owner. One named person per vendor, and a tier that sets how deep and how often you review it.
- You have the key documents for top-tier vendors. The current SOC 2 report, the signed or accepted DPA, the subprocessor list and the Terms of Service version you agreed to.
- You know how each vendor notifies changes. Find the change clause in its terms and the subscribe link on its subprocessor page. Sign up with a shared inbox, not one person's email.
- You have a way to see changes between reviews. Decide how you will learn about new terms, new subprocessors and new AI uses before your annual review.
- You have an exit plan for critical vendors. Know how to export your data, how long the vendor keeps it after you leave, and how you will confirm deletion.
How Venpo helps
Venpo covers the monitoring step for vendor documents. It watches your vendors' Terms of Service, privacy policies, DPAs, subprocessor lists and other public legal pages, and emails you a plain-English alert when one changes, with what changed and why it matters. Each vendor gets a change history you can show an auditor, and the Fine Print Scan answers four questions per vendor: does it train AI on your data, how long does it keep data, does it sell data or use it for ads, and can it raise prices.
Frequently asked questions
Does a small startup need a vendor risk management program?
If you hold customer data or plan to get a SOC 2 report, yes, but it can be small. A vendor list with owners and tiers, a one-page policy, a review before you sign and a way to see changes covers the basics.
Is vendor risk management the same as third-party risk management?
They overlap heavily. Third-party risk management is the broader term and can include partners, resellers and contractors, while vendor risk management focuses on the companies you buy products and services from.
What is the difference between vendor management and vendor risk management?
Vendor management covers the whole relationship, including buying, budgets and performance. Vendor risk management is the part that asks what could go wrong with a vendor and what you do about it.
How often should I review my vendors?
No standard sets one number for every vendor. A common model is to review critical vendors at least once a year and lower tiers less often, plus a review whenever a vendor changes its terms, its subprocessors or its security report.
What tools do I need to start?
A spreadsheet is enough to start. Add a shared inbox for vendor notices and a calendar for renewals, then add tools when the list gets too long to track by hand.
Related terms
Sources
- NIST: The NIST Cybersecurity Framework (CSF) 2.0 (CSWP 29)
- NIST SP 1305: CSF 2.0 Cybersecurity Supply Chain Risk Management Quick-Start Guide
- Federal Register: Interagency Guidance on Third-Party Relationships, Risk Management (June 9, 2023)
- Atlassian Data Processing Addendum
- Stripe Data Processing Agreement
- GDPR Article 28: Processor
- AICPA: 2017 Trust Services Criteria, with revised points of focus (2022)
Last reviewed