Concentration at Fourth-Party Depth

Vendor concentration is measured one hop out. Count the suppliers, check nobody holds too much of a critical process, confirm the portfolio looks diversified. The exercise is worth doing and it answers a narrower question than it appears to.

‍

The dependency that correlates losses across a portfolio frequently sits two hops out, in a provider none of your direct vendors name. Four independent suppliers running on the same infrastructure, through the same identity platform or via the same payment processor are one dependency wearing four contracts.

‍

Why Can't You Map It?

‍

Three structural reasons, and none is a matter of effort. A program premised on producing an accurate fourth-party map will not succeed at it.

‍

You have no contractual relationship with a fourth party, so you cannot compel an audit report, a questionnaire response or breach notification. Your direct vendor frequently does not have complete visibility into its own supply chain, and where it does it may decline to share a subprocessor list that reveals how the service is built. The dependency also changes without notice, since a vendor migrating between regions or switching a downstream provider has no obligation to tell you.

‍

Which Makes the Map Perishable Even When Accurate

‍

A dependency chart assembled through diligence describes the arrangement on the day it was compiled. Six months later some portion of it is wrong and nothing signalled the change, so the expensive part of the exercise decays faster than the cycle that produced it.

‍

Do You Need the Map to Price the Risk?

‍

No, and this is the reframe that makes the problem tractable. What the model needs is whether a shared dependency exists, not who it is.

‍

Correlation in the aggregate is driven by the fact of a shared dependency rather than by its identity. Whether four vendors fail together because they share a cloud region or an authentication provider changes the remediation and not the arithmetic. So a model can carry the correlation while the map remains incomplete, and aggregating with dependency applied is the mechanism.

‍

Which Changes What You Have to Establish

‍

From naming the fourth party to detecting that overlap is likely, which is a considerably lower bar and reachable from sources that do not require anyone's cooperation.

‍

What Can You Establish Without Asking?

‍

Three signals, in descending order of reliability, and the first is the one almost nobody uses.

‍

• Published subprocessor lists: Many vendors publish them to satisfy data protection obligations, which is a disclosure made for somebody else's benefit that you can read without privity.
• Infrastructure observation: Where a vendor's service resolves indicates the hosting provider and frequently the region, from public naming and certificate data.
• Correlated failure history: Vendors that have degraded together in the past share something, whether or not anyone can say what.

‍

The first deserves particular attention because the list exists, is maintained, and is published under an obligation independent of your relationship. Reading the subprocessor pages of your twenty most critical vendors is an afternoon and it routinely reveals the same three or four names repeatedly.

‍

What Do You Do When It Cannot Be Established?

‍

Bound the effect rather than estimate the dependency, which is the same move that applies whenever a parameter is unobservable.

‍

Run the portfolio aggregate twice. Once assuming your critical vendors fail independently, once assuming they share a common dependency and fail together. The distance between the two extreme figures is the range within which the truth sits, and its width answers the question that matters, which is whether the unmapped dependency changes any decision.

‍

What If the Range Is Narrow?

‍

Then the mapping exercise is not worth funding, which is a legitimate and underused conclusion. An organization whose extreme figure barely moves between the independent and fully dependent cases has established that fourth-party concentration is not its binding constraint, and it can document that and move on.

‍

Is Accepting the Unknown Ever the Right Answer?

‍

Frequently, and stating so is more useful than recommending a program most organizations will not sustain.

‍

Fourth-party mapping is expensive, requires cooperation nobody is obliged to give, and decays between cycles. Where the bounding exercise shows the exposure is material, the investment is justified. Where it does not, a documented acceptance stating that dependencies past the first tier are not fully known, with the reasoning attached, is a defensible position and a considerably better one than a stale map presented as current.

‍

What Makes the Acceptance Defensible?

‍

Naming what was attempted. A record showing that subprocessor lists were reviewed, that vendors were asked, that the aggregate was bounded and that the resulting range did not change a decision demonstrates the question was examined. An acceptance with no attempt behind it is indistinguishable from not having thought about it, which an appetite statement that can be breached is where that record belongs.

‍

Which Dependencies Are Worth the Effort?

‍

A short list, because depth is only worth pursuing where breadth already exists.

‍

A fourth party underneath one vendor is that vendor's problem to manage and yours to price through them, which diligence on an acquisition handles the same way. A fourth party underneath several of your critical vendors is the one that concentrates. So the question to ask is not how deep the chain runs but how many of your important suppliers converge, and that is answerable from the subprocessor lists without tracing any single chain to its end.

‍

How Many Layers Should You Go?

‍

Two, in most cases, and stopping there deliberately. Each additional hop costs more to establish and contributes less, since the population of shared providers narrows quickly toward a handful of infrastructure companies everyone depends on. Knowing you are exposed to a small number of dominant providers is the finding, and enumerating the path to each one adds little, which concentration you cannot diversify away describes.

‍

Does Regulation Help Here?

‍

In two places, and both produce disclosure you could not obtain by asking, which makes them worth knowing about even outside the jurisdictions they apply to.

‍

Financial services resilience rules in Europe require in-scope firms to maintain a register of information covering contractual arrangements with technology providers, including subcontracting chains supporting critical functions. Data protection law separately obliges processors to disclose subprocessors and to notify changes. Neither was designed to solve concentration analysis and both generate exactly the records it needs.

‍

How Do You Use That Without Being In Scope?

‍

Read the disclosures other people compelled. A vendor serving regulated financial customers maintains subcontracting records because those customers require it, and a vendor processing personal data publishes subprocessors because the law requires it. Neither obligation runs to you and both produce documents you can read, which the operational resilience regimes have made considerably more common.

‍

Which Vendors Are Most Likely to Have Told Somebody?

‍

The ones serving regulated sectors, which is a useful heuristic for where to look first. A vendor with financial services or healthcare customers has almost certainly documented its subcontracting chain for one of them, so asking whether that documentation exists is a lighter request than asking them to produce it from scratch.

‍

What Should Change in the Contract?

‍

Two clauses, and both are more achievable at renewal than the visibility they replace.

‍

Notification of material subprocessor change, which converts a silent dependency change into an event somebody can assess. Then a requirement that the vendor maintain a published subprocessor list, which many already do for other reasons and which costs them nothing to commit to. Neither gives you privity and both convert an unobservable into something that arrives on its own, and third-party assessment is where those clauses get tracked.

‍

Detect the Overlap, Not the Provider

‍

Fourth-party dependencies cannot be mapped reliably, because there is no contractual route to compel disclosure, vendors frequently do not know or will not say, and the arrangement changes without notice. A program built on producing an accurate map will produce a perishable one. What the aggregate needs is the existence of a shared dependency rather than its identity, and that is reachable from published subprocessor lists, infrastructure observation and correlated failure history. Where it still cannot be established, running the aggregate at both extremes says whether the question matters, and documenting an acceptance with the attempt attached beats a stale map. Kovrr's cyber risk quantification applies correlation across a portfolio, which is what makes the bounding exercise possible.

‍

To see portfolio exposure with the dependency assumption applied and stated, book a demo with our risk experts.