DORA's third-party requirements are the area that creates the most operational confusion. Not because the requirements are unclear, but because they assume a continuity of work that most organisations are not used to.
What counts as an ICT provider under DORA?
DORA applies to all contractual arrangements with third-party ICT service providers — not just the obvious ones, such as cloud services and data centres, but also software vendors, telecoms operators, and in some cases subcontractors further down the supply chain.
What determines how rigorously a provider needs to be managed is whether the service supports a critical or important function within the organisation. That classification is not trivial. It directly affects which contractual requirements apply, how thorough the due diligence needs to be, and how the provider must be handled in the register of information.
A common misconception is that the classification is a one-off assessment. In practice, it needs to be reviewed on an ongoing basis — a provider that previously handled a support process can become critical if the organisation's dependency on that service changes.
The register of information: a living document, not an annual report
DORA requires financial entities to establish and maintain a register of all contracted ICT services — the register of information (RoI). The register must include details about the provider's identity, the services delivered, which functions within the organisation are affected, and whether the service is classified as critical or important.
This is where system design matters. The register needs to be a living document, not a file updated ahead of the annual submission. That requires updates to be triggered automatically by contract lifecycle events — new agreements, renewals, amendments — and clear ownership of each record.
In practice, this is a data quality problem as much as a compliance problem. The register involves multiple departments: procurement, IT, legal, risk. Without a structured process for collection and validation, it quickly becomes inconsistent.
Concentration risk: what supervisors are actually looking for
DORA explicitly addresses concentration risk — the risk that an organisation is overly dependent on a small number of ICT providers, or that the financial sector as a whole relies on the same critical players.
At the organisational level, this means financial entities need to map their dependencies and demonstrate that they understand where concentrations exist. Having a list of providers is not enough. Supervisors want to see that the organisation actively analyses what happens if a critical provider fails.
This is an area where supervisory authorities have not yet provided complete guidance on exactly how the assessment should be documented. The practical starting point is to map which providers support critical functions and analyse substitutability — how quickly and at what cost could the service be replaced?
Continuous monitoring versus periodic review
Misconception: DORA requires a thorough supplier review once a year.
Reality: DORA requires ongoing monitoring of third-party providers. That means changes in a provider's security posture, financial stability, or subcontracting structure need to be picked up continuously — not at the next scheduled review.
That places demands on how the organisation collects and processes information about its providers. Manual processes do not hold up. A provider that suffers a security breach today may be relevant to DORA's incident reporting requirements by tomorrow.
Exit strategies: a requirement that is consistently underestimated
For services supporting critical or important functions, DORA requires organisations to have a credible exit strategy in place. That means a documented plan for how the service can be terminated or migrated if the provider fails, if quality deteriorates, or if the contract is terminated.
An exit strategy that exists only on paper does not meet the requirement. Supervisors expect the plan to be operationally viable — that the organisation can actually execute it within a reasonable timeframe without critical functions being disrupted.
What this means for how the work is organised
Third-party management under DORA is not a project with an end date. It is an ongoing governance programme that requires clear ownership, integrated processes, and documentation that holds up under supervisory scrutiny.
The most common problem is not that organisations lack information about their providers — it is that the information is scattered across contracts, spreadsheets, and email threads without a coherent structure. That structure is what DORA requires.
Next steps with Hy5
Does your organisation need a structured approach to DORA's third-party requirements?
Hy5 maintains your register of information continuously and connects supplier dependencies directly to your critical functions and compliance status. Used by financial organisations to operationalise DORA without manual administration.
Hy5 dramatically increases speed and reliability in compliance work. Across the entire company.
