When a Supplier Becomes Critical

A supplier becomes critical when a service can no longer run, or recover from disruption, without that supplier, whether or not the supplier was critical when first selected. Under DORA, criticality is therefore not fixed at signing; it is a judgement that must be revisited as services, providers and markets change. A small tool can grow into a central dependency, a provider can absorb functions from other suppliers, or several services can quietly converge on one platform. Recognising that shift matters because a critical provider warrants deeper oversight, stronger contract protection, clearer contingency planning and greater senior attention than a routine supplier.

An analytics illustration shows drift clearly. A reporting tool bought for one team may gradually be adopted by other teams, then embedded in pricing, then relied on for client reporting, until withdrawing it would disrupt several services at once. No single decision made it critical; a series of small, sensible adoptions did. Drift is hard to spot from a single contract, because each adoption looks minor in isolation. It becomes visible only when dependencies are viewed across services, which is why service mapping and the register matter. A periodic review that asks how widely a provider is now used can catch drift before it becomes entrenched.

Signals of growing criticality include use by additional services, holding data or code that cannot easily be rebuilt, a shrinking pool of alternatives, and a provider's own growth into adjacent functions that the entity then adopts. Another signal is the cost of exit rising over time, as data volumes grow and integrations deepen. None of those signals alone proves criticality, but together they describe a dependency that is becoming harder to replace. The judgement should be recorded with reasons, so that a later reader can see why a provider moved from routine to important, and what changed in the underlying facts.

Reassessment should trigger a fresh look at the whole chain for that provider, not merely a change of label. Due diligence may need updating to reflect the larger role, contract terms may need strengthening around audit, reporting, incident cooperation and exit, and oversight may need to deepen. The service owners affected should be involved, since they now share a dependency they may not have chosen together. Reassessment is also a moment to challenge the dependency itself: could the function be split, could an alternative be developed, or could the service be redesigned to reduce reliance? Those questions are easier to ask at reassessment than during a crisis.

Contingency for a critical supplier focuses on continuity if the provider fails or becomes unavailable. That may include a fallback process, a manual workaround for a limited period, data held in a form that supports migration, or a plan to move to an alternative provider. Contingency does not need to replicate the provider fully; it needs to keep the most important aspects of the service running or to restore them within the service's tolerance. Testing contingency in discussion, and checking that the data and knowledge needed for it actually exist, separates a plan that could work from a plan that merely describes working. The exit guide develops the longer move; contingency covers the immediate period after a failure.

Senior attention changes because a critical provider is no longer a procurement matter alone; it is a service risk that belongs in wider risk discussion. Senior managers need to understand the dependency, the concentration it creates, the contingency available, and the cost and difficulty of exit. That understanding supports better decisions about growth, investment and risk appetite, such as whether to accept further concentration or to invest in reducing it. Without that attention, criticality can grow silently until a failure forces it into view, at which point the options available are fewer and more expensive than they would have been earlier.