DORA entered application on 17 January 2025. Supervisory reviews of ICT third-party risk management are now underway across the EU financial sector. The register of information — mandated under Article 28(3) of Regulation EU 2022/2554 — is one of the first documents a competent authority will request.
Most firms have something they call a "vendor register." Article 28 requires something more specific: a structured, always-current record of every contractual arrangement for ICT services, maintained at entity level and at sub-consolidated and consolidated levels, with a clear distinction between arrangements that cover critical or important functions and those that do not.
This article walks through what Article 28 actually says, what the implementing technical standards add, and what a supervisory inspection will look for.
What is the DORA ICT Third-Party Risk Register and who must maintain it?
Article 28(3) of DORA uses the term "register of information" rather than "vendor register" deliberately. It covers all contractual arrangements on the use of ICT services provided by ICT third-party service providers — not just the ones you have classified as critical.
The obligation applies to financial entities as defined under Article 2 of DORA: credit institutions, payment institutions, account information service providers, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, management companies, data reporting service providers, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, statutory auditors and audit firms, administrators of critical benchmarks, crowdfunding service providers, and securitisation repositories.
Microenterprises — as defined under EU Commission Recommendation 2003/361/EC — are subject to a simplified regime under Article 16(1) of DORA. They must maintain the register, but certain obligations around ICT third-party risk strategy and the full scope of pre-contractual due diligence are proportionally adjusted.
For all other financial entities, Article 28(3) is unconditional: the register must exist, must cover all ICT contractual arrangements, and must be available to the competent authority on request.
The maintenance obligation runs at three levels simultaneously: individual entity level, sub-consolidated level, and consolidated level where applicable. A group compliance team cannot substitute for entity-level maintenance — both are required.
Which ICT providers must be included — and which are out of scope?
The register covers all ICT third-party service providers with whom the financial entity has a contractual arrangement for ICT services. Article 28 does not provide a materiality floor for inclusion. If there is a contractual arrangement for ICT services, it belongs in the register.
The critical distinction Article 28(3) requires you to draw is not about inclusion but about classification: arrangements covering ICT services that support critical or important functions must be distinguished from those that do not. This is a documentation requirement that runs through every entry in the register.
What counts as a "critical or important function" is defined in Article 3(22) of DORA: a function whose disruption would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the continued compliance with the conditions and obligations of its authorisation, or its other obligations under applicable financial services law.
The pre-contractual assessment required under Article 28(4)(a) — whether the arrangement covers a critical or important function — feeds directly into the register classification. That assessment must happen before contract signature, not retrospectively.
ICT intra-group service providers are not excluded from the scope of Article 28. They appear in the register. The carve-out in Article 31(8)(iii) relates only to the critical third-party provider designation process run by the ESAs — it does not remove intra-group providers from a financial entity's own register obligation.
What data fields does the register need to capture per Article 28?
Article 28(9) delegates to the ESAs — through the Joint Committee — the development of implementing technical standards (ITS) establishing the standard templates for the register. Those ITS lock in the specific data fields that apply to all contractual arrangements.
The Article 28 text itself sets the structural baseline: the register must capture all contractual arrangements and must distinguish those covering critical or important functions from those that do not. The ITS layer adds mandatory data fields that generic vendor management templates do not contain.
From the structure Article 28 requires and the pre-contractual obligations in Article 28(4), your register must be able to demonstrate:
For every arrangement:
- Identification of the ICT third-party service provider
- The ICT services and functions being provided
- Classification: whether the arrangement covers critical or important functions
For arrangements covering critical or important functions, additional depth is required by the pre-contractual assessment obligations in Article 28(4):
- Whether supervisory conditions for contracting were assessed as met
- The concentration risk assessment outcome required under Article 28(4)(c), cross-referenced to Article 29
- Due diligence findings on the ICT third-party service provider
- Conflict-of-interest identification and assessment
The register also feeds the annual reporting obligation under Article 28(3): financial entities must report at least yearly to competent authorities on the number of new arrangements, categories of ICT third-party service providers, types of contractual arrangements, and the ICT services and functions being provided.
The ITS templates developed by EBA, ESMA, and EIOPA under Article 28(9) standardise the field structure for that reporting. Firms using proprietary spreadsheet templates that predate the ITS should validate their field coverage against the published standards — gaps will be visible in the supervisory report.
How does the register connect to your contractual obligations under DORA?
The register is not a passive inventory. It is the operational backbone for several active obligations that Article 28 places on financial entities throughout the contract lifecycle.
Article 28(3) requires financial entities to inform the competent authority in a timely manner about any planned contractual arrangement covering critical or important functions, and also when a function becomes critical or important under an existing arrangement. This is a forward-looking notification obligation, not just a retrospective record. The register must be live enough to trigger that notification process.
Article 28(4) requires pre-contractual assessment before any new arrangement is concluded. The register entry for a new provider should be partially populated at the assessment stage — the classification, the concentration risk analysis, and the due diligence outcome — before the contract executes.
Article 28(5) requires that financial entities only enter arrangements with providers that comply with appropriate information security standards. For critical or important functions, the standard rises: financial entities must take due consideration of the use of the most up-to-date and highest quality information security standards. The register should capture the basis for that assessment, so you can demonstrate compliance on request.
Article 28(7) requires that contractual arrangements include termination rights in four specified circumstances: significant regulatory or contractual breach by the provider; material changes affecting the arrangement or the provider's situation; evidenced weaknesses in the provider's ICT risk management; and situations where the competent authority can no longer effectively supervise the financial entity as a result of the arrangement. Your register should record whether each arrangement includes these termination clauses — and the monitoring status that would trigger them.
Article 28(8) requires exit strategies for arrangements covering critical or important functions. These must be documented, tested, and periodically reviewed. The register entry for each critical-function arrangement is the natural anchor point for linking to the corresponding exit plan.
What does 'critical ICT third-party provider' status change about your register entries?
"Critical ICT third-party provider" (CTPP) is a designation made at EU level by the ESAs under Article 31 — not a classification a financial entity makes unilaterally. The ESAs publish and update yearly the list of CTPPs at Union level under Article 31(9).
When a provider on your register receives CTPP designation, the supervisory stakes on that entry increase. Under Article 31(12), financial entities may only continue to use the services of a third-country CTPP if the provider establishes a subsidiary in the EU within 12 months of designation. If your register does not capture the provider's establishment jurisdiction, you cannot flag this exposure.
CTPP status also affects how the Lead Overseer — the ESA assigned responsibility for that provider — interacts with you. The Lead Overseer has oversight powers over the CTPP itself, including access, inspection, and the ability to issue recommendations. Financial entities are expected to cooperate with oversight exercises. Your register must be accurate enough to support that cooperation.
For your own internal classification — the distinction between critical-function arrangements and non-critical-function arrangements — CTPP designation on a provider is relevant context but not determinative. You may have critical-function arrangements with providers who are not on the CTPP list, and non-critical-function arrangements with providers who are. Both classifications must be maintained on their own basis.
How should financial entities manage register updates when contracts change?
Article 28(3) requires the register to be maintained and updated. This is a continuous obligation, not an annual exercise.
Article 28(3) also requires financial entities to inform competent authorities "in a timely manner" about planned contractual arrangements covering critical or important functions and about functions that become critical or important. The register update must be contemporaneous with the triggering event — a retroactive reconciliation after regulatory inquiry is not timely.
Specific events that should trigger a register update and, where applicable, supervisory notification:
- A new ICT services contract is signed, regardless of criticality classification
- An existing non-critical arrangement becomes critical because the function it supports has grown in importance — Article 28(3) explicitly covers this
- A provider is designated as a CTPP under Article 31
- A material change in the provider's situation occurs that is relevant to the Article 28(7) termination monitoring
- A contract is terminated or substantially modified
- A subcontracting arrangement changes — Article 29(2) requires financial entities to assess whether long or complex subcontracting chains impair their ability to monitor contracted functions
The subcontracting chain is a particularly common gap. Article 29(2) requires financial entities to assess the impact of subcontracting, especially where the ICT subcontractor is established in a third country. This assessment is part of the pre-contractual record for the primary arrangement, and the register entry should reflect the current known depth of the chain.
What will regulators look for when they inspect your register?
Competent authorities have explicit access rights under Article 28(3): financial entities must make available "the full register of information or, as requested, specified sections thereof, along with any information deemed necessary to enable the effective supervision of the financial entity."
There is no materiality filter on that production obligation. The regulator can ask for all of it.
Based on what Article 28 actually requires, a supervisory inspection is likely to probe:
Completeness. Is every ICT contractual arrangement present, including cloud services, data analytics providers, payment processing, custody platforms, and operational technology suppliers that have ICT components? Missing entries are the most common gap — firms tend to populate registers with financial-critical vendors and omit infrastructure and ancillary services providers.
Classification accuracy. Has the critical/important function determination been made consistently, using the Article 3(22) definition, and documented at the pre-contractual stage? Retroactive re-classification — where a firm argues that something it previously categorised as non-critical should be treated as such after the fact — will not satisfy a supervisor who expected the assessment to happen before the contract executed.
Concentration risk documentation. Article 28(4)(c) requires financial entities to identify and assess whether a contractual arrangement may contribute to reinforcing ICT concentration risk as referred to in Article 29. Article 29(1) defines the two concentration scenarios: contracting a provider that is not easily substitutable, and having multiple arrangements with the same or closely connected providers for critical or important functions. The register entry must show this assessment was done.
Exit plan linkage. For critical-function arrangements, Article 28(8) requires exit plans that are comprehensive, documented, tested, and periodically reviewed. Supervisors will expect to be able to trace from a register entry to the corresponding exit plan — and to see evidence of testing.
Annual reporting alignment. The Article 28(3) annual report to competent authorities must be consistent with the register. Discrepancies between reported counts and the register contents signal a process problem.
Timeliness of notifications. If a function became critical or important during the review period, when was the competent authority notified? Late notification is a standalone compliance failure under Article 28(3).
The ICT concentration risk assessment is also aggregated upward. Under Article 31(10), competent authorities transmit the Article 28(3) annual reports to the Oversight Forum, which uses them to assess ICT third-party dependencies across the financial sector. Your register accuracy contributes directly to that macro-level supervisory picture.
FAQ: ICT Third-Party Risk Register under DORA
Does every ICT supplier need to be in the register, or only those supporting critical functions?
All ICT third-party service providers with whom the financial entity has a contractual arrangement must be in the register. Article 28(3) does not limit scope to critical-function providers. The critical/important function distinction affects the depth of documentation and the additional obligations that attach — not whether the provider appears in the register at all.
Does the register obligation apply to microenterprises?
Yes, but on a simplified basis. Article 16(1) of DORA provides a lighter-touch ICT risk management framework for microenterprises. The register obligation itself is not eliminated, but the full scope of pre-contractual due diligence and the strategy requirements under Article 28(2) apply proportionately. Check Article 16 and the accompanying RTS for the specific derogations.
What happens when one of our ICT providers is designated as a critical ICT third-party service provider by the ESAs?
You need to update your register entry for that provider to reflect the designation. If the provider is established in a third country, Article 31(12) requires them to establish an EU subsidiary within 12 months of designation — financial entities relying on that provider need to monitor this timeline. You also gain a direct stake in the ESA Lead Overseer's supervision of the provider, and your register data may be referenced in oversight exercises.
How often must the register be updated?
Article 28(3) requires maintenance and update at entity level, sub-consolidated and consolidated levels, but does not specify a fixed review cycle. Updates should be triggered by material events: new contracts, function criticality changes, provider designation changes, material changes in provider situation, and subcontracting structure changes. Annual reporting to competent authorities under Article 28(3) creates a natural forcing function, but the underlying register must be current throughout the year to support timely supervisory notification.
Aegis GRC maps your third-party obligations to the exact DORA articles that apply — and tracks them as your contract portfolio changes. See how at aegis-grc.com/solutions/financial-services, or explore the platform and single-company views.
Every obligation traced to a verbatim quote from the legal text. No AI hallucinations. A posture you can defend in front of a regulator, a board, or a plaintiff.
