Vendor Risk Assessment

What is a vendor risk assessment?

A vendor risk assessment is a check of how much risk a vendor brings and whether you can live with it. You do it before you sign, and again when something important changes. It is the second step of vendor risk management, right after listing your vendors.

NIST's Cybersecurity Framework asks you to do this kind of check "before entering into formal supplier or other third-party relationships" (GV.SC-06). The SOC 2 points of focus for criterion CC9.2 include assessing vendor and business partner risks.

The depth should match the vendor. NIST suggests judging criticality by things like the sensitivity of data the supplier handles and its access to your systems. A tool that holds customer data gets a full review. A tool with no data and no access gets a short one.

A basic assessment for a small company answers four questions:

1. What data will this vendor get, and whose data is it?
2. What happens to you if the vendor is down for a day or leaks that data?
3. What do its documents promise: SOC 2 report, DPA, privacy policy, Terms of Service and subprocessor list?
4. What is left over after those promises, and is someone willing to accept it?

What it looks like in a vendor's terms

An assessment depends on what the vendor agrees to share. A typical clause reads like this:

On written request, and no more than once a year, Provider will give Customer a copy of its most recent third-party audit report, subject to confidentiality. Provider will also answer reasonable security questions that the report does not address.

• "No more than once a year" limits how often you can ask, which shapes your review schedule.
• "Subject to confidentiality" usually means signing an NDA before you get the report.
• "Questions that the report does not address" means the vendor expects you to read the report first.

A real change we caught

Venpo caught that Lovable now trains its AI on your prompts and code by default. Its old privacy policy said project content would never train general-purpose models for other customers without permission. Since September 9, 2026, Free and Pro plans train on prompts and code unless you opt out. An assessment filed before that date now shows the wrong answer.

Why it matters to you

An assessment is what you show an auditor and your own customers when they ask how you chose a vendor. It is also where each vendor's tier in your vendor inventory comes from.

It is also a snapshot. The answers you record are true on the day you check. If the vendor changes its terms a month later, the file is out of date. That is why assessments pair with continuous vendor monitoring.

What to check

• The SOC 2 report covers the product you are buying and its audit period is recent.
• The DPA names how fast the vendor tells you about a breach and what happens to data when you leave.
• The subprocessor list shows where your data goes. Atlassian's list, for example, gives purpose, data types and processing locations for each provider.
• The Terms of Service say how much notice you get before changes.
• Someone with authority signs off on what is left over, and the date is recorded.

Vendor Due Diligence

Vendor due diligence is the homework you do before you sign. It is the information-gathering part of an assessment. NIST's CSF puts it simply: "Planning and due diligence are performed to reduce risks before entering" a supplier relationship. A short checklist for a small company:

• Collect the latest SOC 2 Type 2 report or ISO 27001 certificate.
• Read the DPA and save the version you accept.
• Save the current subprocessor list and subscribe to updates.
• Read the Terms of Service clauses on changes, renewal, liability and data after termination.
• Check whether the vendor trains AI on your data and whether you can opt out.
• For high-risk vendors, send a short security questionnaire covering anything the documents leave open.
• Record who reviewed it, the date and the decision.

Keep it proportional. A vendor with no data needs the first and last items only.

AI Vendor Risk Assessment

An AI vendor risk assessment adds questions for tools that use AI on your data, or that send your data to an AI provider. A normal security review does not cover what the AI does with your inputs. Add these questions:

• Does the vendor train its models, or anyone's models, on your content? Is that on by default?
• Can you opt out, and does the opt-out cover past data?
• How long are prompts and outputs kept? Is zero data retention available?
• Which AI providers are on the subprocessor list?
• Who owns the output, and who is responsible if it is wrong or infringes someone's rights?

These answers change often. For example, Replit dropped its no-training promise for Pro customers, so an assessment done before that change would show the old answer. See AI training on customer data for more.

Inherent vs Residual Risk

Inherent risk is how risky a vendor is before you count any safeguards. Residual risk is what is left after the safeguards. The gap between them is what your controls and the vendor's controls take away.

For example, a payroll tool holds employee bank details and Social Security numbers. Its inherent risk is high no matter how good the vendor is. Then you count the safeguards: a clean SOC 2 Type 2 report, single sign-on, encryption and a DPA with a short breach notice period. The residual risk drops to something you might accept.

Inherent risk decides the tier and how deep you look. Residual risk decides whether you sign. If residual risk is still too high, you add a control (limit what data goes in, turn off a feature), negotiate terms, or pick another vendor. Write down who accepted the residual risk, because the SOC 2 points of focus include assigning responsibility and accountability for vendors.

How Venpo helps

Venpo keeps your assessment from going stale. Its Fine Print Scan answers four questions for each vendor (does it train AI on your data, how long does it keep data, does it sell data or use it for ads, can it raise prices), and Venpo emails you a plain-English alert when the vendor's terms, privacy policy, DPA or subprocessor list change.