What the DORA Register of Information Requires

In the European Supervisory Authorities' voluntary dry run, 947 registers of information cleared the technical checks and were screened against 116 data quality checks. 6.5% of them passed all 116, and 86.4% of every failure recorded fell into one category: a mandatory field left empty. Those figures are the ESAs' own, published in their dry run summary report of 17 December 2024. The contrarian part is what that implies about the artifact: the register of information is not a document a supervisor reads, it is a validated dataset, checked by machine against a published data point model and against the global LEI database, and it comes back for correction when it fails. The second surprise is the calendar: the 30 April 2025 deadline that most DORA reporting summaries quote was a one-time derogation, and the standing rule underneath it is a different date.

What follows is what the register has to contain, which identifiers actually work, the deadline that replaced the one everybody wrote down, and where the ESAs' own evidence says these submissions break.

Key takeaways

• The register is fourteen linked tables, not a contract list. They join on keys, and a wrong key is a failed join rather than a typo.
• The LEI is the only identifier the implementing standard allows for a financial entity, and a register missing them is rejected rather than queried.
• The standing clock is a 31 December reference date with submission to the ESAs by 31 March. The 30 April 2025 deadline applied to the first submission only.
• In the dry run, 86.4% of failures were missing mandatory values, concentrated in the contractual-arrangement and ICT-service assessment templates.
• The hard fields belong to the risk function, not procurement: recovery objectives per function, substitutability, whether an exit plan exists, when the provider was last audited.

Fourteen tables, and the keys that join them

The EBA publishes a data model for the register setting out fourteen tables and, for every column, its type, its length, and whether it is a primary key, a foreign key, or nullable.

The tables answer four questions. Who you are: B_01.01 for the entity maintaining the register, B_01.02 for every financial entity inside its scope, B_01.03 for branches. What you signed: B_02.01 and B_02.02 for contractual arrangements in general and in detail, B_02.03 for intra-group arrangements, and B_03.01 to B_03.03 for who signed on each side. Who uses the service: B_04.01. Who supplies it: B_05.01 for the provider, B_05.02 for the supply chain beneath them, B_06.01 for the functions the services support, and B_07.01 for the assessment of the services themselves.

Those tables are joined, not stacked: the contractual arrangement reference number, the LEI of the financial entity, the identification code of the third-party provider and the function identifier are all keys. Allocate contract references per team, or let two systems mint provider codes independently, and the register assembles into a file that validates field by field while describing relationships that do not exist.

That is the difference between this and a vendor inventory. An inventory answers who you buy from. The register answers which contract, for which service, supporting which function, at which entity, from which supplier, with which parent above them, consistently enough to join.

The three levels, and who files what to whom

DORA has applied since 17 January 2025, and from that date, in the EBA's own words on its register preparation page, every in-scope financial entity needs a comprehensive register of its ICT third-party contractual arrangements available at entity, sub-consolidated and consolidated levels.

Three levels does not mean three submissions from everyone. The ESAs' decision on reporting for CTPP designation, adopted on 8 November 2024, tells competent authorities how to pass registers up: at individual entity level where the entity is not part of a group, at individual entity level where the group's parent sits outside the Union and there is no Union parent, and at the highest level of consolidation in the Union for groups. Your competent authority then submits to the EBA, acting for the three ESAs, through the EUCLID reporting infrastructure.

Two consequences are easy to miss. A group headquartered outside the EU with several EU-authorized subsidiaries is reported entity by entity rather than as one consolidated file, so identifier discipline has to hold across subsidiaries that may never have shared a vendor taxonomy. And where a register is filed at consolidated level, every financial entity inside that group has to appear in B_01.02 with a valid LEI of its own. That is a master data problem long before it is a reporting problem.

The deadline that replaced the one you wrote down

Article 4 of that ESAs decision sets the reference date at 31 December of the calendar year preceding the reporting date, and Article 5 sets the submission timeline from competent authorities to the ESAs at 31 March. Both articles then carry a derogation for the first annual submission in 2025 alone: reference date 31 March 2025, submission by 30 April 2025.

So the widely circulated April date was the exception, and the rule underneath it is a year-end snapshot reported in the first quarter. Two consequences for planning. Your own deadline is not 31 March; it is whatever earlier date your national competent authority sets so it can validate, chase and consolidate before its own, which makes your supervisor's instruction the only calendar that matters. And a 31 December reference date means the register has to be right as at year end, which is the week an organization has least appetite for a data cleanup. The teams that find this comfortable maintain the register continuously and freeze a snapshot rather than assembling one in February.

The decision also anticipates a tightening: for the first submission the ESAs collected no ex ante master data, and Article 8 provides that from 2026 competent authorities supply structured master data covering the basic properties of the entities and the composition of their groups. The ESAs increasingly know what your group looks like before your file arrives, so a register that quietly omits a subsidiary has a shorter life expectancy than it used to.

Where these submissions actually break

The dry run is the only published, numbered account of how registers fail that we have found on the ESAs' own pages as of August 2026, and the distribution is lopsided in a useful way.

Of more than 235,000 failed checks across more than 9,275,000 data points, the ESAs put 86.4% down to a mandatory field value missing, 6.5% to an invalid LEI code, 4.3% to an invalid value, 1.5% to duplicate values on a key variable and 1.3% to an invalid date. Within the missing values, 60% sat in B_02.02, the specific contractual arrangement template, and over 17% in B_05.01, the provider template. B_07.01, the assessment of ICT services, took 20%, and it is the template the ESAs describe as worst affected by concentration rather than by volume: in that one, every field except the key showed a high number of missing values, so the damage is spread across the template instead of sitting in two or three columns. The fields most often absent were the code identifying the provider and its type, the function identifier, the type of ICT services, and the provider's country of headquarters and ultimate parent.

The identifier finding is the counterintuitive one. More invalid LEIs were reported for the financial entities themselves, close to 9,000, than for their third-party providers, close to 6,000, because in many cases a national code was reported where an LEI was requested. The ESAs' conclusion is unambiguous: the LEI is the only identifier the implementing standard allows for identifying financial entities, registers will be rejected where those LEIs are missing, and missing provider identifiers are flagged for correction and resubmission.

One caveat on reading those numbers across. The dry run accepted partial registers on a best-efforts basis and the ESAs say so plainly, so the 86.4% is not a claim that the industry could not fill its fields. What makes it predictive is the sentence that follows in the report: in official reporting all data points specified in the implementing standard have to be reported, and missing values trigger data quality feedback requiring resubmission. The dry run's most common failure is the one the real process refuses to tolerate.

The fields that are not in your contract system

Work through the data model and a pattern appears: a large share of the mandatory content is not contract metadata, and no procurement system holds it.

B_06.01, functions identification, wants a function identifier, the licensed activity it supports, a criticality or importance assessment with its reasons, the date that assessment was last made, a recovery time objective and a recovery point objective for the function, and the impact of discontinuing it. B_07.01 wants the substitutability of the provider, the reason where it is not substitutable or difficult to substitute, the date of the last audit on that provider, whether an exit plan exists, whether the service could be reintegrated, and whether alternatives have been identified. B_02.02 wants the country of the governing law, the country of provision, the location of the data at rest and of data management, the sensitiveness of that data, and the level of reliance on a service supporting a critical or important function.

Every one of those is a judgment owned by a risk function, a resilience team or a business owner, and the register is where such judgments become dated, auditable, per-function facts instead of institutional memory. Firms already running a serious vendor risk program, of the kind described in our vendor risk management guide, find the register mostly a reformatting exercise. Firms whose third-party process is a procurement workflow with a questionnaire attached find it asking them to do the underlying risk work for the first time, in a schema, with a deadline.

What the ESAs do with it

Your register is not filed and forgotten. It is an input to the designation of critical ICT third-party service providers, the mechanism that pulls a technology company under direct EU oversight. When the ESAs designated the first critical providers on 18 November 2025, their own account of the method starts with collecting data from the registers of information maintained by financial entities, and the EBA's DORA oversight page states that the list of designated providers is published and updated annually. The site's regulatory radar entry covers what that first round changed.

That is why provider identifiers and parent undertakings carry more weight than the rest. Designation turns on aggregating one provider's footprint across thousands of financial entities, so if your file names a supplier with a national code while another entity's uses its LEI, the aggregation misses. Those are the fields where your data quality becomes somebody else's regulatory outcome, which is the argument for remediating them first.

For suppliers, this is where the register meets the contract: what you have to record about a vendor is largely what your addendum has to make them give you, which is the subject of the clause-by-clause read and, for vendors wondering whether any of this binds them, does DORA apply to US companies.

When you should not hire a consultancy for this

Here is the part that costs us work, and it applies to more readers than we would like.

If you are a single authorized entity with no group structure, a contract population in the tens rather than the hundreds, and a competent authority that has already told you its format, you do not need a consultancy for the register. The ESAs and the EBA publish the implementing standard, the data model, the annotated table layouts, the validation rules, the permitted values for every dropdown field, a reporting FAQ and a document of common issues observed in testing, all free, all on the preparation page, and your supervisor gives you validation feedback on top. That is a competent internal project, and the money is better spent getting LEIs issued for the entities that lack them.

Two more limits worth saying out loud. Nobody can sell you a register: the content lives in your contracts, your service catalog and your resilience assessments, and an external team can build the structure but cannot invent the substance. And if the real problem is that nobody has decided which functions are critical or important, that is a governance decision rather than a reporting project, and buying a register build first produces a well-formed file full of contested judgments.

Where an outside team does earn its fee: multi-entity groups where the consolidation level is genuinely unclear, first submissions that came back with a resubmission request and a short window, and organizations holding ISO 27001 or SOC 2 that want the overlap mapped rather than a parallel program built, which is the argument we make about reusing evidence across frameworks.

Where Top Floor fits

Our DORA practice builds the register and, more usefully, the maintenance process that keeps it current between reference dates, because a register that is accurate once a year is a project while a register that is accurate continuously is a control. That means identifier remediation, mapping your contract population into the fourteen tables, the function-level assessments B_06.01 and B_07.01 depend on, and dry validation before your supervisor sees the file.

Where the exposure runs wider, because you are authorized in several jurisdictions or answering NIS2 and DORA from one control environment, that is international compliance work and should be scoped as one program rather than a stack of single-regulation projects. Where nobody owns the resilience judgments underneath the register, a vCISO is the honest answer, because what is missing is an accountable decision-maker rather than a document.

We will also tell you when a gap assessment against the register you already have is all you need.

How to decide this week

Three steps, in order, none of which needs a budget.

First, confirm your level and your date. Ask your competent authority in writing which level it expects your register at and by which date it wants it, then work backwards. That single email removes the most expensive category of rework.

Second, run the identifier check. Every financial entity in your scope needs a valid LEI, and every provider needs an identifier used consistently across all fourteen tables. This was the second largest failure category in the dry run and it has the longest lead time, because obtaining or renewing an LEI is an external process on somebody else's clock.

Third, take B_06.01 and B_07.01 and mark each field green, amber or red against evidence you could produce today: criticality assessments with dates, recovery objectives per function, substitutability, exit plans, last audit dates. The reds are your actual project, and they are almost never the contract fields.

Frequently asked questions

When is the DORA register of information due?

The register itself is a standing obligation rather than an annual one: it has to be maintained and kept current from the day DORA applied. The reporting clock is separate, and it belongs to your competent authority. Under the ESAs' decision of 8 November 2024, competent authorities submit registers to the ESAs by 31 March with a reference date of 31 December of the preceding year, and the first submission in 2025 ran to a derogation, with a 31 March 2025 reference date and a 30 April 2025 deadline. Your own deadline is set nationally and sits earlier than your supervisor's, so ask them rather than diarizing the ESAs' date.

What identifiers does the register require?

For financial entities, the LEI and nothing else. The ESAs state that the LEI is the only identifier the implementing standard allows for identifying financial entities, and that registers will be rejected where those LEIs are missing. For ICT third-party providers, the standard permits a wider set of codes, but the code and the type of code both have to be present and used consistently across the templates, including for the provider's ultimate parent undertaking. Invalid LEI codes were the second largest failure category in the ESAs' dry run, and the most common cause was a national code being reported where an LEI was requested.

Does a group file one register or several?

It depends on where the parent sits. The ESAs' decision has competent authorities report at the highest level of consolidation available in the Union for groups of financial entities, at individual entity level where the entity is not part of a group, and at individual entity level where the group's parent undertaking is outside the Union and there is no Union parent. A non-EU group with several EU-authorized subsidiaries therefore tends to be reported subsidiary by subsidiary. Where a consolidated register is filed, every financial entity inside the scope of that register has to appear with its own valid LEI.

Is a vendor inventory or a GRC platform enough?

Not on its own, and the reason is structural rather than a criticism of any tool. A vendor inventory records who you buy from; the register records which contractual arrangement, for which ICT service, supporting which identified function, used by which entity, supplied by which provider and which parent, and it joins those on keys. The fields that most often break a submission are not procurement fields at all: recovery objectives per function, substitutability, the date of the last audit of the provider, whether an exit plan exists. A platform can hold and export that data. Somebody still has to decide it.