When a critical technology provider fails: assessing concentration and exit readiness

Why supplier counts can mislead

Consider a hypothetical institution offering digital payments. Its customer application, transaction monitoring and support platform come from three suppliers. The procurement register records three independent contracts. A service review discovers that all three depend on the same identity tenant for administration and incident coordination.

The institution also has a recovery environment in another geographic region. That arrangement may help with a regional outage, but it does not establish independence from compromised administrative identities or a shared configuration error. The relevant question is the failure scenario against which the alternative was designed.

This example illustrates a distinction between commercial diversity and operational independence. It does not establish that multiple providers are always preferable. A second platform introduces its own integration, staffing and reconciliation demands. The decision should compare actual recovery options and their costs, including the operational complexity the institution can sustain.

Map the service before judging the provider

Select a service with an accountable business owner and a defined outcome: accepting a payment instruction, processing a withdrawal or providing access to customer records. Specify what minimum acceptable delivery means during disruption. Avoid describing the service only as a software product.

Record dependencies at a level that supports decisions. The mapping exercise should answer the following questions:

Completeness is a working objective, not a reason to delay every decision until the map is perfect. Mark each dependency as confirmed, partly confirmed or unknown. Give material unknowns an investigation date and escalation route. A diagram with unlabelled uncertainty can create more confidence than the evidence supports.

Distinguish continuity from exit

Continuity keeps a service operating or restores it after disruption. Exit transfers or ends the relationship. Their time horizons and prerequisites may differ substantially.

For the hypothetical payments service, an alternate processing route might support a limited subset of transactions during an outage. Moving the complete customer history to a replacement platform could require transformation, testing and commercial negotiation. Calling both arrangements “the exit plan” obscures what each can achieve.

Use separate readiness statements. A continuity statement should identify the scenario, activation authority, available capacity and duration. An exit statement should identify the target operating model, data export conditions, migration dependencies, likely constraints and the evidence supporting feasibility. Where a replacement is unavailable within the desired period, record that limitation explicitly.

Examine concentration through scenarios

The following review sequence is proposed for internal use:

1. Name the failure. Provider outage, supplier compromise, loss of administrative access and abrupt provider withdrawal are different scenarios.
2. Identify simultaneous effects. Mark which services share the affected component or operational dependency.
3. Test the alternative's independence. Check its identity, data, staffing, connectivity and configuration dependencies.
4. Estimate the service consequence. Describe customer impact and operational workload without inventing precision the evidence cannot support.
5. Choose a treatment. Options include stronger recovery, reduced coupling, a staged migration, a bounded manual process or explicit acceptance.

The exercise should include the provider where its actions are essential. An institution cannot establish a supplier's recovery performance by rehearsing only its own internal call tree. Conversely, supplier participation in a discussion is not proof that technical recovery works. Report what was actually demonstrated.

Evidence that should change a decision

A stronger review replaces broad assurances with specific artefacts. A claim that data is portable becomes more useful when a sample export has been imported into a controlled target and checked. A claim that support is available becomes more useful when escalation contacts and access prerequisites have been exercised.

Evidence still needs scope. A successful sample migration does not establish that the full production dataset can move within the same period. A recovery test with every provider engineer present may not represent the staffing available during a widespread incident. Document those differences before using the result to justify acceptance.

The objective is proportional assurance. Low-consequence relationships need not receive the same investigation as a service whose failure would immediately interrupt customer access to funds. Resource allocation should follow consequences and uncertainty, with a review when either changes.

Questions for the risk committee

The committee should be able to establish which critical services could fail together, whether alternatives remain accessible under the chosen scenario, and what evidence supports restoration or transfer. It should also understand whether the institution is knowingly accepting a difficult-to-replace dependency and why that choice is reasonable.

Useful measures include critical services with reviewed dependency maps, material unknowns past their investigation date, and continuity assumptions validated through exercises. These are oversight indicators; none is a probability of institutional failure.