The Supplier You Never Signed a Contract With

Picture the morning. Your payments reconciliation tool is down. So is the onboarding platform your operations team uses. Half an hour later someone in customer service mentions the chat widget has stopped loading.

Three suppliers. Three separate contracts, signed in three different years, by three different people. Nothing in your vendor register links them. Two of them were tier one, assessed last quarter, both scored well.

They were all hosted on the same infrastructure provider. You have never heard of it, because you have never bought anything from it.

This is the part of third-party risk that most programmes are structurally unable to see, and it is not because the teams running them are careless.

Due diligence asks the wrong direction

A vendor assessment is a questionnaire pointed at the vendor. It asks what controls they operate, how they handle your data, whether they have been breached, what certifications they hold. All reasonable questions, all pointed at the entity you are paying.

Almost none of it asks the question that produces the morning described above: who does this vendor depend on?

When it is asked, it is usually one line: "do you use subcontractors or sub-processors? If yes, please list." The answer comes back as a paragraph of free text, gets attached to a PDF, and is never read again. Nobody builds a structure out of it, so nobody can query it later.

Which means the concentration is real, it is documented somewhere in your own files, and it is still invisible.

Why spend is a bad proxy for criticality

The most common tiering method is money. Big contract, tier one. Small contract, tier three. It has the great advantage of being available in a system you already have.

It is also wrong in a specific and predictable way: the supplier that can hurt you most is often cheap.

An authentication provider might cost less per year than the catering contract. A certificate authority, a DNS provider, a single small firm holding a licence key that a production system checks on startup. None of these show up as significant spend. All of them can stop your operation.

The inverse is also true. Your largest supplier by value might be a body shop providing contract staff, where losing them is a hiring problem measured in weeks, not an outage measured in minutes.

Tier by what breaks. Then check the spend, because it tells you something about leverage in a negotiation, but do not let it decide your tiers.

The averaging problem

Here is a failure mode that appears in nearly every scoring model built in a spreadsheet.

You have ten factors. A vendor scores well on nine of them and catastrophically on the tenth: no incident response process at all, or no ability to tell you whether your data has ever been accessed. The weighted total comes out acceptable. The vendor is onboarded. The one answer that should have stopped everything has been diluted by nine answers about things that matter less.

Some answers are not inputs to a score. They are gates.

A knockout rule is the mechanism for this: certain responses stop the engagement regardless of the total. No incident response capability is a knockout for anyone touching production. No ability to support your regulatory notification window is a knockout for anyone touching personal data. The list should be short, and it should be argued over properly once rather than relitigated per vendor.

If your scoring model has no knockouts, it will eventually onboard something it should have refused, and the total will look fine on the day it does.

Fourth parties: what to actually record

You will not build a complete dependency map. Anyone who tells you they have one is describing a snapshot that was accurate for about a week.

Aim narrower and you can actually get somewhere:

Critical tier only. For vendors whose failure stops an operation, ask for their material dependencies by name. Not a category, not "a leading cloud provider". The name.

Record it as a link, not as text. A fourth party has to be a record that several vendors can point at. This is the whole trick. When your fourth party is a field in a PDF, nothing can be counted. When it is a record, the question "how many of our critical vendors depend on this one company?" becomes a query that takes a second.

Ask at renewal, not once. Dependencies change quietly. A vendor migrates platforms and does not think to tell you, because from their side it is an internal decision.

Accept partial answers. Some vendors will refuse, some will give you two names out of five. Partial visibility on your ten most critical suppliers beats total visibility on none of them.

The obligations you agreed to and then forgot

There is a second gap, and it is quieter than concentration risk because it never causes an outage. It just fails you during an audit.

A contract gets negotiated. Security clauses go in: a notification window, audit rights, a right to receive assessment reports, a requirement to encrypt data at rest. Then the contract is signed, filed, and functionally forgotten. Three years later nobody in the risk team can tell you what was promised, and the person who negotiated it has changed jobs.

Contract obligations need to exist as individual tracked items, each with a category, a status, and a review decision, sitting against the vendor record rather than inside a document nobody opens. Otherwise you have commitments you cannot enforce, because you cannot remember them.

The same applies to evidence with a shelf life. A certification report is valid until a date, and after that date it is a historical document, not assurance. If your system does not know that date, an expired report will sit in a file looking exactly as reassuring as a current one.

What this looks like in Sentinel Unity

To be specific about the mechanics rather than gesture at them:

Tier factors are scored against a profile, so tier placement is reproducible. Two people assessing the same vendor land in the same tier, and when someone challenges a placement you can show the working.
Knockout rules are declared separately from the weighted score. A disqualifying answer stops the engagement instead of being averaged away.
Fourth parties are their own records, linked to the vendors that depend on them. Concentration becomes something you can count.
Contract obligations are individual items with categories, statuses, review decisions, and a status history.
Due diligence requests carry a document type and a validity status, so an expired report stops counting as evidence on its expiry date rather than when somebody happens to notice.
Review schedules follow rules tied to tier, not reminders in a personal calendar.

None of this is exotic. It is mostly the difference between recording something as a linked record and recording it as text in a document.

The honest limits

Three things worth saying plainly.

You cannot assess your way out of concentration. If four critical suppliers depend on one platform, knowing that does not fix it. What it does is turn a surprise into a decision: accept it with your eyes open, build a fallback for the one service that genuinely cannot stop, or renegotiate. All three are legitimate. Not knowing is not.

Vendors will resist. Asking a supplier to name their own suppliers feels, to them, like asking for a competitive secret. You will get further by explaining the specific scenario you are trying to avoid than by sending a longer questionnaire.

This work is never finished. The map decays continuously. The goal is not a finished map, it is a maintained one for the small set of relationships where being wrong actually costs you something.

Where to start

If you want one thing to do this quarter, do this:

Take your ten most critical vendors. Not the ten largest by spend, the ten whose failure stops something. For each one, write down the answer to a single question: what does this vendor run on that we do not control?

You will not get ten clean answers. You will probably get six, and two of them will name the same company.

That overlap is the finding. It was there before you looked.

Sentinel Unity models third parties, fourth parties, tier factors, knockout rules, and contract obligations as connected records rather than documents. Request a demo to see how vendor concentration looks when it is queryable, or read more about third-party risk management.