Concentration risk is the exposure created when a meaningful share of an organization's vendors, or an entire sector's vendors, depend on the same underlying provider - a single cloud region, a single identity provider, a single CDN, a single payment rail. Score each of those vendors individually and every one can look fine: current SOC 2 report, clean penetration test, no incident history. The risk only becomes visible when you stop looking at vendors one at a time and start looking at what they all quietly share underneath. This is why concentration risk sits alongside, but separate from, inherent and residual risk - it is a portfolio-level measurement, not a per-vendor one, and no amount of per-vendor due diligence will surface it on its own.
The two shapes concentration risk takes
Practitioners tend to run into two distinct versions of the same underlying problem.
- Vertical (subprocessor) concentration. Several of your directly-contracted vendors rely on the same fourth party further down the chain - the same cloud provider, the same authentication service, the same email-delivery API. On your vendor list they look unrelated. Underneath, they share a single point of failure. See subprocessor and fourth-party risk in the glossary for the building blocks.
- Horizontal (sector or systemic) concentration. An entire industry - sometimes an entire economy - depends on a small handful of hyperscale providers for compute, identity, or content delivery. A failure or compromise at one of them is not a single company's incident; it is a sector-wide event. This is the shape that has pulled regulators in directly, because no individual firm's vendor management can fix a market structure problem on its own.
Why regulators now name it directly
Concentration risk used to be an internal risk-management concern. It is increasingly a named, specific regulatory requirement, for reasons that track the two shapes above closely.
DORA (the EU Digital Operational Resilience Act) makes this explicit at the individual-firm level: Article 29, "Preliminary assessment of ICT concentration risk at entity level," requires in-scope financial entities to assess - before signing a new ICT contract supporting a critical function - whether the provider is easily substitutable, whether multiple existing arrangements already sit with the same or closely connected provider, and how long or complex subcontracting chains might limit the firm's ability to actually monitor what it has contracted for.
The UK has gone further at the sector level. Since 13 July 2026, the Bank of England, the Prudential Regulation Authority, and the Financial Conduct Authority have begun direct oversight of firms that HM Treasury has designated Critical Third Parties to UK finance - a power created by the Financial Services and Markets Act 2023 specifically because, as the Bank of England has put it, when the same small set of providers becomes embedded across thousands of financial firms, a single disruption can threaten the stability of the financial system rather than just one firm's operations. The first four providers designated under the regime are 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, not a private contractual matter between any one bank and its cloud vendor.
US banking regulators frame the same concern in vendor-management terms rather than systemic ones. The interagency guidance on third-party relationships issued jointly by the Federal Reserve, OCC, and FDIC lists "dependency on a single provider for multiple activities" as an operational-resilience consideration banking organizations should account for, alongside ongoing monitoring of a third party's own reliance on subcontractors. It stops short of DORA's or the UK's explicit concentration-risk assessment mandate, but the expectation that examiners will ask about single-provider dependency is the same one.
How to actually find it in your own portfolio
Concentration risk is invisible in a vendor-by-vendor spreadsheet by design - each row looks independent. Finding it requires deliberately cutting the portfolio a different way, by shared infrastructure rather than by vendor name.
- Ask directly, in the questionnaire. Most SIG- or CAIQ-style assessments (see the Shared Assessments SIG) have a section on hosting and infrastructure. Make sure it captures cloud provider and region, CDN, DNS provider, identity/SSO provider, and payment processor - not just "do you use a cloud provider."
- Read the subservice organizations section of every SOC 2 report. Auditors are required to name the subservice organizations a vendor relies on for the controls in scope. This is one of the few places a vendor's infrastructure dependencies are disclosed in writing rather than asserted informally.
- Pull published subprocessor lists. Most SaaS vendors publish a subprocessor page for GDPR reasons, listing exactly which downstream providers touch customer data. Aggregating these across your portfolio is usually the fastest way to spot a shared name appearing under a dozen different vendors.
- Correlate external attack-surface data. IP ranges, ASNs, and certificate issuers observed across your vendors' internet-facing infrastructure - the same signal continuous monitoring already collects - can reveal shared hosting that a vendor's own disclosures missed or understated.
Once collected, the useful artifact is a matrix, not a list: vendors down one side, shared dependencies across the top, so clusters are visible at a glance.
| Vendor | Cloud / region | Identity provider | CDN |
|---|---|---|---|
| HR platform | Same hyperscaler, us-east region | Shared corporate IdP | Provider A |
| Ticketing tool | Same hyperscaler, us-east region | Shared corporate IdP | Provider B |
| CRM | Different hyperscaler | Shared corporate IdP | Provider A |
Read that way, three "unrelated" vendors share two single points of failure: an identity provider and a region. Neither shows up if each vendor is assessed in isolation.
What to do once you've found it
The point of surfacing concentration risk is rarely "stop using the vendor" - at hyperscaler and identity-provider scale, genuine alternatives are often limited, and the concentration is frequently a rational trade-off the whole market has made. The point is to stop treating each affected vendor as an independent risk and start managing the cluster deliberately:
- Feed it into tiering. A vendor that is one of many sitting on a shared single point of failure should be tiered, in part, on that basis - not solely on its own control posture.
- Plan for the correlated failure, not just the single vendor's failure. If the underlying provider goes down, several vendors fail together. Incident response and business-continuity plans should name that scenario explicitly rather than assume vendor outages are independent events.
- Push contractual terms where you have leverage. Notification timelines, failover commitments, and audit rights matter most for the vendors sitting on your biggest concentration clusters.
- Reassess when the regulatory picture shifts. A provider being designated critical under a regime like the UK's CTP framework, or newly in scope under DORA Article 29, is itself a signal worth acting on even if nothing about the vendor relationship changed.
Concentration risk is a discovery problem before it's a decision problem
Most programs underestimate concentration risk not because they disagree on what to do about it, but because they never see it - it lives in subprocessor disclosures and infrastructure metadata that a per-vendor questionnaire doesn't surface on its own. Platforms that correlate external attack-surface signal across an entire vendor portfolio, rather than one vendor at a time, are built to make these clusters visible automatically; Rescana takes this approach, and several continuous-monitoring providers such as BitSight, SecurityScorecard, and UpGuard collect the underlying infrastructure signal that makes this kind of correlation possible. Whichever platform runs the program, the discovery step - building the shared-dependency matrix - has to happen before tiering or contract terms can reflect the real risk.
Frequently asked questions
What is concentration risk in third-party risk management?
Concentration risk is the exposure created when a significant share of an organization's vendors - or an entire sector's vendors - depend on the same underlying provider, such as a single cloud region, identity provider, content delivery network, or payment processor. Each vendor can pass its own individual risk assessment, but if the shared provider fails or is compromised, every vendor sitting on top of it fails together. It is a portfolio-level risk rather than a property of any one vendor, which is why it does not show up in a vendor-by-vendor questionnaire and has to be found by deliberately mapping shared infrastructure across the portfolio.
How do you identify concentration risk across a vendor portfolio?
Identifying concentration risk requires cutting the portfolio by shared infrastructure rather than by vendor name. Practical sources include the infrastructure section of SIG or CAIQ questionnaires, the subservice organizations section of each vendor's SOC 2 report (which auditors are required to disclose), published subprocessor lists that most SaaS vendors maintain for GDPR compliance, and correlation of external attack-surface data such as shared IP ranges, ASNs, or certificate issuers across vendors. The results are best organized as a matrix of vendors against shared dependencies - cloud provider and region, identity provider, CDN - so that clusters become visible rather than staying hidden inside separate, seemingly unrelated vendor files.
Does DORA require assessing ICT concentration risk?
Yes. Article 29 of DORA, titled "Preliminary assessment of ICT concentration risk at entity level," requires in-scope EU financial entities to assess concentration risk before contracting for ICT services supporting a critical or important function - specifically whether the provider is easily substitutable, whether the entity already has multiple arrangements with the same or closely connected provider, and how complex or long subcontracting chains might limit its ability to monitor what it has contracted for. This sits alongside sector-level measures such as the UK's Critical Third Parties regime, under which the Bank of England, PRA, and FCA began direct oversight of designated critical providers - including major cloud vendors - in July 2026, reflecting the same underlying concern applied at the level of the financial system rather than a single firm.