The vendor risk register lists 142 vendors. The security team has tiered them, run questionnaires on the top tier, and feels organized. Then the AWS us-east-1 outage hits, and you discover that 37 of those 142 vendors are themselves running on us-east-1. Customer support is down because your help-desk tool is down. Marketing automation is down. Three different "alternative" CRMs are all down because they all use the same underlying database provider. Your "diversified" vendor stack collapses to a single point of failure that nobody mapped.
This is concentration risk — and it's the dimension of vendor risk that traditional TPRM programs systematically miss. The questionnaires probe individual vendor posture; they don't probe what happens when ten vendors share an underlying dependency that fails simultaneously. The 2025 AWS outages, the CrowdStrike incident, and the 2024 Change Healthcare cascade all exposed the same gap: companies that thought they had vendor diversification actually had topological concentration that only became visible during the incident.
The four layers of vendor concentration risk
Concentration risk lives at four distinct layers of the vendor stack. A complete map covers all four; most programs cover only the first.
Each layer requires different evidence to map. Direct concentration is visible from your own usage data. Sub-processor concentration requires reading each vendor's sub-processor list. Infrastructure concentration requires asking each vendor (or inferring from their tech blog and status page). Software supply-chain concentration is the hardest — most vendors don't publish dependency manifests.
The vendor concentration map — what it looks like, how to build it
The artifact that closes the gap is a vendor concentration matrix: vendors on one axis, shared dependencies on the other, with cells marked where a vendor relies on a given dependency. The matrix surfaces clustering that the per-vendor view never reveals.
List your top 20–40 vendors by business criticality, not by spend
Spend is a poor proxy for concentration risk. A $20K/year vendor whose outage halts customer onboarding matters more than a $200K/year vendor whose outage delays a non-critical workflow. Tier by business-function criticality.
Pull each vendor's sub-processor list and infrastructure disclosures
Most vendors publish sub-processor lists for GDPR compliance. Most don't publish infrastructure details, but you can usually infer cloud provider from their public engineering content, status page, or by asking your account manager. Document what you find; flag what you can't determine.
Build the matrix
Rows: your vendors. Columns: cloud providers (AWS, GCP, Azure, regions), critical sub-processors (Stripe, Twilio, Auth0/Okta, SendGrid, Snowflake), critical software dependencies (if known). A check mark in a cell means "this vendor depends on this thing." Sum the columns: any column with 5+ checks is a concentration risk.
Quantify the failure scenario per concentration
For each concentration with 5+ vendor checks: what business functions go down simultaneously if this dependency fails? What's the revenue impact per hour of outage? This is the number that justifies any diversification investment.
The single most common concentration finding when teams build this matrix for the first time: 60%+ of their critical SaaS vendors run on AWS us-east-1 specifically. Not just AWS — the specific region. The reason: us-east-1 is the default region for most AWS-deployed SaaS, has the lowest latency for US east coast traffic, and has the most service availability. The result: an us-east-1 incident takes down a larger fraction of the vendor stack than a multi-region AWS architecture would imply. This is invisible to per-vendor TPRM; it's obvious in the concentration matrix.
What to do when you find a concentration
Three responses, depending on the concentration's nature and the business cost of the failure scenario.
How concentration risk fits into the broader TPRM program
The concentration map is a different artifact from the per-vendor risk register. Both are necessary; neither substitutes for the other.
What the per-vendor register answers
For vendor X specifically: what data do they have, what's their security posture, what's their breach history, what's the contractual recourse, what's their incident response capability? This is the standard TPRM artifact. Most programs cover this well.
What the concentration map answers
Across the vendor stack: which underlying dependencies, when they fail, take down a meaningful fraction of vendors simultaneously? Where does the per-vendor view obscure topological risk? This is the artifact most programs are missing entirely, and the one the 2024–2025 cascading-failure incidents made unavoidable.
The two together produce a TPRM program that handles both individual vendor risk and topological risk. The per-vendor register catches a single vendor breach; the concentration map catches a shared-dependency cascade.
The vendor incident response question concentration unlocks
When a single named vendor has an incident, the response is bounded — assess customer impact, notify if needed, work with the vendor on resolution. When a shared dependency fails and 10+ vendors are affected simultaneously, the response is qualitatively different: simultaneous degradation across multiple business functions, customer-facing impact across multiple surfaces, communications that need to be triaged across overlapping affected populations.
The IR plan for "Salesforce is down" is straightforward. The IR plan for "AWS us-east-1 is down and so is 60% of our vendor stack" is operationally different — and most companies don't have one until they need it. The concentration map is the input that makes the multi-vendor IR plan possible.
The bottom line
Per-vendor TPRM catches the risks that fit on a single vendor's row in the risk register. It systematically misses concentration risk — the topological exposure that lives in the columns, where many vendors depend on the same underlying thing. The 2024–2025 cascading vendor failures made this gap unavoidable. The fix is a concentration matrix that maps shared cloud, sub-processor, and supply-chain dependencies across the vendor stack, with a quantified failure scenario per concentration. The artifact takes a day or two to build and surfaces risk patterns the per-vendor view will never reveal.
Build the concentration map without spending the quarter on it
vCISO Lite generates the vendor concentration matrix from your vendor inventory — pulling sub-processor disclosures, mapping infrastructure dependencies, surfacing the columns where concentration risk lives — and ties it to the per-vendor risk register so both views stay coherent. Built for the 33 million US small and mid-sized businesses that don't have a CISO yet, but need a TPRM program that catches both single-vendor risk and the cascading-failure scenarios the 2024–2025 incidents made operationally real.
If you've been meaning to build the concentration map but haven't found the time, visit vcisolite.com to learn more and get started.
Where this matters next
Third-party risk management for growing companies — the per-vendor TPRM foundation that the concentration map sits on top of.
The 5 vendors you should actually worry about (and the 50 you shouldn't) — the prioritization framework for which vendors to focus on in the per-vendor register, before layering the concentration analysis on top.
How to evaluate AI in your vendor's products — the AI-specific vendor evaluation lens that increasingly intersects with both per-vendor TPRM and concentration analysis (AI vendor concentration is its own emerging dimension).
Someone else's breach: why vendor IR is its own discipline — concentration risk is a standing-program lens; when one of the concentrated vendors actually breaks, an incident-time discipline takes over. The companion cluster for everything that happens after the vendor's status page goes red.
Mitigation debt: the silent risk that accumulates between vendor incidents — the cross-cluster bridge. A concentrated upstream that has already produced one vendor incident in your portfolio carries different residual risk depending on whether you delivered on the mitigations you committed to last time.
Where this matters next
Third-Party Risk Management for Growing Companies — Your vendors are your risk. Here's how to assess, tier, and manage third-party security without drowning in questionnaires
TPRM Software: 2026 Buyer's Guide — Compare Third-Party Risk Management software for 2026 — six platforms across the platform-augmented, outside-in continuous rati…
The Security Questionnaire Survival Guide — Enterprise questionnaires are killing your deals
Someone Else's Breach: Why Vendor Incident Response Is Its Own Discipline — Traditional risk assessment asks what might happen