DORA's third-party chapter is where many financial entities found the most new work. Vendor risk management existed before, often under outsourcing guidelines. What DORA added was a single regime covering every ICT service, a register in a prescribed format that supervisors receive, and explicit rules on concentration, exit and termination.
The register is the visible part, and it is tempting to treat it as a procurement export. That approach fails quickly. The register is only as good as the classification of functions behind it and the supplier data feeding it, and both take sustained work.
This article covers the principles in Articles 28 and 29, what the register holds, the assessments due before you sign, and the exit and termination rules. Contract clauses under Article 30 get their own treatment in a separate article.
The principles behind the chapter
Article 28 opens with the rule that frames everything else: a financial entity that uses ICT third-party services remains fully responsible for complying with its obligations under DORA and financial services law. Outsourcing the service does not outsource the accountability.
Entities manage ICT third-party risk as an integral part of their ICT risk management framework, in proportion to the nature, scale, complexity and importance of their ICT dependencies. Entities other than microenterprises must adopt and regularly review a strategy on ICT third-party risk. That strategy includes a policy on the use of ICT services supporting critical or important functions, and the management body reviews the resulting risk profile regularly.
The distinction between critical or important functions and everything else runs through the whole chapter. A function is critical or important when its disruption would materially impair the entity's financial performance, the soundness or continuity of its services, or its continued compliance with its authorization. Classify functions first. Every later decision depends on it.
What the register of information is
Article 28(3) requires financial entities to maintain and update a register of information on all contractual arrangements for ICT services provided by ICT third-party service providers. It is kept at entity level and, for groups, at sub-consolidated and consolidated levels. It must distinguish arrangements covering ICT services that support critical or important functions from the rest.
The register has three uses with the competent authority:
On request. The entity makes the full register available when the authority asks.
Yearly reporting. At least once a year, the entity reports information on new arrangements, the categories of providers, the types of arrangements, and the ICT services and functions provided.
Advance notice. The entity informs the authority in a timely manner about any planned arrangement for ICT services supporting critical or important functions, and when a function has become critical or important.
The format is not left to you. Implementing technical standards set the templates. Supervisors also use register data to understand dependencies on providers across the sector, which is one reason the data quality expectations are high.
What goes into the register
In general terms, the templates link together information about:
The financial entities maintaining the register, including the group structure where relevant.
The contractual arrangements, with references, dates, notice periods and governing law.
The ICT third-party service providers, with identifiers such as a legal entity identifier.
The ICT services provided, by type.
The functions each service supports, and whether each is critical or important.
Locations where services are provided and data is stored and processed.
The supply chain for services supporting critical or important functions: the subcontractors that effectively underpin the service.
Assessments of each arrangement, such as substitutability and the feasibility of exit.
Check the current templates for the exact fields. They are detailed, and the detail is where submissions fail.
The supply chain problem
The hardest field to fill is the subcontracting chain. You cannot export it from your procurement system, because it is not your data. Only your provider knows which of its own suppliers support your service. Build the request into onboarding, put an obligation to keep it current into the contract, and expect to chase it.
Assessments due before you sign
Article 28(4) requires the entity, before entering an arrangement, to:
Assess whether the arrangement covers a critical or important function.
Check whether supervisory conditions for contracting are met.
Identify and assess all relevant risks, including whether the arrangement could contribute to ICT concentration risk.
Undertake due diligence on the prospective provider and confirm it is suitable.
Identify and assess conflicts of interest the arrangement may cause.
Entities may only contract with providers that comply with appropriate information security standards. For critical or important functions, they must take due account of the most up-to-date and highest quality information security standards. Due diligence depth should follow risk, the same principle behind tiering vendors by data access.
Article 29 adds the concentration risk assessment. The entity considers whether an arrangement would mean relying on a provider that is not easily substitutable, or holding several arrangements with the same provider or closely connected providers. Where an arrangement allows further subcontracting of a critical or important service to a provider in a third country, the entity also weighs insolvency law in that country and any constraints on recovering data quickly.
Document each assessment as it happens. A pre-contract assessment written after signature is a reconstruction, and it reads like one.
Monitoring, termination and exit
Monitoring continues for the life of the arrangement. Entities set the frequency of audits and inspections, and the areas they cover, based on the risk posed by the provider.
Article 28(7) requires that arrangements can be terminated in four circumstances:
A significant breach by the provider of applicable law, regulation or contractual terms.
Circumstances identified through monitoring that could alter the performance of the functions provided, including material changes affecting the arrangement or the provider's situation.
Evidenced weaknesses in the provider's overall ICT risk management, in particular in how it ensures the availability, authenticity, integrity and confidentiality of data.
Conditions of the arrangement that leave the competent authority unable to effectively supervise the entity.
Article 28(8) requires exit strategies for ICT services supporting critical or important functions. They must be comprehensive, documented, sufficiently tested and periodically reviewed. They identify alternative solutions and transition plans, so the entity can exit without disrupting its business, limiting compliance with regulation, or degrading service to clients.
The test of an exit plan is whether someone could execute it. Name the alternative provider or the in-house option, estimate the migration, and record what data comes back and in what format. A plan that says "we will select an alternative provider" is not a strategy.
Mistakes that show up in register work
Treating the register as a one-off submission. It must be maintained and updated, and the yearly report is a snapshot of something that changes continuously.
Leaving out intra-group providers. ICT services provided by group companies are within the regime.
Classifying functions inconsistently. The same service marked critical by one business unit and not by another will draw questions.
Missing identifiers. Providers without the identifiers the templates expect cause rejected or incomplete records. Request them at onboarding.
Stale subcontractor data. A chain captured at signature and never updated is wrong within a year.
For the view from the other side of the table, see DORA explained for ICT service providers, which covers what providers should have ready. Our DORA framework page summarizes the chapter alongside the rest of the regulation. How these articles apply to your specific arrangements, particularly the classification of functions, is a point to confirm with counsel.
How TrustLynce helps
TrustLynce's third-party risk management keeps the vendor inventory, risk tiers, due diligence reviews and reassessment dates in one place, so register data comes from a maintained record rather than a yearly scramble. Due diligence reviews recorded at the time they happen give you the pre-contract assessment trail.