Outsourcing vs ICT Third Party Services

DORA treats ICT third party services as the wider category and outsourcing as a narrower arrangement inside it. An ICT third party service is a service supplied by an outside party that supports a financial entity's ICT functions, while outsourcing describes an arrangement under which a function that would otherwise be performed by the firm is performed by another party on its behalf. Every outsourcing of an ICT function is therefore an ICT third party service, but not every ICT third party service is outsourcing. The distinction matters because DORA's provisions on ICT third party risk apply across the wider category, while the outsourcing character of an arrangement affects how governance, contractual terms, and oversight are framed. Labelling an arrangement loosely, or copying a label from a vendor brochure, can leave a firm applying the wrong expectations to a dependency that matters to a service.

Consider an account opening service that relies on an external identity checking tool, a hosted document store, and a provider that operates part of the onboarding workflow on the firm's behalf. The identity tool may be bought as a standard product, used through an interface, and configured by the firm, without the provider performing a firm function in the firm's name. The workflow operator, by contrast, carries out steps the firm would otherwise carry out itself, following the firm's rules and handling cases that affect applicants directly. Both arrangements create dependence, and both sit within DORA's ICT third party risk provisions, but they raise different questions about instruction, supervision, audit, and exit. Treating them as identical because both involve an outside party would hide those differences at exactly the point where a disruption or a supervisory question would expose them.

Classification is not a filing exercise. It determines which questions a firm asks before signing, what the contract needs to say, and what oversight looks like while the arrangement runs. For an outsourced function, the firm needs clarity about instructions, quality expectations, access for monitoring, and the handling of sub-contracted work, because the function is being performed for the firm rather than merely supplied to it. For a standard ICT service, the emphasis may fall more on configuration, integration, data flows, and the resilience of the interface between the firm's systems and the provider's product. In both cases the firm retains responsibility for the service that depends on the arrangement. Classification shapes the route to meeting that responsibility; it does not reduce it.

A practical approach begins with the function, not the contract title. The firm asks what the outside party actually does, whether that activity would otherwise sit inside the firm, how much discretion the party exercises, and how directly its work affects customers or the firm's records. It also asks whether the party can change the service, its hosting, or its own suppliers without the firm's knowledge, and what notice and consent arrangements govern such changes. Those answers, recorded with reasons, give the classification a basis that can be revisited when the arrangement changes. A classification recorded without reasons is fragile, because a product update, a scope change, or a new use of the same provider can shift the arrangement across the boundary without anyone noticing.

Common errors follow a pattern. A firm may classify by vendor category, calling every cloud product outsourcing or every managed service a mere purchase, without examining the function performed. It may classify once at procurement and never revisit the decision, even as usage spreads to a critical service. It may also allow different teams to classify the same provider differently, so that one service treats a provider as a peripheral supplier while another treats the same provider as the operator of a core workflow. Each error has the same consequence: the governance, contract, and evidence built around the arrangement fit a different arrangement from the one actually in place. When a disruption arrives, the mismatch appears as confusion about who decides, who acts, and who can be asked for information.

The evidence for a sound classification is modest but specific: a description of the function performed, the reasons for the category chosen, the services that depend on the arrangement, and the date the classification was last reviewed. That record supports later work in this cluster, including due diligence, risk assessment, governance, and contract drafting, because each of those activities depends on knowing what kind of arrangement is being governed. It also supports a conversation with a supervisor, who will be interested less in the label chosen and more in whether the firm understood the arrangement and acted consistently with that understanding. A label that is explained and applied consistently is useful. A label that is asserted and then ignored is not.