Short answer. The register of information is the structured inventory of every ICT third-party arrangement a financial entity holds, required under Article 28(9) of DORA (Regulation (EU) 2022/2554). It uses 15 standard templates fixed by Commission Implementing Regulation (EU) 2024/2956, and EU financial entities first submitted it to their supervisor with a reference date of 30 April 2025. Supervisors use the aggregated registers to map ICT concentration risk across the whole financial sector.
The register of information is a machine-readable dataset rather than a policy document. Every contract with an ICT provider becomes a set of rows with defined fields: cloud hosting, a SaaS core-banking module, a managed security service, a payment processor, an intra-group IT company. If a service touches the entity through a contract, it belongs in the register.
Each row carries specific, checkable data:
The register is maintained at three levels: entity, sub-consolidated, and consolidated. A banking group files a consolidated view plus the entity-level detail beneath it. The reporting format is xBRL-CSV against the EBA Taxonomy 4.0, so the data has to be internally consistent before it is even accepted as a valid submission.
DORA has applied since 17 January 2025 to roughly 20 categories of financial entities: banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, and more. The register is the evidence that an entity actually knows its ICT dependency map. A gap in the register is a gap a supervisor can see, and it points to a control the entity may not have.
The data does not stop at the national competent authority. Registers flow up to the European Supervisory Authorities (EBA, EIOPA, and ESMA), which use the aggregated view to designate Critical ICT Third-Party Providers (CTPPs) for direct EU oversight. For a bank or insurer in Slovakia, the Czech Republic, or Austria, the register connects three concerns a board already tracks: outsourcing governance, cloud concentration, and audit readiness. It turns those concerns into one filed, verifiable artifact.
The register also raises the cost of a stale outsourcing inventory. Many entities entered 2025 with contract data spread across procurement spreadsheets, legal archives, and vendor management tools that never reconciled to each other. DORA forces a single source of truth. The entities that fared best treated the register as a data-governance task with a named owner, not as a reporting form to fill in once.
The register of information is DORA’s machine-readable inventory of every ICT third-party arrangement, required under Article 28(9).
Commission Implementing Regulation (EU) 2024/2956 defines 15 templates organized into related groups: entity identification, contractual arrangements, the ICT providers themselves, the functions each service supports, the criticality assessment of those functions, and the subcontracting chain. The templates cross-reference each other, so a contract entry has to link to a valid provider entry, and a provider entry has to link to a valid LEI.
Two fields carry most of the weight. First, every legal entity and every provider needs a valid 20-character LEI, with no gaps. Second, each business function must be mapped to a criticality classification, because that classification decides how deep the subcontracting disclosure has to go. Where a provider subcontracts material parts of a critical or important service, those subcontractors have to be named in the register too.
The first reference date was 30 April 2025, with entities submitting to their national competent authority shortly after. The cycle then repeats on an annual basis: the register is compiled to a year-end reference date and filed the following spring. The 2026 round, for example, references 31 December 2025. Supervisors can also request the register ad hoc, and entities are expected to keep it current whenever a material ICT arrangement starts, changes, or ends.
The practical consequence is that the register is a living dataset, not a once-a-year project. An entity that only assembles it in the weeks before the deadline tends to discover missing LEIs and unmapped functions with no time to fix them.
Article 29 of DORA requires a financial entity to assess single-provider and sector-wide concentration before entering a new ICT arrangement that supports a critical or important function. The register makes that concentration visible at scale. When hundreds of entities name the same handful of hyperscalers, supervisors can see a systemic dependency that no single entity would spot on its own. More than 65% of EU entities rely on at least two of the largest cloud providers, which is exactly the pattern the register is designed to surface.
From the aggregated registers, the ESAs designate Critical ICT Third-Party Providers. A designated CTPP then falls under a direct EU oversight framework, with a lead overseer able to conduct inspections and issue recommendations that the provider is expected to follow. The register is therefore more than a compliance filing: it is the raw material for how the EU supervises the concentration of digital risk in finance, and it gives each individual entity a defensible answer when its own board asks how exposed it is to a single provider outage.
Invalid or missing LEIs were behind roughly one third of the issues flagged in the 2025 cycle. That single field failure is enough to break the cross-references the templates depend on. The other frequent failures follow the same pattern: incomplete subcontracting chains, business functions that were never mapped to a criticality classification, and a register population that does not match the actual contract population held by procurement and legal.
Because the xBRL-CSV format validates structure on submission, quality problems surface as filing rejections rather than quiet gaps. That is a feature. It forces the data model to be correct before the supervisor ever reads it, and it rewards entities that treat the register as a governed data product with a named owner.
Ableneo has shipped 34 production AI projects across regulated industries, with roughly four of five reaching production rather than stalling as pilots. That work runs inside the same core banking and insurance platforms that DORA now governs, alongside clients such as ČSOB, Erste, and UNIQA. The register of information rewards the discipline we bring to every engagement: a clean data model, a named owner for each control, and a traceability path an auditor can follow end to end. Our DORA explainer sets out how the regulation applies to AI systems specifically, which is the next question most FS&I teams ask once the register is filed.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.