Vendor Risk

A logging vendor most people had never heard of got popped a couple of years back, and suddenly a few hundred companies were drafting breach notifications for data they'd handed over and forgotten about. None of them got hacked directly. They just trusted someone who did. That's the whole problem in one sentence: when your vendor leaks, regulators and customers don't care that it wasn't your server. It was your data, and it's your name in the incident report.

Vendor risk management is how you keep that from being a surprise. The trouble is most of the material out there assumes you have a GRC team, a tooling budget, and a quarter to spend. You probably have a Tuesday afternoon and a sales team that wants a contract signed by Friday. Here's how I'd run it anyway.

What TPRM is, minus the acronym soup

Third-party risk management — TPRM, vendor risk, supplier risk, pick your label — is the practice of knowing who you've trusted with your data and systems, deciding how much that trust is worth, and checking that they've earned it before and after you sign. That's it. Everything else is detail.

The reason it matters more every year is concentration. A modern company runs on fifty to two hundred SaaS tools, and a handful of them hold the keys to everything: your identity provider, your code host, your data warehouse, your payment processor. A breach at any one of those is functionally a breach at your company. Your SOC 2 auditor knows this, which is why "how do you vet your vendors?" is now a standard line of questioning — and a blank answer there is a finding.

Start with an inventory, because you can't manage what you can't see

Before any assessment, you need a list. Not a perfect one — just an honest one. Most teams are shocked at how long it gets once they actually look, because vendors arrive through the side door: a designer expenses a tool, an engineer signs up for a free tier that quietly starts holding production data, marketing connects something to your CRM.

Pull from the places money and access leak out:

• Your finance system. Every recurring charge is a candidate vendor.
• Your SSO/identity provider. Anything wired into Okta or Google Workspace is touching your accounts.
• Your OAuth grants. Check what third parties have been authorized against Google Workspace and Microsoft 365. This is where the forgotten ones hide.
• Your expense reports and corporate cards. The shadow IT graveyard.

For each one, capture the basics: vendor name, the owner internally, what data they touch, and whether they're business-critical. That last column is what drives everything next.

Tier vendors so you don't review them all the same way

Here's the mistake that makes vendor risk feel impossible: treating your e-signature tool and your office snack delivery with the same questionnaire. Don't. Tier them, then match effort to tier.

I sort vendors into four buckets along two axes — how sensitive is the data they touch and how badly does an outage hurt us:

• Critical — holds your most sensitive data (customer PII, source code, financials) or, if it goes down, you go down. Identity providers, cloud infrastructure, your primary database host.
• High — meaningful customer or employee data, or important to operations but survivable for a day. Support desks, analytics with PII, email platforms.
• Medium — limited or internal-only data, easy to replace. Project management, internal docs.
• Low — no access to your data or systems. The snacks.

A critical vendor earns a real review. A low one earns a name in the register and thirty seconds of thought. I put the full tiering rubric and per-tier checks in the vendor risk assessment checklist, because it's the part teams get wrong most often.

The lightweight assessment process

For everything above "low," the goal is a proportionate review you can actually finish. My default flow:

1. Ask the data-access question first. What exactly are we sending them, and does it include PII, PHI, payment data, or secrets? The answer sets the bar for everything else.
2. Request their evidence before you write a single question. A vendor with a current SOC 2 Type 2 has already answered most of what you'd ask. More on this below.
3. Send a questionnaire only for the gaps. Don't fire off a 300-question SIG by reflex. If the SOC 2 covers it, the questionnaire is redundant noise. I broke down which standardized questionnaire to use when in the security questionnaires guide.
4. Make a decision and record the reasoning. Approve, approve with conditions, or reject. Write down why. Future-you, and your auditor, will thank you.

The trap is perfectionism. A "good enough, documented, revisit in a year" decision beats a flawless review that arrives three weeks after the deal closed anyway.

What evidence to actually ask for

You don't need to invent your own audit. Let other people's auditors do the work. The artifacts that tell you the most, in rough order of value:

• A SOC 2 Type 2 report. The single most useful document. An independent CPA watched their controls operate over months and wrote it down. Read the auditor's opinion, check the report period is recent (within the last year), and skim the exceptions section — that's where the real story lives. If you're fuzzy on what the report proves, start with the SOC 2 guide.
• An ISO 27001 certificate. The international equivalent. Confirms a certified body audited their security management system.
• A penetration test summary. Not the full report — vendors rarely share that — but an executive summary or attestation letter showing they test and remediate.
• A trust center or security page. Increasingly vendors publish their certs, sub-processors, and policies in one place. For a low or medium vendor, that's often enough.

When a vendor has none of these and holds sensitive data, that is your answer. The absence of evidence for a critical vendor is a risk decision, not a paperwork gap.

The contracts: DPA and BAA

Diligence tells you whether to trust a vendor. Contracts make that trust enforceable. Two documents matter most, and people mix them up constantly.

A DPA (Data Processing Agreement) is the privacy-law contract. If the vendor processes personal data of people covered by GDPR or similar laws, you need one — it pins down who's the controller, who's the processor, and how international transfers are handled. A BAA (Business Associate Agreement) is the health-data contract, required under HIPAA whenever a vendor touches protected health information. They are not interchangeable, and needing one doesn't excuse you from the other. I untangle the two in DPA vs BAA.

If a vendor handles regulated data and won't sign the corresponding agreement, that's not a negotiation. That's a no.

Monitoring, because security isn't a one-time photo

A clean review today says nothing about next year. SOC 2 reports expire. Companies get acquired, lay off their security team, or quietly change what they do with your data. So bake in a cadence:

• Reassess on a schedule by tier. Critical and high vendors annually, at minimum — pull the new SOC 2 each cycle. Medium every couple of years or on a trigger. Low when something changes.
• React to triggers, not just the calendar. A breach, an acquisition, a new product that suddenly wants more of your data, or a vendor's SOC 2 lapsing should all kick off a fresh look.
• Watch the news. You don't need a paid feed. A saved search for your critical vendors' names catches most of what matters.

The vendor risk register

All of this lives in one place, and for most teams a spreadsheet is genuinely fine. Don't let anyone shame you into buying a platform before you've outgrown a sheet. Columns I'd keep:

That register is your TPRM program in its early life. When an auditor or a prospect asks how you manage third-party risk, you open the sheet. The day it gets unwieldy is the day to look at tooling — and not a moment sooner.

Run it this way and vendor risk stops being the thing that ambushes you mid-deal. It turns into a short, repeatable habit you can hand to the next person you hire, which is exactly what a program is supposed to be.

Get the templates we actually use.

One practical email a week: a new template, a teardown of a real framework requirement, and the occasional honest tool review. No fluff, unsubscribe anytime.

Send me the templates

No spam. Unsubscribe in one click.