Measuring Concentration Risk

Measuring concentration risk means working out how much of a firm's important work would be affected together by one failure. The unit of measurement is the dependency, not the contract. A firm starts from its important services, traces what each service needs in order to run, and then looks for points where those needs overlap. Where several services share a provider, a region, a technology, or a sub-provider, that overlap is concentration, however the contracts are written.

A useful measurement therefore produces a map and a judgement, not just a list. The map shows where dependencies converge. The judgement concerns what that convergence would mean during a disruption: which services stop together, how far the effect spreads, and how difficult recovery would be. Without that second step, a measurement can be accurate as a count and still unhelpful as a risk picture.

Measurement starts with important services, because not every dependency carries the same weight. A firm identifies the services whose disruption would matter most to customers, to market functioning, or to its own operations, and then traces the systems, data, people, and third parties each service depends on. That service-first order keeps the work focused. A supplier inventory built without services can grow very large while saying little about what would actually fail together.

For each service, the trace needs to go beyond the direct supplier. It should record the provider of the service, the platform it runs on, the region where it runs, the connectivity it uses, and any known sub-providers that provide an essential part of it. Gaps in that information should be recorded as gaps, not filled with assumptions. A map that shows its own blind spots is more useful than a complete-looking map that hides them.

Counting providers answers a purchasing question: how many suppliers does the firm pay. Counting dependencies answers a resilience question: how many services rely on the same thing. The difference becomes clear with group structures. Several suppliers that belong to one group, share one platform, or rely on one subcontractor may present themselves as separate choices while behaving as one dependency during an incident. Treating them as separate in a measurement would understate the risk.

A dependency count therefore groups suppliers and components by what would fail together. If two suppliers share a platform, they count as sharing a dependency even if their contracts are separate. If one supplier provides several services through the same region and the same operations team, those services share dependencies too. The aim is not to produce a single perfect score. It is to show where failure would be correlated, so that planning and testing can be aimed at the right places.

A measurement should connect each concentration point to the services it touches and to the effect of losing those services together. That means describing, in plain terms, which customer journeys are interrupted, which internal processes stop, and which records or data become unavailable. It also means considering recovery: whether an alternative route exists, whether data can be restored, and whether the firm can still communicate with customers and staff while the primary route is down.

This impact view is what turns a map into a risk assessment. Two concentrations can look similar on a diagram and differ greatly in practice. One might affect a service that can be paused and recovered later with limited harm. Another might affect payments, customer access, and reporting at the same time, leaving few workarounds. Distinguishing those cases helps a firm decide where redundancy, contractual protections, or exit planning matter most, and where accepting the concentration, with eyes open, is the more honest course.

Take an illustrative lending operation as an example. Applications are received online, credit information is retrieved, decisions are recorded, and funds are released. The firm might use separate suppliers for the online channel, the credit data service, and the payment release. If the online channel and the decision record both depend on the same identity checking component, supplied through a subcontractor, a failure in that component could block new applications and prevent staff from verifying existing decisions at the same time.

A provider count would miss that link, because the identity component does not appear as a direct supplier in either contract heading. A dependency map would show it as a shared point. That visibility does not automatically solve the problem, but it changes the conversation with the direct suppliers, the testing plan, and the contingency thinking. The firm can test what happens when that component is unavailable, rather than testing each supplier in isolation.