DORA and the register of information: your vendor list is now a regulated filing¶
Article 28(3) is one line in the regulation and a quarter of the implementation effort in practice. It requires a register of information of all your ICT third-party arrangements. ITS 2024/2956 turns that line into a structured, machine-readable filing with a fixed template set. Today, what the register is and why it consumed so many teams in 2025.
The one-line obligation¶
Article 28(3) says entities shall "maintain and update a register of information with all contractual arrangements about the use of ICT services provided by ICT third-party service providers". Simple to state. The difficulty is that it demands you know, precisely and in a defined format, every ICT service you consume, which function each supports, where the data sits, and how the arrangements interlink, including subcontracting chains.
Most organisations discovered in 2025 that they did not have this. Procurement had part of it, IT had part of it, risk had a spreadsheet that was already out of date. The register forces all of that into one authoritative, current picture.
The ITS makes it a filing, not a spreadsheet¶
ITS 2024/2956 defines the structure: a set of 15 interlinked templates covering the entity, the providers, the contractual arrangements, the ICT services, the functions and assets supported, and the service chains. They are interlinked by design, so a provider referenced in one template has to reconcile with the arrangements and functions in others. This is why a loose spreadsheet does not survive contact with the ITS. The register is relational.
The EBA, as the ESAs' technical provider, publishes the full reporting package: the templates, the data point model, validation rules, taxonomy and sample files, the same package firms used for the 2025 submissions. This is the "here is what DORA demands, here is the official tool" pairing at its clearest, and both the ITS and the EBA package are on the resources page.
Where the register connects¶
The register is not a standalone chore. It is the formalised output of your Article 8(5) mapping of third-party dependencies, and it is the data source for the incident-origin analysis that made Chapter V necessary. Build Article 8 well and the register is a reformatting exercise. Build Article 8 badly and the register is where the gaps become visible to your supervisor.
The artefact: register readiness check¶
Before you touch the ITS templates, can you answer these from one source?
| Question | Register layer |
|---|---|
| Every ICT provider you use, uniquely identified | Provider templates |
| Every contractual arrangement, current | Arrangement templates |
| Which function each ICT service supports | Function and service templates |
| Which arrangements support critical or important functions | Flagged across templates |
| Subcontracting chains for critical services | Service chain templates |
| Data and processing locations | Arrangement detail |
If any row lives in someone's head or a stale file, that is your register project. The ITS 2024/2956 text and the EBA reporting package are linked from the DORA resource library.
Next in this series: the finale, oversight of critical ICT third-party providers, and DORA on one page.