Important Services and Outsourced Services

Outsourcing a task does not outsource the service. When a firm uses a supplier, processor, cloud platform, or specialist handler to deliver part of an important service, the service remains the firms service in the eyes of its customers, and the harm from its failure remains harm to those customers. Identification must therefore follow the service across the boundary of the firm, naming the outsourced parts, the providers that run them, and the points at which a provider failure would block, corrupt, or delay the user outcome. A payment processor outage, a cloud platform failure, a claims handler that cannot be reached, or a data provider that stops updating can each become a service failure for the firm, even though the firms own systems are running. The question for identification is not who operates a component, but whose customers would be harmed if it stopped.

Mapping an outsourced service starts with the same user outcome as any service, then traces each step to the party that performs it. Some steps will be performed in house, some by a direct supplier, and some by a supplier of a supplier, whose existence the firm may only discover by asking. Each outsourced step should be named, with the provider, the function performed, and the consequence if that function fails, is delayed, or returns wrong results. Concentration deserves particular attention: a single provider supporting several services, or several providers relying on the same underlying platform, creates a common point of failure that a service by service map might miss. The map should also show the firms retained capability, such as the ability to monitor the provider, to communicate with customers during a provider outage, and to operate a workaround, because those retained capabilities determine how much harm a provider failure actually causes.

The firm retains responsibility for identifying the service, for setting its tolerance, for understanding its dependencies, and for recovering the user outcome when a provider fails. A contract can allocate tasks, set service levels, and require cooperation during incidents, but it cannot transfer the customer relationship or the harm that customers experience. That retained responsibility has practical consequences for identification: a service cannot be excluded from the list merely because a supplier runs it, and a service cannot be treated as resilient merely because a supplier asserts that it is. The firm needs its own understanding of the provider chain, its own testing that includes provider failure scenarios, and its own recovery and communication plans for a provider outage.

Services provided by another company in the same group raise a similar issue in a quieter form. Because the provider is familiar and internal governance may feel sufficient, the dependency can be under mapped, with no clear owner, no agreed recovery order, and no rehearsal of what happens if the group provider fails or is itself disrupted. The harm test does not distinguish between an external supplier and a group company: if the group providers failure would harm the firms customers, the service is important and the dependency must be mapped with the same care. Shared group platforms, group data centres, and group service centres are therefore worth explicit attention in the inventory, with ownership and recovery responsibilities stated rather than assumed from group membership.

A common mistake is to stop the map at the firms boundary, listing a supplier as a single box without understanding what it does, what it depends on, or how its failure would manifest to users. Another is to confuse a suppliers resilience claim with the firms resilience, without testing provider failure as a scenario in its own right. A third is to overlook fourth parties, the providers behind the provider, until an incident reveals them. A fourth is to treat outsourcing as a reason to set a looser tolerance, on the assumption that the provider will recover, rather than setting the tolerance from user harm and then asking whether the provider arrangement can meet it. Each mistake shifts attention from the user outcome to the commercial arrangement, which is the opposite direction from the harm test.

Check an outsourced service list by choosing a provider and failing it in a rehearsal. Ask which services would be affected, what customers would experience, how the firm would know, how it would communicate, and what workaround exists if the provider cannot recover promptly. If any answer depends on information the firm does not hold, or on a provider action the firm cannot verify, the identification work is incomplete. Check also whether the list shows concentration, so that a single provider failure affecting many services is visible as one risk rather than scattered across many service entries. This guide is educational only; the EU regime under DORA and the UK regime are labelled separately.