DORA makes ICT third-party risk part of a financial entity's operational resilience responsibilities. Financial entities must maintain a register of ICT contractual arrangements, assess providers that support critical or important functions, consider concentration and subcontracting risk, and keep evidence that oversight continues after onboarding. DORA has applied since 17 January 2025.
A vendor questionnaire can contribute to the evidence DORA requires, especially for controls and contractual commitments that only a provider can attest to. But the regulatory requirement reaches further, because the financial entity remains responsible for understanding and managing the ICT risk created by the services it uses.
What DORA requires on third-party ICT risk
Under DORA, financial entities must manage ICT third-party risk as part of their ICT risk management framework, maintain information on contractual arrangements with ICT providers, perform due diligence before contracting, monitor relevant arrangements, assess concentration and subcontracting risk, and preserve contractual rights that support oversight and resilience.
DORA is Regulation (EU) 2022/2554. It applies to a broad set of EU financial entities listed in Article 2, including credit institutions, payment institutions, investment firms, insurers, crypto-asset service providers and other regulated financial-sector entities. ICT third-party service providers also sit within the Regulation's scope for the relevant provisions. The Regulation has applied since 17 January 2025 under Article 64.
The core third-party risk framework sits in Article 28. It requires financial entities to manage ICT third-party risk as an integral component of ICT risk management and makes clear that using an ICT provider does not transfer the financial entity's regulatory responsibility.
In practice, that creates an evidence problem as much as a policy problem. A financial entity needs to know which services it relies on, which functions those services support, which arrangements are critical or important, and whether the risk picture has changed since the contract was signed.
Yet many organisations don't have a complete picture.
The register of information and what it demands
DORA Article 28(3) requires financial entities to maintain and update a register of information covering their contractual arrangements for ICT services. The register must distinguish services that support critical or important functions, and it must be available to competent authorities.
The register is more structured than a supplier spreadsheet. The standard templates were established by Commission Implementing Regulation (EU) 2024/2956, which turns the register into a defined data model rather than a free-form inventory.
The implementing standard defines an ICT service supply chain as the sequence of contractual arrangements connected with an ICT service. It also introduces provider ranks: the direct provider is rank 1, while subcontractors sit at higher ranks. That structure matters because the register is intended to represent dependencies as well as contract names.
A useful readiness check is whether the organisation can connect each relevant arrangement to the financial entity using the service, the ICT service provided, the function it supports, the provider, and the parts of the supply chain that need to be recorded under the applicable templates. Legal and compliance teams still need to determine the exact reporting scope for their entity and group structure.
Which third-party dependencies must you be able to evidence?
DORA expects financial entities to understand the ICT services they use and to identify which arrangements support critical or important functions. The evidence needs enough relationship context to show what the provider supports, where the dependency sits, and why disruption could matter to the financial entity.
This is where a flat vendor inventory becomes limiting. Knowing that a contract exists does not tell a risk team which digital service relies on it, which business function depends on that service, or whether the same provider appears elsewhere in the environment.
Article 28 requires assessment before a contractual arrangement is concluded, including whether the arrangement covers ICT services supporting a critical or important function. Article 30 then requires key contractual provisions such as a clear description of the functions and ICT services, the locations where services and data are handled, and conditions for permitted subcontracting of services supporting critical or important functions.
The practical depth therefore depends on the service and its criticality. The closer a provider or subcontractor sits to an important function, the stronger the case for traceable dependency evidence, ownership and ongoing monitoring.
Where fourth parties and subcontracting chains enter the requirement
DORA reaches into subcontracting chains when an ICT provider subcontracts services that support a critical or important function. Financial entities must assess the risks created by that subcontracting and consider whether long or complex chains could weaken their ability to monitor the contracted function.
This requirement appears in Article 29, which specifically addresses subcontracting of ICT services supporting critical or important functions and asks financial entities to consider the effect of potentially long or complex subcontracting chains on effective monitoring and supervision.
That does not mean every nth-party relationship in the global technology ecosystem must be mapped without limit. The regulatory focus is tied to the ICT services and functions in scope, with deeper scrutiny where subcontracting supports critical or important functions.
For security teams, the useful operational question is: which indirect providers can materially affect the service we rely on, and can we produce evidence of that dependency when asked?
Concentration risk under DORA
DORA requires financial entities to assess ICT concentration risk before entering relevant arrangements, including the risk of depending on providers that are difficult to substitute and the risk created by multiple critical or important services relying on the same provider or closely connected providers.
Under Article 29, the assessment includes the degree of substitutability of the provider and whether multiple contractual arrangements supporting critical or important functions depend on the same ICT third-party provider or closely connected providers.
Concentration can also be hidden below the contract layer. Two apparently separate suppliers may rely on the same cloud, identity, network or infrastructure provider. Procurement records can show two vendors while the operational dependency still converges on one underlying service.
A relationship map makes that pattern easier to investigate because it can connect suppliers to shared infrastructure and show where several services depend on the same external component. The regulatory conclusion still belongs to the financial entity; the map supplies evidence for that analysis.
How supply chain intelligence supports the evidence
Supply chain intelligence can support DORA by adding continuous external evidence to the contractual and governance records already maintained by the financial entity. It can help discover supplier relationships, map observable dependencies, monitor changes and preserve evidence that supports ongoing third-party risk decisions.
ThingsRecon Supply Chain Intelligence is designed to provide that external relationship layer. It maps observable suppliers, assets, and dependencies and keeps the evidence behind those relationships available for validation.
That can strengthen DORA evidence in three practical ways:
This evidence can sit alongside questionnaires, contracts, and internal records. The same hybrid approach is covered in Are vendor questionnaires enough for regulatory compliance? and in our guide to choosing a third-party risk tool for DORA and NIS2.
External discovery cannot establish every contractual fact, internal control or data-processing arrangement. Those still require internal records and provider assurance. Its value is in giving teams another evidence source for the digital relationships that can be observed from outside.
Common gaps in a first DORA readiness pass
The most common DORA gaps appear when the register, contracts and operational reality do not line up. An organisation may have a supplier list without a clear link to critical functions, know the direct provider without enough subcontracting context, or document a review without evidence of what changed between reviews.
These gaps do not automatically mean non-compliance. They are signals that the evidence needed to demonstrate effective oversight may be difficult to assemble when a regulator, auditor or incident team asks for it.
DORA third-party ICT risk: evidence comparison
A DORA readiness checklist for third-party ICT risk
A defensible DORA programme should be able to show who provides ICT services, which functions those services support, which relationships are critical or important, how subcontracting and concentration have been assessed, what the contracts require, and how risk is monitored over time.
A platform can support those activities with discovery, mapping and evidence. Compliance still depends on the organisation's governance, contractual decisions, risk assessments, controls and supervisory obligations.
