Governance for ICT Third-Party Risk
Governance for ICT third-party risk under DORA keeps the management body in control of services run partly outside the entity. This guide explains oversight of providers, concentration and exit.
The short answer
Many financial services depend on external providers for hosting, software, data, communications or processing. Under DORA, the management body must oversee that dependence as part of ICT risk governance, even though the provider operates outside the entity. Oversight means understanding which services depend on which providers, what would happen if a provider failed or degraded, and how the entity would continue or recover. A contract alone does not provide that understanding.
Governance of third party risk therefore combines several kinds of work: assessing providers before and during a relationship, monitoring their performance and risk, understanding concentration where several services share a provider, and planning for exit or replacement. The board question throughout is service based. It is not whether a provider is generally reputable, but whether the entity could still serve its customers if that provider could not.
How should the board see provider dependencies?
The board should see provider dependencies mapped to services, not merely listed as contracts. A list of providers tells the board who is paid. A service map tells the board what breaks if a provider breaks. That distinction matters most for providers that support several services at once, where a single failure can cascade across customer journeys that appear unrelated in an organisational chart.
Consider a card payment service that uses one provider for transaction routing and another for fraud screening. If the fraud screening provider degrades, transactions may be delayed or declined, even though routing itself is healthy. A service map makes that interaction visible, while a contract list may present the two providers as separate, low risk items. Governance reporting should therefore show dependencies in service terms, with the customer consequence of each dependency stated plainly.
What do provider assessment and monitoring involve?
Assessment before entering a relationship involves understanding the provider's ability to support the service, its security and resilience arrangements, its subcontractors where relevant, and the entity's rights to information and audit. Monitoring during the relationship involves tracking performance, incidents, changes in the provider's arrangements, and whether assurances remain evidenced. Both stages should be proportionate to the criticality of the service supported, with the closest attention given to providers whose failure would most harm customers.
Assurance from a provider needs careful handling at board level. A provider report or certificate can be useful evidence, but it does not replace the entity's own judgement about its service. The board should understand what an assurance actually covered, whether it addressed the service in question, and whether any limitations or exceptions were noted. Uncritical acceptance of provider assurance is a governance weakness, because it transfers judgement to a party that does not bear responsibility for the financial entity's customers.
Why do concentration and exit belong in governance?
Concentration arises when many services, or many parts of one service, depend on the same provider, the same technology, or the same location. Concentration increases the impact of a single failure, and it can grow quietly as teams adopt the same provider independently. Governance should therefore look across the entity for shared dependencies, rather than only within individual projects. A dependency that looks modest in each project can become material in aggregate.
Which third party decisions reach the board?
Board level decisions on third party risk include approving the approach to managing such risk, approving or noting critical provider relationships, deciding how concentration risk will be addressed, and acting on serious provider findings or incidents. The board should also decide when a provider risk is accepted despite known weaknesses, because acceptance of a material risk is a governance decision that should be owned explicitly, not implied by inaction.
That explicit ownership matters after a provider failure. If the board never discussed a known provider weakness, it cannot show that it weighed the risk. If it discussed the weakness, considered alternatives, and recorded its decision and reasoning, it can show governance even though the outcome was unwelcome. Governance does not promise that providers never fail. It promises that provider risk was understood, discussed and owned before failure, and that the response after failure was directed rather than improvised.
What goes wrong most often in third party governance?
A frequent weakness is treating third party risk as a procurement topic rather than a resilience topic. Procurement focuses on price, service levels and contract terms, all of which matter, but resilience focuses on what happens when the contracted service is unavailable. Governance should bring both lenses together, so that a commercially attractive arrangement is not approved without a resilience assessment of its failure consequences.
Another weakness is fragmented oversight, where each team manages its own providers and no one sees the whole dependency picture. Fragmentation hides concentration and leaves exit planning to individual teams that may lack leverage or information. Central visibility, even in a small entity, helps the management body see the aggregate risk. The record should show that visibility: a service level dependency view, reviewed by the management body, with decisions attached to the risks it reveals.
Primary sources on the record
- Regulation (EU) 2022/2554, EUR-Lex text.
- European Banking Authority, operational resilience pages.
Legal status: Regulation (EU) 2022/2554 in force; applies from 17 January 2025, with technical standards applying on the dates stated in each standard. Application position for this topic: Applies from 17 January 2025. Technical standards apply on their own stated dates.