Selecting ICT Third Parties

Selecting an ICT third party under DORA starts with the service, not with a shortlist of vendors. The financial entity first clarifies what function the provider will perform, how central that function is to an important service, and how hard the function would be to replace. Only then does comparison become meaningful, because a provider that looks strong in general may be weak for this particular dependency. Price, reputation and familiarity all have a place in the discussion, but none of them answers the central question: if this provider stopped performing, what would happen to the service, and how quickly could the entity respond?

A loan origination illustration shows why order matters. Two providers might both offer workflow software, yet one hosts the decision engine and the customer data while the other supplies a document viewer. Treating them as equivalent purchases would misstate the risk in both directions, overstating the viewer and understating the engine. Defining the function, the data involved, the systems touched and the customers affected gives selection a factual base. It also prevents a common drift, where a tool bought for a narrow task gradually expands until it supports a much larger part of the service than anyone originally approved.

Fair comparison depends on asking each candidate comparable questions about the same dependency. Those questions typically cover security practices, resilience arrangements, the use of subcontractors, the location of data and operations, financial stability in broad terms, and willingness to accept audit, reporting and exit terms. A provider that answers openly, even where the answer reveals a limitation, gives the entity something it can plan around. A provider that answers only in general terms leaves the entity to guess, and guessing is a poor basis for a dependency that may last for years. Documenting the comparison, including reasons for rejecting a candidate, matters because the decision may later need to be explained.

Concentration asks whether the entity is quietly building a single point of failure. That can happen in several ways: several services relying on one provider, one provider relying on one subcontractor, or many entities in a market relying on the same platform. None of those patterns is automatically wrong, but each one changes the meaning of a failure. Selection is the cheapest moment to notice concentration, because alternatives can still be weighed and the design can still be changed. Once contracts are signed and data has migrated, the same discovery becomes a remediation project rather than a choice.

Exit sounds like a late topic, yet selection is where exit becomes either feasible or painful. A provider whose data formats are open, whose contract allows assistance on departure, and whose service can run in parallel during transition is easier to leave than one whose formats are closed and whose assistance is vague. Asking about exit at selection is not a sign of distrust; it is recognition that services change, providers change, and strategies change. The exit guide in this cluster develops the point, but the leverage to secure a workable exit is greatest before signature, when the provider is still competing for the work.

The selection record should let a later reader reconstruct the decision without relying on memory. That means the service and function, the candidates considered, the criteria used, the evidence relied on, the concentration view, and the reasons for the final choice, including any residual concerns accepted knowingly. A thin record, such as a note that a provider was approved, does not support oversight later, because overseers cannot tell what was checked and what was assumed. A clear record also protects the provider, since expectations agreed at selection are less likely to become disputes during the contract. That record also helps a new owner take over oversight without reconstructing decisions from memory or from scattered correspondence.