Vendor risk management is the practice of knowing what you depend on well enough to act before it breaks something. Most programs only manage the vendors they already know about. The gap that causes real damage is usually what those vendors themselves depend on: the sub-vendors, subprocessors, and fourth parties sitting underneath them.
Why vendor risk management matters
A few reasons this matters more every year:
- Your vendor list is bigger than you think. Across 6,000+ companies and 90,000+ vendor relationships mapped so far, the median company in Resiliate's database depends on 23 direct vendors, some on more than 160, before counting what those vendors depend on. Most teams can name their direct vendors, but not the sub-vendors those vendors themselves depend on, and that's usually where the real risk sits.
- An invisible sub-vendor can be a concentrated risk to many of your vendors at once. 87% of companies depend on Google in some form, and around half on Microsoft or AWS: different vendors on your own list often turn out to share that exact same provider underneath them. What looks like a diverse set of vendors on paper can collapse into a single point of failure the moment that shared sub-vendor goes down.
- Manual tracking doesn't scale. Spreadsheets and annual questionnaires go stale the moment a vendor changes its stack, which is constant.
Software built for this replaces guesswork with a live, current picture, so risk gets managed before it becomes an incident.
What is an example of vendor risk?
In 2023, the ransomware group Cl0p exploited a flaw in MOVEit, a file-transfer tool made by Progress Software, and stole payroll data from British Airways, Boots, the BBC, and hundreds of other organisations.
None of them had a relationship with MOVEit or Progress Software. They were customers of Zellis, a UK payroll provider that used MOVEit internally. The flaw wasn't in Zellis, it was one layer beneath it, and it reached every company Zellis served at once.
This is what vendor risk looks like in most real breaches: the failure sits in what your vendor depends on, not the vendor itself.
And it's not an outlier. Verizon's 2026 Data Breach Investigations Report found third-party involvement had reached 48% of all breaches, up 60% year over year, the fastest-growing pattern it tracks.
How to manage vendor risk
Managing vendor risk means keeping a live picture of who you depend on and acting before something breaks. That comes down to four habits: find every vendor and sub-vendor, rank them by criticality, monitor for outages, and have a response plan ready.
How to do a vendor risk assessment
- List the vendor's dependencies, including its sub-vendors. Ask what it runs on, which cloud, subprocessors, identity or payment provider sits underneath it. That's usually where the real exposure is, not the name on the contract.
- Rank it by criticality. Tie it to the business process it supports, then ask what happens if it goes down for an hour, a day, or a week. A vendor behind checkout deserves more scrutiny than one behind an internal wiki, even if the wiki costs more.
- Do your due diligence. It's responsible practice to cross-reference what the vendor tells you, audits, certifications, questionnaire answers, against what's independently verifiable: its tech stack, subprocessors, and outage history. Resiliate verifies this automatically, so you're not relying on the vendor's own account alone.
- Score it. The classic calculation is the probability of an incident multiplied by the gravity of that incident. A vendor that rarely fails but would be catastrophic if it did, and one that fails often but barely matters, carry very different risk even if they land at the same likelihood, so score the two halves separately rather than picking one.
- Monitor and reassess on a schedule, not once a year. A vendor's risk profile isn't fixed at onboarding, so re-check scores on a cadence and watch for incidents in real time, before a customer tells you first. Resiliate does this monitoring for you: follow a vendor and get an alert the moment something changes in your network or an incident happens.
Can I do my own vendor risk assessment?
Yes. You can map your vendors' dependencies yourself, score them against what's verifiable, and put a review cycle in place. None of that requires special tooling.
What's hard to sustain is that every piece of it is moving at once, not just your vendor list. Vendors add subprocessors, switch cloud regions, get acquired, or go down, usually without telling you, and their own sub-vendors are doing the same thing underneath them. A spreadsheet is only ever accurate for the day you filled it in.
That's the part most teams underestimate, which is why many end up hiring a third-party risk management (TPRM) consultant to run the process for them rather than building it in-house.
Resiliate solves the same problem differently: it maintains a constantly updated map of your vendor relationships, with a focus on technology vendors, discovering sub-vendors from public sources, refreshing the map daily, and flagging disruptions in real time, so you're not relying on someone remembering to check. You still make the judgment calls, the data behind them just stays current.
Where to go from here
Start by mapping your vendors and their indirect dependencies with Resiliate. Enter your domain and it maps your direct and indirect vendors from public sources and proprietary data, then keeps that map current and watches it for disruptions, so the list you start with doesn't go stale.
It's already mapped 6,000+ companies and 90,000+ vendor relationships this way, and the network grows every day.