ICT Third-Party Risk Management

ICT third-party risk management under DORA means treating a supplier as part of the service, not as something outside it. When a financial entity relies on an ICT provider for a function that supports an important service, a failure at the provider can interrupt that service just as directly as a failure inside the entity itself. DORA therefore expects the entity to understand the dependency before it signs, to contract for access, security and cooperation, to oversee the arrangement while it runs, and to keep a workable exit route open. Responsibility stays with the financial entity throughout, even where day-to-day operation sits with the provider.

A chain is a useful way to picture this topic because a weakness at any stage tends to surface at a later one. A provider chosen mainly on price may prove hard to oversee if its reporting is thin, and a contract without audit or exit terms may leave the entity with little leverage when performance slips. Conversely, careful selection makes contracting easier, because the questions that matter have already been asked, and steady oversight makes exit less disruptive, because the entity already knows what the provider holds and how the service could move. The supporting guides in this cluster follow that order for a reason, and each one returns to the same test: does this step make the service easier to run, to evidence, and to leave?

Not every supplier carries the same weight, and DORA-related practice draws a distinction between routine purchases and providers that support functions which are difficult to replace or central to a service. A retail payments illustration helps here. A provider that processes payment instructions sits closer to the customer than a provider that supplies a back-office reporting tool, and an interruption in the first case is felt sooner and more widely. Criticality is therefore judged by the service, not by the size of the invoice. Questions that shape the judgement include how quickly an alternative could be found, whether the provider holds data or code that cannot easily be rebuilt, and whether several services depend on the same provider at once.

The central pitfall in this cluster is oversight that reads a supplier report and calls it assurance without checking what the report actually covers. A report may describe controls across a provider's whole estate, or for a different product, or for a period that has since passed, while the service in question depends on one specific system in one specific location. Assurance comes from matching the evidence to the dependency: which system, which data, which subcontractors, and which period. Where the match is unclear, the honest position is that assurance is partial, and the gap should be recorded and addressed rather than smoothed over in a committee paper.

Governance in this area is less about creating a new committee than about making sure the people who own the service, the contract, the risk picture and the incident response all work from the same facts. The service owner knows what interruption would mean for customers. The contract owner knows what rights the entity actually holds. The risk function knows how the provider fits into the wider register of dependencies. When those views diverge, the entity may discover during an incident that it cannot reach the right person at the provider, cannot obtain the information it needs, or cannot move the service elsewhere. Regular, documented discussion between those owners, grounded in current evidence rather than in last year's assessment, is what keeps the chain from breaking into separate tasks.

A reader new to the topic can start with this pillar, then follow the chain in order: selecting a provider, carrying out due diligence, contracting, overseeing the arrangement, understanding sub-outsourcing, planning exit, handling incident notification, respecting data protection boundaries, benchmarking performance, keeping registers, and recognising when a supplier becomes critical. Each supporting guide stands on its own topic, but none of them is a substitute for the whole chain. The value of reading them together is that a decision made at selection can be checked against its consequences at exit, and a weakness found in oversight can be traced back to a gap in the contract.