Your vendor's vendors are your risk

Every third-party risk programme in existence is built around a list of companies you have a contract with. The list is complete, it is maintained, and someone owns it. It is also the wrong boundary, because the data crosses it.

When you sign with a support tool, you are also processing through its hosting provider, its email sender, its session-replay vendor, its translation service, and the fraud-scoring API one of those uses. You did not choose any of them, you have no contract with them, and in most programmes nobody has ever written their names down.

The category has a name

Fourth-party and Nth-party risk: the exposure that arrives through the companies your vendors depend on, recursively. The term is not new. What is missing is anyone maintaining the graph, which is why the term shows up in frameworks and almost never in a tool.

The reason is arithmetic. Reading one subprocessor page per vendor is already most of a GRC analyst's week. Reading the subprocessor page of every subprocessor is not a bigger version of that job — at forty vendors it is several hundred pages, in a dozen formats and half a dozen languages, changing without notice.

Why the recursion is the product

Existing monitoring tools diff a single page at depth 1. Point one at your vendor's subprocessor page and it will tell you when the page changes. That is a real service and it stops exactly where the interesting part starts, because the change you would have objected to usually happens two companies further down.

Traversing the chain properly means a few things that are easy to get wrong. Cycles occur in practice — vendor A discloses B, B discloses A — so the walk has to run over a visited set. Hyperscalers appear under most branches of most graphs, so entities have to be deduplicated and depth stored as the shortest path from your root rather than per path. And the walk has to distinguish a company that publishes nothing from a company we have not reached yet.

A vendor that publishes nothing is a fact. A vendor we have not reached is a gap. Reporting them as the same thing understates your risk.

How we count coverage

What we do with it

We hold the graph beneath a company, refetch the pages daily, classify what moved, and match the result against rules you wrote. Cosmetic churn — copyright years, whitespace, navigation edits — is suppressed before classification, because a tool that cries wolf in week one never gets listened to in week six.

Because the graph is held rather than walked on demand, it also answers backwards. When a provider is in the news, the question is which of your vendors ultimately depend on it, and through which path. That is one indexed read against a closure you already have.

You can see the shape of it without an account. The public company pages show a depth-limited, lagged preview of the same dataset.