Outsourcing and Cloud Dependencies

Outsourcing and cloud dependencies describe a position under DORA that is easy to state and harder to evidence. A financial entity that moves a system to a cloud provider or an outsourcer keeps responsibility for the service that system supports. The provider supplies capacity, tooling, or operations, while the firm keeps ownership of the tolerance for that service, the sequence for recovering it after a disruption, and the answer it gives to its regulator when recovery is examined. DORA, the EU regulation on digital operational resilience for the financial sector, treats that retained responsibility as the starting point for managing ICT third party risk. A contract, a service dashboard, or a provider assurance statement does not transfer it. What matters is whether the firm can show, for a named service, how the provider will support tolerance and recovery in a disruption that affects that service in particular.

Responsibility stays with the firm because customers, counterparties, and supervisors deal with the firm, not with its supply chain. When a payment cannot be made, a balance cannot be seen, or a claim cannot be settled, the harm is experienced through the firm's service, even if the failing component belongs to a provider. DORA reflects that reality in its provisions on ICT third party risk, which ask the financial entity to understand its dependencies, to govern them, and to be able to explain them. Outsourcing changes who performs a task. It does not change who answers for the outcome of the service, and it does not turn a provider's general assurances into service-specific evidence. A firm that cannot describe the link between a provider and a named service has a governance gap, not merely a documentation gap, because the decisions taken during a disruption will depend on that link.

The recurring pitfall in this cluster is a contract that promises availability in general terms and says nothing about the specific service, its tolerance, and its recovery sequence. General availability language can describe a platform, a region, or a product family, while saying little about the one service that matters in a disruption. A lending service, for example, may depend on a credit decision component, a document store, and a notification channel, each hosted or operated differently. If the contract does not say which of those components supports that service, what recovery order applies when more than one fails, and what the firm will be told while recovery is under way, the firm holds a promise without a plan. Availability measured across a provider estate is not the same as recovery of a named service, and the difference only becomes visible when the service stops.

Mapping starts from the service and works outward, rather than starting from a vendor list and working inward. The firm names the service, describes what a user experiences when it works, and then traces the systems, data flows, and provider functions that produce that experience. Each link in that trace raises a practical question: if this link fails, what breaks, what degrades, and what can continue in a reduced form. A map that stops at the name of a provider is incomplete, because a provider name does not explain which function, which data, and which recovery step belongs to the service. The map is a working tool for decisions during a disruption, not a diagram kept for examination.

Tolerance states what disruption a service can absorb before harm becomes intolerable, expressed in terms the disruption itself produces, such as users unable to complete a transaction or records unavailable for reconciliation. Recovery is the ordered sequence that brings the service back, including the provider steps, the firm steps, and the communication that runs alongside them. Evidence is the record that the sequence was understood before the disruption, tested in conditions resembling it, and followed or consciously adapted when it happened. DORA brings these elements together through its provisions on ICT risk management, incident handling, testing, and third party oversight, so that a firm can show a coherent story for a service rather than a collection of unrelated controls.

The supporting guides in this cluster each take one part of that story and examine it closely. Some deal with distinctions, such as the difference between outsourcing and ICT third party services in DORA, or between a service level and a tolerance. Others deal with structure, such as regions, availability zones, multi-cloud arrangements, and group entities. A further group deals with the life of the arrangement: due diligence, risk assessment, governance, contract change, renewal, data location, incident responsibility, shared responsibility, exit, and regulatory access. Where any answer is vague, that vagueness is the work to be done.