ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Vendor concentration risk is the danger that too much of your operation depends on a single supplier, or on a small group of suppliers that share a common weakness. A vendor assessment may show that each supplier is individually sound, yet the organisation is still exposed if one cloud provider, one payment processor or one software platform carries all its critical services. When that provider fails, everything fails together.
This guide explains the types of vendor concentration risk, how to measure it, how to set thresholds and what you can do about it, including the expectations that financial regulators now place on firms.
Concentration can arise in several ways. It appears when a single vendor supplies many services, when many critical functions rely on one technology, when several vendors depend on the same upstream provider, or when suppliers are located in one region exposed to the same hazard. The common feature is a shared point of failure that individual assessments do not reveal, because each one looks at a vendor in isolation. Our guide to third-party risk assessment covers the individual view, and this article covers the portfolio view.
Free third-party risk assessment
How much risk does this vendor bring?
Tier the vendor, check the evidence, rate the risks from 30 third-party scenarios and choose controls referenced to ISO 27001, NIST CSF 2.0 and DORA. You get a tier, a heat map and the findings an auditor would raise, free.
Start the free vendor risk assessment → or View premium report sample
| Type | Description | Example |
|---|---|---|
| Single-vendor | Many services depend on one supplier | One provider hosts ERP, email and storage |
| Single-service | One critical function has only one supplier | Only one payment gateway is integrated |
| Geographic | Suppliers share one region or data centre area | Three vendors all in one flood zone |
| Fourth-party | Different vendors rely on the same sub-supplier | Several SaaS tools run on the same cloud |
| Technology | Reliance on one platform, protocol or product | All authentication passes through one identity provider |
| Contractual or exit | Lock-in makes leaving impractical | Proprietary data format, no export |
Fourth-party concentration is the least visible. Our guide to fourth-party risk explains how to ask suppliers about their own dependencies.
Financial regulators have made concentration a named topic. The EU Digital Operational Resilience Act, Regulation (EU) 2022/2554, requires financial entities to carry out a preliminary assessment of ICT concentration risk at entity level before entering into contractual arrangements, in Article 29. The regulation is available on EUR-Lex. It also creates an oversight framework for critical ICT third-party providers; see our guide to critical ICT third-party providers. Other regimes, such as US interagency guidance on third-party relationships, ask banks to consider concentration in their risk management; see the overview of the interagency guidance on third-party relationships. Whether or not you are regulated, the logic applies to any organisation with critical suppliers.
Start with the critical business services and list the vendors, systems and locations each one depends on. A simple matrix with services in rows and vendors in columns quickly shows where many services pile up on the same supplier. Extend it with fourth parties where you have the information.
Useful measures include the share of critical services that rely on each vendor, the share of spend and transactions with the top three vendors, the number of critical services with a single supplier and no alternative, the number of critical vendors in one region and the percentage of critical vendors with a tested exit plan. Track them over time so leaders see the direction of travel.
Combine dependency with impact: how long could the services tolerate an outage, what would it cost, and how quickly could you switch? A vendor that supports a service with a four-hour tolerance and takes six months to replace represents a much higher concentration risk than one supporting a service with a month’s tolerance and a ready alternative.
Decide in advance what level of dependency is acceptable. Thresholds might say that no single vendor should support more than a stated share of critical services without a documented and tested exit plan, that critical services must not depend on a single region without a recovery option, or that any single-supplier critical function needs board-level acceptance. The numbers should reflect your risk appetite, and be reviewed regularly. Our guide to risk appetite explains how to set them.
There are several ways to reduce concentration, each with costs.
Diversification is not free. A second supplier increases cost and complexity, and two vendors that share the same underlying cloud provide less resilience than they appear to. Assess whether the alternatives are truly independent.
An exit plan on paper is not a capability. Test at least the critical steps: can you retrieve your data in a usable format, how long would migration take, who would do it, and what would it cost? Run a tabletop exercise where the primary provider is unavailable for a week. The findings often reveal hidden dependencies, such as a licence key or an identity link that only the failed vendor can provide. Our guide to the vendor offboarding checklist covers the end of a relationship.
Watch for signals that a dependency is becoming more dangerous: a supplier’s acquisition by a competitor, financial stress, repeated outages, a change of hosting location, loss of key staff or a rise in the share of your services that use it. Set up alerts on news and supplier notices, and ask relationship owners to report changes at each quarterly review. Early notice gives you months, not days, to arrange an alternative.
The following is a hypothetical example invented for illustration. A mid-sized insurer maps its ten critical services against 40 vendors. The matrix shows that seven critical services depend on one cloud platform either directly or through other software, and that both its claims system and its customer portal use the same identity provider. Three vendors listed as independent all run their platforms in one cloud region.
The board sets a threshold that no single provider may support more than half of critical services without a tested exit plan, and that authentication must have a fallback. The insurer adds a secondary identity provider in standby, negotiates data export and transition clauses with the cloud provider, and runs a regional failover test. Two services remain concentrated, and the board accepts the risk with quarterly monitoring. The exercise turned an unseen dependency into a managed one.
Typical weaknesses include assessing vendors only one at a time, ignoring fourth parties, treating hosting location as an IT detail, counting a second vendor that shares infrastructure as diversification, no thresholds, no exit plans or untested ones, forgetting that concentration in a payment or identity service can stop the whole business, and no reporting to the board. Another is discovering the concentration only during an outage.
Show leaders a short view: the top dependencies, the services affected, the tolerance and exit time for each, the thresholds and any breaches, with actions and owners. A heat map of vendors against services is a clear way to display it. Update the view quarterly and after major supplier changes, and feed it into your vendor risk tiering so that concentrated suppliers are classed as critical.
A structured report helps you capture dependencies, ratings and mitigation for each supplier in a consistent way. The Third-Party Risk Assessment Report and Workbook provides a report and register to document supplier assessments and actions. Whichever tool you use, keep the same fields across suppliers so that concentration can be analysed across the whole portfolio.
The risk that excessive dependence on one supplier, or several suppliers sharing a common weakness, causes serious disruption if that supplier or weakness fails.
Yes. Article 29 requires financial entities to assess ICT concentration risk at entity level before entering into contractual arrangements, and the regulation also establishes oversight of critical ICT third-party providers.
No. If both rely on the same underlying provider or region, the benefit is limited. Check that alternatives are genuinely independent and that switching has been tested.
Map critical services to vendors, then measure the share of services per vendor, single-supplier functions, regional clustering and the percentage of critical vendors with tested exit plans.
A senior person or committee with authority over the affected services, with a written rationale, compensating controls and an expiry date for the decision.
September 30, 2026
