Your vendor risk program probably treats vendors as independent bets. Assess each one, tier each one, monitor each one. The math behind that mental model quietly assumes their failures are uncorrelated, and for modern SaaS vendors that assumption is false. A large share of them run on a handful of cloud platforms, in a handful of favored regions, authenticated through a handful of identity providers. When one of those shared layers has a bad day, a dozen of your "independent" vendors have the same bad day at the same hour.
This is concentration risk, and the uncomfortable part is that it hides from standard TPRM entirely. Every individual vendor can assess beautifully while the portfolio is one regional outage away from a company-wide incident. Regulators have noticed: operational resilience regimes on both sides of the Atlantic now expect firms to understand their critical third-party concentrations, and insurers increasingly ask the same questions, a thread we pulled in vendor risk and cyber insurance readiness.
What follows is a concentration index you can compute from data you mostly already have, and a mitigation menu priced honestly, because several popular mitigations cost more than the risk they retire.
Step 1: Collect the dependency layer
For each critical vendor (Tier 1, plus any vendor embedded in a revenue-critical process), record three dependencies: primary cloud platform, primary hosting region or regions, and identity provider used for your access to them. Sources, in order of ease: the vendor's public sub-processor or trust page, their SOC 2 subservice-organization section, their status page (which usually names regions during incidents), and a direct question at assessment. For most programs this is an afternoon per dozen vendors, illustratively, not a quarter-long project.
Step 2: Compute the concentration index
Borrow from finance. The Herfindahl-Hirschman Index (HHI) measures market concentration by summing squared shares, and it adapts cleanly to vendor dependencies. For a chosen layer (say, cloud platform):
- Weight each critical vendor by impact. A simple scheme: 3 for vendors whose failure halts a critical process same-day, 2 for painful within a week, 1 for absorbable. Reuse your tiering rationale; do not invent a new scale.
- For each provider in the layer, sum the weights of vendors depending on it, then divide by the total weight across all critical vendors. That is the provider's share, between 0 and 1.
- Square each share and sum the squares. The result is your Vendor Concentration Index (VCI) for that layer, between 0 (perfectly dispersed) and 1 (everything on one provider).
Worked example (illustrative). Twelve critical vendors, total weight 24. Cloud layer: provider A carries weight 14 (share 0.58), provider B weight 7 (share 0.29), provider C weight 3 (share 0.13). VCI = 0.58² + 0.29² + 0.13² = 0.34 + 0.08 + 0.02 = 0.44.
Interpretation bands, adapted from the antitrust convention and useful as conversation anchors rather than law:
| VCI | Reading | Typical posture |
|---|---|---|
| Below 0.15 | Dispersed | Monitor annually, no action |
| 0.15 to 0.25 | Moderate | Record it, test one failure scenario per year |
| 0.25 to 0.50 | Concentrated | Board visibility, resilience testing for the top provider, exit thinking for the worst-placed vendors |
| Above 0.50 | Critical dependency | Treat the shared provider as if it were your own Tier 1 vendor, because functionally it is |
Compute the VCI separately for each layer: cloud platform, region, and identity provider. The layers fail differently. A cloud control-plane incident is rare and global; a regional outage is more common and geographic; an identity provider incident locks your people out of everything at once, which is often the fastest-moving of the three. Many organizations discover their identity layer scores worst, because SSO consolidation was a deliberate (and correct) security decision whose concentration cost nobody ever wrote down.
Step 3: Find the compound points
The index summarizes; the pairs kill. Query your dependency data for vendors that share two or more layers: same cloud and same region, or same cloud and same identity provider. These compound clusters are your true blast radius, because a single event takes out the whole cluster and your workaround for vendor 1 probably assumed vendor 2 was still up. Write down, for the largest cluster: which business processes stop, what the first hour looks like, and who declares the incident. If nobody can answer, that is the finding. Keeping vendor records and their dependency attributes in one queryable system rather than a diagram makes this a filter, not a workshop; this is one of the reasons ThirdSentry models fourth-party dependencies as structured data on the vendor record.
Step 4: Mitigation options, with honest price tags
Not every concentration deserves spending. Match the response to the layer and the number:
- Accept and document (cost: near zero). Legitimate for moderate scores. The board formally acknowledges the concentration and its rationale. Cheap, honest, and vastly better than undocumented drift. Most organizations should do this for at least one layer.
- Demand resilience evidence from clustered vendors (cost: low). For vendors in a compound cluster, ask specifically for multi-region failover evidence and last tested date, not a generic BCP attestation. A vendor on the concentrated cloud with tested cross-region failover is a much smaller contributor to real blast radius than the index alone implies.
- Sequence new procurement (cost: low, slow payoff). Add dependency questions to vendor selection and, where two candidates tie, prefer the one that reduces your VCI. This bends the curve over years without a single migration.
- Break identity coupling for crown-jewel access (cost: moderate). Maintain a tested break-glass access path, outside the primary identity provider, for the two or three systems you would need during an identity outage. High value per dollar; frequently skipped.
- Dual-source a critical capability (cost: high). Running two providers for one function doubles integration and operating cost and usually halves feature depth. Justifiable for a genuinely existential dependency; a poor default. Be suspicious of resilience strategies that begin here.
- Force vendors to migrate (cost: usually fantasy). You will almost never move a SaaS vendor off their cloud. Spend that leverage on notification clauses, resilience evidence, and shorter renewal terms instead.
Reporting it upward
Concentration is the rare TPRM topic where the board is ahead of the security team, because directors already think in portfolio terms. Report three numbers per quarter: the VCI per layer with trend, the size of the largest compound cluster, and the share of clustered vendors with tested failover evidence on file. Then ask the board to set an appetite threshold, because "how concentrated is too concentrated" is precisely the kind of question boards exist to answer. The cost side of the argument is already documented in the real cost of vendor breaches; concentration is the multiplier on that cost.
ThirdSentry keeps cloud, region, and identity dependencies as structured attributes on each vendor record, alongside assessments and live monitoring, so the VCI and the compound clusters are computed from current data instead of a stale diagram. If your concentration picture lives in a slide from last year, that is the first gap to close.
