Concentration Risk

Individual resilience analysis asks what happens when a dependency fails. Concentration risk asks what happens when it fails for everyone at once — when the same cloud provider, the same identity service, the same payments processor, the same security agent or the same certificate authority underpins a large share of an industry.

The distinction matters because correlated failure defeats the assumptions behind most contingency arrangements. A plan to shift to an alternative provider assumes the alternative has spare capacity; if every affected organisation executes the same plan simultaneously, it does not.

Why it matters

Regulators care about this because it is systemic rather than commercial. A single institution's outage is that institution's problem; a simultaneous outage across a large fraction of a sector is a public one, which is why supervisory attention has moved toward critical third parties and why exit and continuity plans are now demanded rather than assumed.

Internally, the same reasoning applies at a smaller scale. A dependency used by every service in an organisation — a service registry, a configuration store, an identity provider, a shared database — has a blast radius equal to the company, and its failure is the difference between an incident and an outage.

Implementation patterns

• Inventory the genuinely shared dependencies, internal and external, and for each state who is affected when it fails completely. Any answer of "everyone" is the finding.
• Distinguish correlated from independent failure in resilience analysis, since redundancy protects against the second and most serious incidents are the first.
• Reduce the shared surface where it is affordable: per-cell control planes, regionalised services, and caching with stale-serving so a shared dependency's outage degrades rather than halts.
• Static stability against shared dependencies — cached configuration, long stale-serving windows, no describe/list calls in the request path — so a control-plane failure removes the ability to change rather than the ability to serve.
• A tested capability to operate without the dependency, at least in degraded form, rather than a documented intention.
• Contractual protections for external providers: notice periods, data return, assistance obligations.
• Honest assessment of the alternative. Multi-provider arrangements reduce concentration and increase complexity, cross-provider transfer cost and operational surface — and frequently increase total risk, so the decision must be evidence-based rather than reflexive.
• Scenario testing that assumes everyone else is also affected, which is what distinguishes concentration analysis from ordinary continuity planning.

Industry example

The July 2024 CrowdStrike incident is the clearest recent demonstration: a single vendor's content update simultaneously affected airlines, hospitals, banks and broadcasters, because the same agent ran on a large share of enterprise endpoints. No individual organisation's redundancy helped, because the failure was inside a component every one of them shared.

Cloud control-plane incidents produce the same shape at regional scale, and the 2021 us-east-1 event demonstrated the internal version: many services and many customers depending on the same region's control plane and the same global services hosted there, so an impairment propagated across organisations that had no relationship with one another.

Failure scenarios

• Shared dependencies never inventoried, so the exposure is unknown.
• Contingency plans that assume the alternative has capacity, when every affected party will call it simultaneously.
• Redundancy analysis assuming independence, where the failure is correlated.
• A single global control plane behind an otherwise well-isolated architecture.
• "We do not deploy in that region" treated as isolation, when global services hosted there are still on the path.
• Multi-cloud adopted reflexively, adding cost and complexity without reducing the actual correlated risk.
• Exit plans never rehearsed, so the capability is asserted rather than demonstrated.
• Third-party sub-processors unmapped, so the concentration exists one layer below where anyone looked.

Trade-offs

Reducing concentration is expensive and frequently reduces reliability in the ordinary case. A second provider means two operational surfaces, two sets of expertise, cross-provider data transfer at the highest available prices, and lowest-common-denominator architecture — and a more complex system fails more often, even if it fails less severely.

There is also a genuine argument that concentration buys reliability: a large provider operates at a standard most organisations cannot match, and the correlated events are rare precisely because of that investment.

The trade is everyday reliability, cost and complexity against the severity of a rare correlated event. The defensible position is rarely full duplication — it is knowing where the shared dependencies are, degrading gracefully when they fail, and having tested the ability to operate in a reduced form — with full diversification reserved for the small number of dependencies where a correlated failure would be existential.

Interview question

"Name the three dependencies whose failure would affect our entire product, and for each tell me whether our contingency plan assumes something that would also be unavailable to everyone else — then tell me which one you would actually invest in reducing."