The DORA Register of Information, explained

A Register of Information is the structured record of every ICT contractual arrangement a financial entity holds, kept in a fixed set of reporting templates and filed with a supervisory authority. This page is the plain account of what it contains and what form it takes. Every regulatory statement on it is footnoted to the instrument that says so.

What is a Register of Information?

It is a set of linked reporting templates in which a financial entity records every ICT contractual arrangement it holds, maintained and updated under the implementing standard that prescribes their format.^[1]

The word "register" does more work here than it looks. This is not a list of suppliers: it is a classification. Each arrangement has to be tied to the function it supports, the entity that uses it, the provider that signs it, and — where the function is critical or important — an assessment of what would happen if that provider stopped.

The templates are set out in Annexes I to IV of the implementing standard, and a register is kept at entity level, or at sub-consolidated and consolidated level for a group.^[1]

What has to be in it?

The relevant information on all ICT services from direct providers, plus every subcontractor that effectively underpins an ICT service supporting a critical or important function.^[2]

The second half is the one that surprises people. A register is not bounded by who you signed with: where a direct provider supports a critical or important function, the subcontractors underneath them that effectively underpin that service belong in the register too. That is the ICT service supply chain, and it is where the data has to come from outside your own systems.

Position in that chain is recorded as a rank. The direct provider is always rank 1, and a subcontractor is always higher — a lower number means closer to the financial entity.^[3]

Which identifiers does it require?

A valid and active LEI, or the EUID, and both where available, for every ICT third-party service provider that is a legal person.^[4]

Two words in that requirement do most of the damage in practice: valid and active. A Legal Entity Identifier can be well formed and still be lapsed, retired, or never issued at all — and the difference is a fact about the GLEIF register, not about the twenty characters in your cell.

This is also the boundary of the free checker on this site, stated plainly rather than glossed. It confirms an identifier is well formed and was issued, from a snapshot compiled at build time and served from this origin. It cannot confirm the identifier is still active, because doing so would mean sending it somewhere — and nothing on this site sends your register anywhere.

Does a group keep one register or several?

Both are possible: a register is maintained at entity level, or at sub-consolidated and consolidated level, and a consolidated one covers every financial entity and ICT intra-group provider in the group.^[5]

For a parent undertaking, deciding which entities belong in a consolidated register means reading the relevant sectorial Union legislation rather than following a single rule in the implementing standard.^[5]

The practical consequence for anyone filing across a book of entities is that the classification work does not repeat per entity. The same providers, the same functions and the same criticality judgements recur, which is why the marginal cost of a second register is a fraction of the first.

What counts as a correct register?

The implementing standard names six data quality principles: accuracy, completeness, consistency, integrity, uniformity and validity.^[6]

Those are the terms the instrument itself uses, and they are worth reading as six separate tests rather than as a phrase. Consistency and uniformity are the two that catch a register assembled from several teams: the same provider named two ways, or the same function identified differently in two entities, passes every field-level check and still fails.

Each data element carries a single value. Where more than one value is valid, the answer is another row rather than a longer cell — which is the mechanical reason a register grows sideways at the supply-chain templates.^[7]

What format is it filed in?

An xBRL-CSV reporting package following Report Package 1.0: a ZIP containing META-INF/reportPackage.json and a reports folder, encoded in UTF-8.^[8]

The templates are worked on as a spreadsheet and filed as something else. The package is a defined structure with a defined filename, and values drawn from a closed list have to be written with the eba_ prefix — eba_CT:x12 rather than the label a human reads in the dropdown.^[9]

Most first-time rejections are about this layer rather than about the content: a filename that has been used before, a file over the size limit, a boolean in the wrong case. They are also the cheapest defects to find, because they can be found before you file rather than after.

What is checked when you file?

The EBA publishes 120 checks in four categories: technical checks, DPM technical checks, DPM business validation rules, and LEI/EUID checks.^[10]

They are not all equally serious. The technical checks are errors: they reject the submission. The DPM business validation and identifier checks are warnings — the register is accepted, and the entity is expected to fix the issues and resubmit.^[11]

A warning is therefore not a pass. It is a finding on the record with your name against it, which is the part that matters when a supervisor asks about it later.

The fourteen reporting templates

Fourteen templates carry the register, from RT.01.01 through RT.07.01, plus RT.99.01 — a legend of the permitted values used in the others rather than a template anybody reports.^[12]

Each has two names. Reporters see the RT notation in their workbook; the data model, the validation rules and every message a regulator sends back use the B_ notation. They map one to one, and a finding that quotes only one of them is a finding you have to translate before you can act on it.

The title and description of each template below are the enacted text of Annex I, in the language you are reading, rather than our summary of it.

RT.01.01RT.01.01Entity maintaining the register of informationB_01.016 fieldsThis template identifies the entity maintaining and updating the register of information at entity, sub-consolidated and consolidated level, respectively.A compliance officer at a mid-size bank is preparing to submit. Before anything else the file has to say who is filing it: the bank’s own LEI, its country, its type, and which authority receives it. That single row is RT.01.01.If this row is wrong, an otherwise correct register is filed against the wrong entity.Full entry Entity maintaining the register of informationB_01.01: This template identifies the entity maintaining and updating the register of information at entity, sub-consolidated and consolidated level, respectively.
RT.01.02RT.01.02List of entities within the scope of consolidationB_01.0211 fieldsThis template identifies all the entities belonging to the group. Where the financial entity responsible for maintaining and updating the register of information does not belong to a group, only that financial entity shall be reported in this template.An insurance group files one register for the whole group. RT.01.02 is where each entity in the consolidation is listed — LEI, country, parent undertaking, total assets — so a supervisor can see which legal entities the rest of the register speaks for.Every LEI used elsewhere in the register is expected to have been declared here first.Full entry List of entities within the scope of consolidationB_01.02: This template identifies all the entities belonging to the group. Where the financial entity responsible for maintaining and updating the register of information does not belong to a group, only that financial entity shall be reported in this template.
RT.01.03RT.01.03List of branchesB_01.034 fieldsThis template identifies the branches of the financial entities referred to in template B_01.02.A French bank runs a branch in Belgium. The branch is not a separate legal entity and has no LEI of its own, so it cannot be listed in RT.01.02. RT.01.03 is where it is named and tied back to its head office.Reporting a branch as though it were a legal entity is one of the easier structural mistakes to make.Full entry List of branchesB_01.03: This template identifies the branches of the financial entities referred to in template B_01.02.
RT.02.01RT.02.01Contractual arrangements – general informationB_02.015 fieldsThis template lists all contractual arrangements with direct ICT third-party service providers.The procurement team pulls every ICT contract in force. Each one is given a reference number here, together with whether it stands alone or sits under a master agreement, and what it cost last year.The reference numbers minted here are the key that binds most of the rest of the register together.Full entry Contractual arrangements – general informationB_02.01: This template lists all contractual arrangements with direct ICT third-party service providers.
RT.02.02RT.02.02Contractual arrangements – specific informationB_02.0218 fieldsThis template provides details in relation to each contractual arrangement listed in template B_02.01 with regard to: (a) the ICT services included in the scope of the contractual arrangement; (b) the functions of the financial entities supported by those ICT services; (c) other important information in relation to the specific ICT services provided (e.g. notice period, law governing the arrangement, etc.).For one cloud contract, this is the long form: which entity uses it, which provider supplies it, the type of service, start and end dates, notice periods on both sides, governing law, where the data sits at rest, and how sensitive it is.It carries more fields than any other template, so it is where most of the filling-in time goes.Full entry Contractual arrangements – specific informationB_02.02: This template provides details in relation to each contractual arrangement listed in template B_02.01 with regard to: (a) the ICT services included in the scope of the contractual arrangement; (b) the functions of the financial entities supported by those ICT services; (c) other important information in relation to the specific ICT services provided (e.g. notice period, law governing the arrangement, etc.).
RT.02.03RT.02.03List of intra-group contractual arrangementsB_02.032 fieldsThis template identifies the links between intra-group contractual arrangements and contractual arrangements with ICT third-party service providers which are not part of the group using the contractual reference numbers when part of the ICT service supply chain.A subsidiary buys data centre capacity from its own parent, which buys it in turn from an external provider. RT.02.03 links the internal arrangement to the external one.Without it, an intra-group arrangement looks like the end of the supply chain when it is not.Full entry List of intra-group contractual arrangementsB_02.03: This template identifies the links between intra-group contractual arrangements and contractual arrangements with ICT third-party service providers which are not part of the group using the contractual reference numbers when part of the ICT service supply chain.
RT.03.01RT.03.01Entities signing the contractual arrangements for receiving ICT service(s) or on behalf of the entities making use of the ICT service(s)B_03.012 fieldsThis template provides information on the entity signing the contractual arrangements with the direct ICT third-party service provider for the entity making use of the ICT services.A group signs one contract centrally and four subsidiaries use the service. RT.03.01 names the entity that actually put its signature on the paper — often not the entity using the service.Signing and using are different acts, and the register asks for both separately.Full entry Entities signing the contractual arrangements for receiving ICT service(s) or on behalf of the entities making use of the ICT service(s)B_03.01: This template provides information on the entity signing the contractual arrangements with the direct ICT third-party service provider for the entity making use of the ICT services.
RT.03.02RT.03.02ICT third-party service providers signing the contractual arrangements for providing ICT service(s)B_03.023 fieldsThis template identifies all the ICT third-party service providers referred to in template B_05.01 signing the contractual arrangements referred to in template B_02.01 for providing the ICT services.The same contract seen from the other side: which of the provider’s legal entities signed it. A vendor often contracts through a local subsidiary rather than under the group name on the invoice.The signing legal entity is frequently not the brand the service is bought under.Full entry ICT third-party service providers signing the contractual arrangements for providing ICT service(s)B_03.02: This template identifies all the ICT third-party service providers referred to in template B_05.01 signing the contractual arrangements referred to in template B_02.01 for providing the ICT services.
RT.03.03RT.03.03Entities signing the contractual arrangements for providing ICT service(s) to other entities within the scope of consolidationB_03.032 fieldsThis template identifies all the entities referred to in template B_01.02 signing the contractual arrangements referred to in template B_02.01 for providing the ICT services to other entities in the consolidation.A group’s shared-services company provides IT to its sister entities. It is a provider, and it is also inside the group, so RT.03.03 records it signing to supply the others.Intra-group providers are still providers, and leaving them out understates the group’s own dependencies.Full entry Entities signing the contractual arrangements for providing ICT service(s) to other entities within the scope of consolidationB_03.03: This template identifies all the entities referred to in template B_01.02 signing the contractual arrangements referred to in template B_02.01 for providing the ICT services to other entities in the consolidation.
RT.04.01RT.04.01Entities making use of the ICT servicesB_04.014 fieldsThis template identifies all entities making uses of the ICT services provided by ICT third-party service providers and registered in the register of information.One contract, several users. RT.04.01 answers the question "who actually consumes this service" — each entity, whether direct user or branch, tied back to the contract’s reference number.It is what turns a list of contracts into a map of who depends on what.Full entry Entities making use of the ICT servicesB_04.01: This template identifies all entities making uses of the ICT services provided by ICT third-party service providers and registered in the register of information.
RT.05.01RT.05.01ICT third-party service providersB_05.019 fieldsThis template lists and provides general information to identify: (a) the direct ICT third-party service providers; (b) the ICT intra-group service providers; (c) all subcontractors included in template B_05.02 on ICT service supply chain; (d) the ultimate parent undertaking of the ICT third-party service providers listed in points (a), (b) and (c).The vendor list. For each provider: its identification code and what kind of code that is, its name, the country of its headquarters, the total annual cost, and its ultimate parent undertaking.Every identification code here is read against the type of code it declares itself to be.Full entry ICT third-party service providersB_05.01: This template lists and provides general information to identify: (a) the direct ICT third-party service providers; (b) the ICT intra-group service providers; (c) all subcontractors included in template B_05.02 on ICT service supply chain; (d) the ultimate parent undertaking of the ICT third-party service providers listed in points (a), (b) and (c).
RT.05.02RT.05.02ICT service supply chainB_05.027 fieldsThis template identifies and links the ICT third-party service providers that are part of the same ICT service supply chain.A bank’s payroll provider stores its data with a cloud host, which uses a third firm for backups. RT.05.02 records that chain rank by rank — the part of the register most firms cannot answer from their own contracts, because the answer sits with the vendor.Sub-contracting is where a dependency nobody contracted for turns up.Full entry ICT service supply chainB_05.02: This template identifies and links the ICT third-party service providers that are part of the same ICT service supply chain.
RT.06.01RT.06.01Functions identificationB_06.0110 fieldsThis template identifies and provides information on the functions of the financial entity making use of the ICT services.Before any service can be assessed, the firm names its own functions — "execution of retail payments", say — and says whether each is critical or important, why, and how long it could be down. The function identifiers defined here are used throughout RT.02.02.Nothing downstream can be classified until the functions here have been named.Full entry Functions identificationB_06.01: This template identifies and provides information on the functions of the financial entity making use of the ICT services.
RT.07.01RT.07.01Assessments of the ICT servicesB_07.0112 fieldsThis template captures information in relation to the risk assessment of the ICT services (e.g. substitutability, date of last audit, etc.) when those ICT services are supporting a critical or important function or material part thereof.For each service supporting a critical or important function: could this provider be replaced, when was it last audited, is there an exit plan, could the service be brought back in house, and has an alternative provider been identified.These are the judgements no vendor can make on your behalf.Full entry Assessments of the ICT servicesB_07.01: This template captures information in relation to the risk assessment of the ICT services (e.g. substitutability, date of last audit, etc.) when those ICT services are supporting a critical or important function or material part thereof.
RT.99.01RT.99.01Options legendDefinitions from entities making use of the ICT ServicesThis template captures entity-internal explanations, meanings, and definitions of the closed set of indicators used by the financial entity in the register of information.RT.07.01 asks for the impact of losing a service as low, medium or high. RT.99.01 is where the firm writes down what it means by "high". It holds no register data of its own — it is the key to the closed-set answers given elsewhere.Without it, a supervisor reading "high" has no way to know what the firm meant by it.Full entry Definitions from entities making use of the ICT ServicesB_99.01: This template captures entity-internal explanations, meanings, and definitions of the closed set of indicators used by the financial entity in the register of information.

Full definitions in the glossary

Questions this page is asked next

Is a spreadsheet enough, or does it have to be xBRL-CSV?

The register is maintained in the templates and filed as a reporting package. The spreadsheet is how the work is done; the package is what is submitted, and converting between them is a mechanical step that can be got wrong in a small number of well-documented ways.

Our providers will not give us their subcontractor details. What then?

That gap is real and it is not one a consultant can close on your behalf. What can be done is to name it precisely — which provider, which field, and what to ask them for — so the request goes out as a specific question rather than as a general one, and so the gap is documented rather than silently left blank.

Can a clean result from a validation tool guarantee acceptance?

No, and any tool that says otherwise is overstating what it does. A clean result means the rules that ran found nothing. The free checker on this site implements a subset of the published checks and states which under every result, and several published checks require a live registry lookup that no offline tool can perform.

How much of this can be reused next cycle?

Most of the classification, and almost none of the assembly. Function identifiers, service types and criticality assessments are judgements that persist until the underlying arrangement changes; provider details, contract dates and the package itself are rebuilt each time.

If you are building one now

The free checker on this site reads a register in your browser and reports what the published checks would find, without uploading anything. If you would rather the register were built from your contracts than checked after the fact, that is the engagement.

Validator Register of Information Sprint Register Rescue Glossary

For management companies and fund administrators

Sources

[1]The ITS requires financial entities to use the templates in Annexes I to IV to maintain and update the register of information in accordance with Article 28(3) of Regulation (EU) 2022/2554, at entity level or at sub-consolidated and consolidated level. Source (opens in a new tab) ↩
[2]The register must cover the relevant information on all ICT services provided by direct ICT third-party providers, and information on all subcontractors that effectively underpin ICT services supporting critical or important functions or material parts thereof. Source (opens in a new tab) ↩
[3]Every ICT third-party service provider is assigned a rank: the direct provider is always rank 1, and a subcontractor is always higher, with a lower number meaning closer to the financial entity. Source (opens in a new tab) ↩
[4]Financial entities must use a valid and active LEI, or the European Unique Identifier (EUID) referred to in Article 16 of Directive (EU) 2017/1132, and both where available, to identify every ICT third-party service provider that is a legal person — except individuals acting in a business capacity. Source (opens in a new tab) ↩
[5]A register maintained at sub-consolidated and consolidated level must include all financial entities and ICT intra-group service providers that are part of the sub-group and the group; parent undertakings take the relevant sectorial Union legislation into account when deciding which entities to include. Source (opens in a new tab) ↩
[6]The ITS names six data quality principles the register must satisfy: accuracy, completeness, consistency, integrity, uniformity and validity. Source (opens in a new tab) ↩
[7]Each data element carries a single value. Where more than one value is valid, an additional row is added to the template for each one. Source (opens in a new tab) ↩
[8]A submission is an xBRL-CSV reporting package following Report Package 1.0, containing META-INF/reportPackage.json and a reports folder. Source (opens in a new tab) ↩
[9]Values drawn from a closed set must be written with the eba_ prefix, for example eba_CT:x12. Source (opens in a new tab) ↩
[10]The EBA publishes 120 checks for Register of Information reporting, in four categories: technical checks, DPM technical checks, DPM business validation rules, and LEI/EUID checks. Source (opens in a new tab) ↩
[11]The ESAs’ technical checks are errors that reject a submitted register, while the DPM business validation and identifier checks are warnings: the register is accepted, and the entity is expected to fix the issues and resubmit. Source (opens in a new tab) ↩
[12]The ESA reporting template carries 14 reporting templates, RT.01.01 to RT.07.01, plus RT.99.01, which is an options legend rather than a reportable template. spec/RegisterInformation.xlsx — Counted from the ESA reporting template held in /spec/. A public URL for that workbook is pending owner confirmation (spec/SOURCES.md). ↩