# Vendor Due Diligence: Third-Party Risk Checklist

- url: https://www.tryplox.com/blog/vendor-due-diligence
- date: 2026-07-01
- tags: Due Diligence, Data Rooms
- excerpt: The first time a vendor I had cleared turned into a problem, it was not a dramatic breach. It was a quiet email from their account team saying they were "winding down" a product line we depended on, w

The first time a vendor I had cleared turned into a problem, it was not a dramatic breach. It was a quiet email from their account team saying they were "winding down" a product line we depended on, with 90 days of notice. We had signed them because the demo was good and the price was right. Nobody had asked what happens if they disappear. That is the gap vendor due diligence closes: you check the company behind the contract before you hand them your data, your money, or a dependency you cannot easily unwind.

This guide covers vendor due diligence in the third-party risk sense, the review you run on a supplier, SaaS tool, or service provider before and during the relationship. It is a different exercise from the seller-side "vendor due diligence" report in some M&A deals, where the target commissions its own diligence pack. If you came here for that, the broader [due diligence](/blog/due-diligence-guide) pillar walks through deal-stage diligence end to end. Here, the "vendor" is the third party you are buying from, and the job is to decide whether they are safe to rely on.

## What vendor due diligence actually is

Vendor due diligence is the structured assessment of a third party's security, financial health, legal standing, and operational reliability before you sign and on a recurring basis after. The point is not a binder nobody reads. It is to surface the handful of risks that could actually hurt you (a vendor leaking your customer data, going insolvent mid-contract, failing a compliance requirement you inherit, or holding you hostage at renewal) and to decide whether the value is worth those risks.

I think about it across four buckets:

- **Security and data:** how they protect data, where it lives, who can access it, and what happens in a breach.
- **Financial and business viability:** whether they will still be around, and stable, through the term of the contract.
- **Legal and compliance:** contracts, liability, regulatory posture, and any obligations that flow down to you.
- **Operational dependency:** how critical they are, how hard they are to replace, and whether you can exit cleanly.

The depth scales with the stakes. A design tool that touches no customer data gets a light touch. A payments processor or a vendor with access to your production database gets the full treatment, closer to the [enhanced due diligence](/blog/enhanced-due-diligence) you would run on a high-risk counterparty.

## Who runs it, and when

In a small company, the person who owns the vendor relationship runs it, often a founder or an ops lead, with a security-minded engineer pulled in for the technical part. As you grow, this splits: procurement owns the process, security owns the assessment, legal owns the contract, and finance signs off on the spend. The thread that should not break is that someone owns the decision, not just the paperwork.

Four moments matter most:

1. **Before you sign.** This is the obvious one. The leverage to ask for things (a SOC 2 report, a security addendum, better exit terms) is highest before money changes hands.
2. **At onboarding.** Even after signing, you confirm what was promised is actually configured: access scoped correctly, data residency set, integrations limited to what you agreed.
3. **On a recurring cycle.** High-risk vendors get re-reviewed annually or when something changes (an acquisition, a breach disclosure, a new sub-processor). Risk is not static.
4. **At renewal.** Renewal is your next-best leverage point after signing. Use it to revisit terms, pricing, and anything the relationship taught you.

## A step-by-step vendor due diligence process

Here is the process I actually run, stripped to what earns its place.

### 1. Triage the vendor by risk tier

Not every vendor deserves the same scrutiny. Before you collect a single document, classify the vendor: does it touch customer data, does it touch money, is it critical to operations, and how hard is it to replace? A simple tiering keeps you from spending two weeks on a $20-a-month tool and ten minutes on the vendor holding your customer records.

| Risk tier | Typical examples | What it touches | Review depth |
|---|---|---|---|
| Critical | Payment processors, core infrastructure, data sub-processors | Customer data, money, uptime | Full review, annual re-check |
| Elevated | CRM, analytics with PII, key SaaS | Some sensitive data | Standard review, periodic re-check |
| Standard | Internal tools, no customer data | Limited internal data | Light review, light monitoring |
| Low | Single-user utilities, no integrations | Nothing sensitive | Self-serve sign-off |

### 2. Send a scoped request, not a wall of questions

Ask for what the tier justifies. For a critical vendor that means security documentation (a SOC 2 Type II report or ISO 27001 certificate), a data processing agreement, financial signals, references, and contract drafts. For a standard vendor it might just be a security questionnaire and a privacy policy link. Over-asking burns goodwill and slows you down; under-asking leaves you exposed.

### 3. Verify the security and data posture

Read the compliance report rather than noting it exists. Check the date (an expired SOC 2 tells you nothing about today), the scope (does it cover the product or just the corporate office), and the exceptions section, where the real story lives. Confirm where data is stored, who the sub-processors are, how access is controlled, and the breach notification commitment. If a vendor cannot say where your data physically lives, that is your answer.

### 4. Check financial and business viability

You are not auditing their books, you are gauging survival odds through your contract term. For a private vendor, signals matter: funding history, customer count, leadership stability, public layoffs or hiring, and whether the product line you depend on is core to their business or a side bet. For deeper deals this overlaps with proper [financial due diligence](/blog/financial-due-diligence), but for vendor risk you mostly want to know: will they be here, and stable, in 18 months.

### 5. Review legal, contract, and compliance terms

Read the contract for the clauses that bite later: liability caps, data ownership, termination rights, auto-renewal traps, price-increase ceilings, and what happens to your data when you leave. Make sure any regulatory obligations you carry (GDPR, HIPAA, PCI, depending on your business) flow down to the vendor in writing. The cheapest time to fix a bad clause is before signing.

### 6. Score, decide, and document

Pull the findings into a single view, decide (approve, approve with conditions, or reject), and record why. The documentation is not bureaucracy; it is what you reach for when a vendor relationship goes sideways, when an auditor asks, or when the person who ran the original review has left. Keep the evidence and the decision in one place.

### 7. Monitor and re-review

The review does not end at signature. Set a re-review date by tier, subscribe to the vendor's status and security pages, and watch for the events that change the risk picture: a breach, an acquisition, a funding round that did not happen.

## The vendor due diligence checklist

Here is the checklist I work from, grouped by area. Adapt the depth to the vendor's tier.

**Security and data**
- [ ] Current SOC 2 Type II report or ISO 27001 certificate (check the date and scope)
- [ ] Data processing agreement (DPA) in place and signed
- [ ] Data residency and storage locations confirmed
- [ ] Sub-processor list reviewed
- [ ] Access controls, encryption at rest and in transit, and MFA confirmed
- [ ] Breach notification timeline committed in writing
- [ ] Penetration test summary or security questionnaire completed

**Financial and business viability**
- [ ] Funding, ownership, and time in business reviewed
- [ ] Customer base and references checked
- [ ] No red flags on stability (layoffs, leadership churn, product sunsetting)
- [ ] The capability you depend on is core to their business

**Legal and compliance**
- [ ] Master agreement and SLA reviewed
- [ ] Liability, indemnification, and data-ownership terms acceptable
- [ ] Termination and exit terms, including data return or deletion, are clear
- [ ] Auto-renewal and price-increase terms understood
- [ ] Relevant regulatory obligations (GDPR, HIPAA, PCI) flow down in writing

**Operational dependency**
- [ ] Criticality and replaceability assessed
- [ ] Integration and access scope limited to what is needed
- [ ] Exit plan and data portability path exist
- [ ] Re-review date scheduled by risk tier

## Common red flags

Some signals should slow you down or stop you. None is automatically disqualifying, but each deserves a real answer before you sign.

| Red flag | Why it matters |
|---|---|
| No current security report, and reluctance to discuss it | Either immature security or something to hide |
| Vague answers about where data is stored | They may not know, which is itself the risk |
| Pushback on a basic DPA | Compliance gaps that become your gaps |
| Long, sub-processor chains with no visibility | Your data may travel further than you think |
| Aggressive auto-renewal and steep undisclosed price hikes | Lock-in by design |
| Single point of failure with no documented redundancy | One incident becomes your incident |
| Evasiveness, slow responses, or shifting answers | The relationship rarely gets more transparent after signing |

The pattern under most of these is not the gap itself, it is how the vendor responds when you ask. A vendor that says "good question, here is the report and here is the exception we are remediating" is telling you something very different from one that goes quiet.

## How a data room streamlines vendor due diligence

Most of the friction in vendor diligence is document logistics. The SOC 2 report, DPA, financials, and references arrive over email, in chat, as PDF attachments, in a shared folder someone forgets to revoke. Three reviews later, nobody can find the report that was current at signing, and an auditor wants to know who looked at it.

A secure data room fixes the logistics so you can focus on the judgment. When I run vendor reviews, I keep the evidence in [Plox](/data-rooms), the data room we use, for a few practical reasons:

- **One organized place** for every artifact a vendor sends, structured so the next reviewer (or the auditor) can navigate it without a tour.
- **Permissioned access** so the right people see the right documents and access is revoked cleanly when the review is done. (If you are setting that up, [data room permissions](/blog/data-room-permissions) covers the structure.)
- **An audit trail** that records who viewed what and when, which is exactly the documentation step your future self will need.
- **A reusable structure** you can clone for the next vendor, so each review starts from a template instead of a blank folder.

This is the same machinery that powers deal-side reviews. The [due diligence data room checklist](/blog/due-diligence-data-room-checklist) lays out how to organize one for an M&A process, and most of those habits transfer to vendor risk; the difference is scope, since a vendor review is narrower and recurring where a deal room is broad and one-time.

You do not strictly need a dedicated room for one low-risk vendor; a shared folder will do. But once you are managing a portfolio of vendors, re-reviewing annually, and answering to compliance, one organized, permissioned, auditable home for the evidence pays for itself the first time something goes wrong.

## Frequently asked questions

### What is the difference between vendor due diligence and a security questionnaire?

A security questionnaire is one input into vendor due diligence, not the whole thing. The questionnaire captures the vendor's self-reported security posture. Due diligence is the wider exercise of verifying those answers against evidence (the actual SOC 2 report, the DPA, references) and adding the financial, legal, and operational dimensions the questionnaire usually skips.

### How long should vendor due diligence take?

It scales with risk tier. A low-risk tool can be a same-day self-serve sign-off. A critical vendor with access to customer data can take a couple of weeks, mostly waiting on documents and contract redlines. The biggest time sink is usually chasing paperwork, which is exactly the part a good intake process and a shared data room compress.

### Do small companies really need a vendor due diligence process?

Yes, though a proportionate one. You do not need an enterprise GRC platform to start. You need a simple risk tiering, a short checklist, and one place to keep the evidence. The cost of skipping it shows up later as a breach you inherited, a vendor that vanished, or an auditor's question you cannot answer. Even a lightweight version of the process catches most of that.

### How often should I re-review existing vendors?

Set the cadence by tier. Critical vendors deserve at least an annual re-review plus an event-driven one whenever something material changes (a breach, an acquisition, a new sub-processor, a missed renewal). Lower-tier vendors can be reviewed less often or simply monitored through their status pages. The mistake is treating the initial approval as permanent.

### What documents should I always collect from a vendor?

At minimum, for any vendor touching sensitive data: a current security report (SOC 2 Type II or ISO 27001), a signed data processing agreement, the master agreement and SLA, and a sub-processor list. For elevated and critical vendors, add financial or stability signals and references. Keeping these in one permissioned place, rather than scattered across inboxes, is what makes re-reviews and audits manageable.

### Is vendor due diligence the same as the vendor due diligence report in M&A?

No, and the shared name causes real confusion. In some M&A processes, a seller commissions a "vendor due diligence" (VDD) report on itself to present to buyers. That is a sell-side deal artifact. The vendor due diligence in this guide is third-party risk management: assessing a supplier you are buying from. If you are running a deal, start with the [due diligence](/blog/due-diligence-guide) pillar and the [virtual data room due diligence](/blog/virtual-data-room-due-diligence) workflow instead.