What Is Concentration Risk in TPRM?

What concentration risk is

Concentration risk is the exposure that builds up when too much of your operation depends on a single point - one vendor, one cloud provider, one region, or one sub-processor sitting behind several of your vendors. It is not a statement that any one of those is risky on its own. It is the observation that you have put too many eggs in one basket, so a single failure has an outsized, cascading effect.

The defining feature is correlation. Ordinary vendor risk asks how likely each vendor is to fail and how much it would hurt. Concentration risk asks a different question: when one thing goes wrong, how many of your dependencies go down with it? A portfolio of individually healthy vendors can still be fragile if they would all fail together.

The forms it takes

Concentration hides in more than one layer of the stack. The common ones:

• Single-vendor - one provider for a critical function with no ready alternative, so its outage is your outage.
• Single-cloud or single-host - many different vendors that all run on the same underlying cloud, so one provider's regional incident takes a swathe of your stack down at once.
• Single-region - vendors and data concentrated in one geography, which couples operational risk with data-residency and resilience risk.
• Single sub-processor (fourth-party) - several independent vendors that all quietly rely on the same downstream provider for payments, email, identity, or hosting.
• Single category dependency - one tool so embedded across teams that replacing it is effectively impossible on any useful timeline.

Why a per-vendor review misses it

Concentration risk is a property of the portfolio, not of any single vendor - which is exactly why a one-vendor-at-a-time assessment cannot see it. Each vendor can clear its own review with strong scores, and the portfolio can still be dangerously concentrated, because the risk lives in the relationships between vendors rather than inside any one of them.

A review process built around assessing vendors individually will therefore report a clean bill of health right up until the shared dependency fails. Seeing concentration requires stepping back from the per-vendor view and looking across the whole inventory at once.

The fourth-party angle

The hardest form to spot is concentration through a shared sub-processor. You can have ten vendors, each independently solid, each with its own clean assessment - and all ten routing through the same downstream provider for a critical function. On paper you are diversified; in reality a single fourth-party outage takes all ten down together.

This is the version of concentration risk that a vendor inventory alone will never surface, because the shared dependency is one level below the vendors you contracted with. Catching it means mapping not just who your vendors are, but who their vendors are - the sub-processor lists you gather during due diligence become the raw material for spotting overlap.

How to measure it

Measuring concentration is a grouping exercise: take the inventory, bucket it along each axis that could correlate failures, and look for buckets that hold too large a share of what matters.

• Count vendors per critical business function - any function served by a single vendor with no alternative is a concentration flag.
• Group vendors by underlying cloud or host, and by region, to surface infrastructure and geographic clustering.
• Group by shared sub-processor using the lists gathered at due diligence, so fourth-party overlap becomes visible.
• Weight by impact, not just count - five low-impact tools on one cloud matter far less than two critical ones.
• Set a threshold for what share of a critical category in one bucket is too much, and flag anything above it for a decision.

What to do about it

Concentration is not always something to eliminate - sometimes the consolidation is worth it, and the right move is to accept the risk with eyes open. The point of measuring it is to make that an explicit decision rather than an accident. The usual responses:

• Accept and document - record the concentration, who owns it, and the monitoring that will catch trouble early.
• Diversify - stand up a second source for the most critical concentrated functions so a single failure is survivable.
• Build for portability - favor contracts and architectures that let you exit or fail over, so a dependency is not also a trap.
• Plan the contingency - a runbook for the concentrated dependency failing, tested before you need it rather than written during the incident.

Common mistakes

Concentration risk tends to slip through in familiar ways:

• Assessing vendors only individually, so the portfolio-level exposure is never computed.
• Stopping at the vendor layer and ignoring the cloud, host, and region beneath it.
• Never mapping sub-processors, which leaves fourth-party concentration completely invisible.
• Treating concentration as a one-time finding instead of a metric that drifts as the vendor mix changes.
• Confusing diversification of contracts with diversification of dependencies - many vendors, one sub-processor, is still concentrated.

Where concentration shows up in your program

Because concentration is a portfolio view rather than a per-vendor field, it only becomes visible when something can aggregate across the whole inventory - count vendors per function, group them by cloud, region, and shared sub-processor, and weight the result by impact. Done by hand in a spreadsheet, that analysis is laborious enough that it rarely gets refreshed, and concentration creeps back as the vendor mix changes.

v3ndor surfaces concentration directly from the vendor inventory you already maintain - grouping by category, tier, and the relationships between vendors so over-reliance shows up as a view rather than a manual audit. Request access at /request-access to see where your own portfolio concentrates.