Concentration Risk Monitoring Across Shared Vendors

A vendor can pass every review a risk team throws at it, a current SOC 2 report, a clean penetration test, no incident history on file, and the organization can still be sitting on a structural exposure nobody caught. That is the paradox at the center of concentration risk: it does not appear in any single vendor's file, because a review measures one vendor at a time and concentration risk is not a property of any single vendor. Concentration risk is the exposure created when a meaningful share of an organization's vendors depend on the same underlying provider: one cloud region, one identity provider, one CDN, or one payment rail. Score each dependency in isolation and the picture looks fine every time, because the question due diligence asks is "is this vendor trustworthy," not "what does this vendor share with the other vendors already under contract"; 73% of organizations reported more than three material supply chain disruptions in the past twelve months, so a quarterly or annual mapping exercise will routinely miss the disruption that is already in progress.

That second question only has an answer at the portfolio level, and no per-vendor assessment, however rigorous, is built to produce it. A questionnaire evaluates a vendor against its own controls, its own history, its own financial standing. It was never designed to check whether that vendor, combined with others already in place, quietly stacks multiple critical functions onto the same or a closely connected vendor. A procurement team can clear every review it is obligated to run, hit every deadline, close every finding, and still arrive at zero visibility into concentration, because the visibility was never going to come from that process in the first place.

This is a unit-of-analysis problem. Vendor risk management asks "is this row safe." Concentration risk asks "what do all these rows have in common underneath." Those are different questions, and answering the first one repeatedly, no matter how well, does not get you closer to answering the second.

Two structural shapes concentration risk takes in practice

Concentration risk occurs in two recognizable patterns, and most practitioners will find at least one already sitting inside their own vendor list.

The first is vertical, sometimes called subprocessor concentration. Several vendors an organization contracts with directly all lean on the same fourth party further down the chain, sharing the same cloud provider, the same authentication service, or the same email-delivery API. On paper, on the vendor list itself, these vendors look unrelated. They serve different functions, sit in different departments, were procured at different times. They share a single point of failure beneath the surface differences, produced by the fact that different departments and procurement timelines can still route through the same underlying provider, and that sharing stays invisible until someone goes looking for it.

The second is horizontal, or sector-wide, concentration. Here an entire industry, sometimes an entire economy, depends on a small handful of hyperscale providers for compute, identity, or content delivery. This is not a fringe scenario. AWS, Microsoft Azure, and Google Cloud together hold roughly 63% of global cloud infrastructure spend, which makes horizontal concentration the market's default structure rather than an outlier condition. The European Central Bank has flagged that outsourcing budgets across the financial sector concentrate with only ten providers, more than 30% of total outsourcing spend, most of them headquartered outside the EU. Concentration at that scale is already the baseline condition of how the sector operates. It is the baseline condition of how the sector already operates.

Both shapes have already produced real disruption. During the automotive semiconductor shortage of 2020 to 2022, Ford and GM both experienced production slowdowns tied to heavy reliance on a limited pool of semiconductor vendors, a case where upstream dependency inside what looked like a diversified supplier base still triggered outsized operational damage. And in September 2025, a compromise affecting a shared airline check-in and passenger-processing system cascaded across multiple European airports, because multiple airlines and airport operators had all built their operations on the same structurally critical provider. Neither event was a failure of vendor vetting. Both were failures to see that a nominally diverse set of relationships in fact ran through the same underlying provider.

How regulators have moved from guidance to named mandates

Regulators have stopped treating concentration risk as a maturity nicety and started writing it into binding obligations, and that shift changes what "we did our vendor due diligence" is worth as a defense.

Under DORA Article 29, titled "Preliminary assessment of ICT concentration risk at entity level," in-scope financial entities have been required since January 2025, as a precondition to signing any new ICT contract supporting a critical function, to assess if the provider is easily substitutable, if multiple existing arrangements already sit with the same or a closely connected provider, and how long or complex the subcontracting chain runs before it starts limiting the firm's ability to monitor what it actually contracted for. That is a precondition to signing. It is a precondition to signing.

DORA backed the mandate with enforcement infrastructure. In November 2025, the European Supervisory Authorities designated the first 19 Critical Information and Communication Technology Third-Party Providers, putting concentration in front of sector regulators as a named, tracked category rather than a theoretical concern. The UK followed with its own version: since 13 July 2026, the Bank of England, the Prudential Regulation Authority, and the Financial Conduct Authority have exercised direct oversight over firms HM Treasury designated as Critical Third Parties to UK finance, a power created under the Financial Services and Markets Act 2023 specifically because concentration across thousands of financial firms threatens system stability, not just the stability of any one institution. The first four providers named under that regime were Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Ltd, and Oracle Corporation UK Limited, named publicly because concentration at that scale is treated as a system-level risk.

US regulators have not gone as far, but the direction is the same. Interagency guidance from the Federal Reserve, the OCC, and the FDIC lists dependency on a single provider for multiple activities as an operational-resilience consideration. It stops short of DORA's explicit contractual mandate, but examiners now ask directly whether the firm depends on a single provider in practice, which functionally narrows the gap. Passing a per-vendor review no longer answers the question a regulator is going to ask. Info-Tech Research Group frames accountability clearly, stating that it sits with the CIO and CRO, not the vendor or the regulator.

Where concentration hides: the infrastructure layers most assessments miss

Confidence and reality have diverged badly in this space. Most security leaders report high confidence in their SaaS security programs, yet a majority of organizations still experienced a SaaS security incident within the prior eighteen months. That gap is a strong signal that current assessments are looking in the wrong places, and four infrastructure layers explain most of it.

The first is the cloud provider and region. The relevant question is never simply which vendor uses a cloud provider. It is which provider and which specific region, because several vendors quietly sharing the same regional footprint means a single regional outage takes down services that look completely unrelated on the vendor list. The third is identity and SSO. The fourth is the payment processor and the financial rails underneath it: when several vendors in a portfolio share a rail, its failure hits every one of them at once rather than staying confined to a single vendor's incident.

Some categories make this concentration structurally unavoidable rather than merely common. Cloud infrastructure, cybersecurity and endpoint security, DevOps and software delivery platforms, and backup all have only one or two viable providers at meaningful scale, so a portfolio built from best-in-class tools in these categories will concentrate almost by definition.

A second hidden layer, produced by the same structural blind spot that leaves infrastructure dependencies unexamined, is supplier viability. Sphera's Supply Chain Risk Report identifies financial and operational stress as the largest category of supplier risk events, and one that grew in 2025 relative to the year before. Spend-based concentration metrics miss this entirely, because a low-spend, niche supplier providing a specialized component or a single-source dataset can carry disproportionate operational impact regardless of what the organization pays it. A vendor line item that looks trivial on a procurement report can still be a single point of failure. The CDN and DNS provider, the content delivery and resolution infrastructure, is rarely captured in questionnaires, yet it is a shared dependency that can disable customer-facing services across a portfolio simultaneously.

How to build a portfolio-level dependency map from the data you already have

None of this requires new vendor outreach or a fresh round of questionnaires. It requires reorganizing information the organization already has, and the shift starts with the artifact itself: a matrix, with vendors run down one side and shared dependencies run across the top. Vendors run down one side, shared dependencies run across the top, cloud provider and region, identity provider, CDN, DNS, payment processor, and the clusters become visible at a glance in a way a flat vendor list never surfaces.

Four data sources feed that matrix without a single new vendor call. The first, and easiest to reach, is the infrastructure section already buried inside standard assessments. The third is the subprocessor list most SaaS vendors already publish for GDPR compliance, naming exactly which downstream providers touch customer data; aggregating these across a portfolio is usually the fastest way to spot the same name recurring under many different vendors. The fourth is external attack-surface data, IP ranges, ASNs, certificate issuers observed across a vendor's internet-facing infrastructure, which can reveal shared hosting a vendor's own disclosures understated or missed entirely.

Financial stability belongs in the same map. Revenue and margin trends, debt and liquidity, credit ratings, customer concentration on the vendor's own side, all of these matter for any vendor that underpins a critical function, because a financially stressed provider is a concentration risk before it ever actually fails.

Spend concentration is a useful trigger for the analysis. When the top three vendors account for a dominant share of total annual procurement spend, that is a signal to run the mapping exercise, though the mapping exercise itself still has to be run. Once the matrix exists, the real work is triage: not every cluster of shared dependency carries equal risk, and prioritization should follow how hard a given dependency would be to unwind, weighing contractual rights, data portability, available market alternatives, in-house skills, technical feasibility, and realistic migration time and cost. Substitutability, not spend and not headline count, is the dimension that tells a team where to act first. The questionnaire infrastructure section notes that SIG- and CAIQ-style assessments have a hosting and infrastructure section, and it should capture cloud provider and region, CDN, DNS, identity/SSO provider, and payment processor, not just "do you use a cloud provider". The SOC 2 subservice organizations section requires auditors to name the subservice organizations a vendor relies on for in-scope controls, making it one of the few places infrastructure dependencies are disclosed in writing rather than asserted informally.

Why point-in-time mapping is not monitoring

A dependency map is a snapshot, and every snapshot starts going stale the moment it's finished. Vendor risk profiles are not static: changes in market health, regulatory posture, or a vendor's own leadership can alter its risk profile overnight, and a map built at onboarding reflects that moment, not the present one. Given that 73% of organizations already report more than three material supply chain disruptions a year, a quarterly or even annual mapping cycle will routinely miss the disruption that is already unfolding while the map sits unopened in a shared drive.

The stakes of missing it keep rising. Across a large dataset of confirmed breaches, the share involving a third party doubled, and more than one in three data breaches in 2024 traced back to a third-party vendor, with average remediation costs running into the millions. Continuous monitoring, to actually address concentration rather than just vendor risk generally, needs to track a specific set of change signals rather than a general sense of vendor health.

Vendor infrastructure changes matter first: a vendor migrating to a new cloud region or a new identity provider redraws the dependency map without a single new contract being signed. Merger and acquisition activity matters just as much, because when a vendor gets acquired by another provider already sitting in the portfolio, two previously independent dependencies quietly become one. Subprocessor list updates deserve close attention too, since vendors add or swap subprocessors between formal assessment cycles, and the GDPR-driven subprocessor page is often the earliest public signal that a new shared dependency has appeared. Financial stress signals, deteriorating credit, leadership turnover, news of a major contract loss, can precede a viability failure by months, giving a monitoring program real lead time if it's watching. And incident signals at shared infrastructure providers matter beyond the vendor that actually reports them: a security event at a hyperscaler, a CDN, or an identity provider is relevant to every other vendor in the portfolio that shares it, not only the one named in the breach notification.

Monitoring vendors individually rather than monitoring the shared infrastructure that produces their risk is a structural gap, and 70% of risk managers report lacking full visibility into their supplier risk landscape.

Non-human identities as a concentration vector the dependency map rarely captures

Even a well-built dependency map misses one layer almost entirely: the machine credentials connecting vendors to each other. Non-human identities, OAuth tokens, API keys, service accounts, outnumber human users by roughly 82 to 1 in enterprise environments. They are the actual connective tissue linking vendors together, and their governance rarely reflects the authority they carry.

OAuth tokens in particular grant durable, delegated access without any of the session controls applied to a human login: no MFA prompt, no conditional access policy, no timeout tied to a session. A token compromised at one vendor is standing access into whatever it's connected to, quietly, indefinitely, until someone revokes it. And most of that access sits unused: non-human identities on average exercise just 2% of what they're actually granted. The bulk of the access surface exists unexploited but very much exploitable.

The August 2025 Salesloft-Drift breach shows exactly how this plays out at scale. The threat actor UNC6395 stole OAuth tokens from the Salesloft-Drift integration and used them to reach Salesforce and other connected instances across more than 700 potentially affected organizations, without deploying a single piece of malware. The breach cascaded precisely because the tokens involved were long-lived and broadly scoped, turning one integration compromise into a multi-organization event. GitGuardian's 2026 data adds a sobering coda: a material share of organizations already have at least one publicly exposed asset carrying a long-lived, still-valid vendor secret, making the shared dependency in question an already-realized risk in a meaningful fraction of portfolios. It's already breached. NHI3:2025 from the OWASP Non-Human Identities Top 10 describes Vulnerable Third-Party NHI as risk inherited from a vendor's or integration partner's own NHI hygiene, where a compromised SaaS-to-SaaS OAuth grant is a vector that bypasses every per-vendor assessment that evaluated the vendor's own controls.