Sub-Outsourcing and Fourth Parties

Sub-outsourcing means a provider passes part of its work to another party, creating a chain in which the financial entity may depend on a fourth party it has never met. Under DORA, that chain does not dilute the entity's responsibility. The entity still needs to know which subcontractors support its service, to have contractual protection that flows down the chain, and to be able to assess and, where appropriate, object to changes. A provider that cannot describe its own chain, or that treats subcontracting as an internal matter, leaves the entity dependent on arrangements it cannot see, which is a difficult position to defend when something goes wrong.

A claims platform illustration shows the problem. The entity contracts with a platform provider, which uses a subcontracted analytics service, which in turn stores data with a further provider. An outage or a security event at the furthest point can interrupt claims handling, yet the entity's contract is only with the first provider. Visibility means mapping that chain for the service in question, not merely listing a provider's corporate group. The map should show which subcontractor performs which function, what data it touches, and where it operates, so that an incident anywhere in the chain can be traced to the service it affects.

Control over change typically rests on contract terms agreed before the chain grows. Those terms may require notice of a planned subcontractor change and, for changes affecting the service, an opportunity to assess the new party and to object where the change creates an unacceptable risk. The practical difficulty is timing: notice that arrives after a change has taken effect gives the entity a complaint, not a choice. Oversight should therefore track whether notice arrives early enough to act, and whether objections, where made, are respected in practice rather than merely acknowledged in correspondence.

Flow-down means that obligations agreed with the direct provider also bind the parties behind it, so far as they touch the entity's service. Security duties, confidentiality, audit and access, incident cooperation and data protection obligations are of little use if they stop at the first provider while the work itself is done further down the chain. The entity will rarely contract directly with every fourth party, so it relies on the direct provider to impose equivalent terms and to evidence that it has done so. Asking for that evidence, rather than assuming it exists, is a basic oversight task.

Concentration can hide inside a chain in ways that a direct provider list will not reveal. Several apparently different providers may share the same subcontractor, the same platform, or the same data centre, so that one failure affects them all at once. A register that records only direct providers will miss that pattern entirely. Mapping subcontractors for important services, and looking across services for shared dependencies, is how hidden concentration comes into view. The finding may not lead to immediate change, but it changes how the entity plans for disruption, because it knows that a single event could affect more than one service.

When a link fails, the entity's first need is information: which service is affected, what the failing party does, and what the direct provider is doing about it. That information should flow through the contract and the incident arrangements, not through press reports or customer complaints. After the event, the lesson often concerns visibility rather than technology: the chain was longer than assumed, a subcontractor had changed without notice, or a flow-down term was missing. Recording that lesson and fixing the visibility gap matters more than assigning blame, because the next event is likely to test the same chain again. The review should also check whether other services share the same failing link, since a chain failure rarely affects only one service.