Vendor due diligence: a practical guide for small and mid-sized businesses

Every business runs on other businesses. Your payroll, your email, your hosting, the contractor who has admin on your CRM — each is a decision to trust someone else with something you are accountable for. Vendor due diligence is how you make that decision deliberately, write it down, and keep it current.

This guide is for the person who owns that job at a small or mid-sized company, usually alongside three other jobs. It explains what due diligence has to achieve, a process that fits a team of one, and what to keep so the file holds up when an auditor, a customer or a regulator asks to see it.

What vendor due diligence is, and what it is for

Due diligence answers four questions about a third party before you rely on it, and again at intervals while you do:

1. Who are they? Legal identity, ownership, financial stability, sanctions and adverse-media screening. A vendor that may not exist next year, or that you cannot lawfully pay, is a risk before any security question is asked.
2. What will they touch? Which data, which systems, with what level of access, and how important the service is to your operations. This determines how deep the rest of the review needs to go.
3. How do they protect it? Security, privacy and continuity controls, evidenced rather than asserted: a SOC 2 report, an ISO 27001 certificate, a penetration test summary, a completed questionnaire with supporting documents.
4. What happens when something goes wrong? Contractual commitments on breach notification, sub-processors, data return and deletion, liability and exit.

The output is not a score. It is a decision — accept, accept with conditions, or reject — made by a named person on a date, with the evidence that supported it attached. That is the artefact every framework is really asking for.

When it is required

Do a full review at three moments: before a new vendor is given data or access, when an existing vendor’s scope changes materially (a new integration, a new data category, a move to a new sub-processor), and on a schedule set by the vendor’s risk tier. Add an out-of-cycle review after any security incident at the vendor, a change of ownership, or a warning sign such as missed SLAs or a lapsed certificate.

The mistake small teams make is doing the first review thoroughly and never the others. The auditor asks about the population of vendors in the audit period, not the ones you onboarded that year, so a vendor reviewed in 2023 and untouched since is a finding waiting to happen. See Vendor risk tiering: how to classify third parties and set a review cadence for a cadence that survives contact with a small calendar.

A process that fits a team of one

Enterprise third-party risk programmes assume a department. What follows is the same substance, sized for a company where one person owns it. Each step produces one record; the records are the programme.

1. Inventory every vendor

You cannot assess what you have not listed. Pull vendors from accounts payable, the expense tool, SSO application lists, and a conversation with each team lead; the shadow ones — the free tier somebody signed up for with a work email — usually surface in the last of those. For each, capture the owner inside your company, the service, the data categories shared, the type of access, and the contract dates. This is the register the auditor will ask for first.

2. Tier by risk

Not every vendor deserves a forty-question assessment. Classify each one as critical, high, medium or low using three questions: what data and access do they have, how much would an outage hurt, and how hard would they be to replace. The tier sets the depth of the assessment and the frequency of the review, so effort goes where the exposure is.

3. Assess, in proportion to the tier

For critical and high-tier vendors, send a questionnaire mapped to the frameworks you answer to, and ask for evidence alongside the answers: the SOC 2 Type II report, the ISO certificate and statement of applicability, a recent penetration test summary, the data processing agreement, the business continuity test result. For medium-tier vendors, a short questionnaire and their public security page usually suffice. For low-tier ones, confirm the contract terms and move on. What to ask, and how to score it, is its own guide.

4. Review the evidence, not just the answers

A questionnaire is a set of claims. Evidence is what makes them checkable. When you receive a SOC 2 report, read the auditor’s opinion, the period covered, the exceptions noted, and the complementary user entity controls — the things the report assumes you do. When you receive a certificate, check the scope actually covers the service you buy, and the expiry date. Write down what you looked at and what you concluded; a one-line note per document is enough.

5. Score, decide, and record the decision

Turn the assessment into a risk rating using a method you could explain to an auditor in a sentence. Then decide: accept, accept with conditions (a remediation date, a contractual clause, a compensating control on your side), or reject. The record needs a named approver, a date, the rating, the conditions, and links to the evidence.

6. Contract for the gaps

Whatever the assessment could not confirm, the contract should require. At minimum: security obligations proportionate to the data, breach notification within a fixed number of hours, prior notice of sub-processor changes, audit or assessment rights, data return and deletion at termination, and — where personal data is involved — a data processing agreement meeting the requirements of GDPR Article 28.

7. Monitor, and reassess on schedule

Between reviews, watch for the things that should move a review forward: certificate expiries, breach notifications, ownership changes, SLA misses, adverse news. Then reassess on the cadence the tier sets. A reassessment can reuse most of the previous file; what matters is the new date, the new evidence, and a fresh decision.

The vendor due diligence checklist

A compact version of the above, for pinning next to the desk. If every box has a record behind it, the file is audit-ready.

• Vendor is in the inventory with an internal owner, service description, data categories and access type.
• Risk tier is assigned and the reason recorded.
• Identity, sanctions and adverse-media screening completed for new vendors.
• Questionnaire sent, returned and scored in proportion to the tier.
• Evidence collected: SOC 2 / ISO 27001 / pen test / DPA / BCP as applicable, each reviewed with a dated note.
• Complementary user entity controls from the vendor's SOC report assigned to someone on your side.
• Risk rating and decision recorded with approver, date and conditions.
• Contract contains security, breach-notification, sub-processor, audit and exit clauses.
• Next review date set from the tier; triggers for out-of-cycle review understood by the owner.

What to keep, and for how long

Auditors accept a range of evidence formats. What they will not accept is evidence assembled after the fact, so the principle is to create the record at the moment of the decision and never edit it afterwards — append a new review instead.

A retention period of the contract term plus six years covers most contractual limitation periods; check your own jurisdiction and your customers’ contractual requirements.

Five mistakes that turn into audit findings

• Reviewing once and never again. A stale review reads as no review. Set the next date when you close the current one.
• Filing the SOC 2 report without reading it. The exceptions and the user-entity controls are the point. Note that you read them.
• Treating every vendor the same. Either the critical ones get too little or the trivial ones get too much and the programme stalls. Tier first.
• Keeping the record in email. Threads get deleted, people leave. The decision, the evidence and the date need to live in one place with an owner.
• Missing the shadow vendors. The free tool a team adopted without procurement is still your processor. Reconcile against SSO and expenses quarterly.

Where to go next

If you are building the programme from nothing, Third-party risk management for small businesses: a programme without a GRC team describes the whole structure. If the inventory is done and the next step is asking questions, Vendor risk assessment questionnaire: what to ask, and how to score the answers covers what to ask and how to score it. If a specific audit is coming, the SOC 2, ISO 27001 and GDPR guides map the process above to what each one checks.