The Register of Information is the structured record of every ICT third-party arrangement a financial entity holds, required by Article 28 of the Digital Operational Resilience Act, Regulation (EU) 2022/2554. The Implementing Technical Standards — Commission Implementing Regulation (EU) 2024/2956 — define fifteen templates, submitted in xBRL-CSV, covering entities, branches, contracts, providers, the functions they support and the subcontracting chain. You populate the templates that apply to you; a firm with no branches and no intra-group arrangements files fewer than fifteen. Because the templates cross-reference one another, the register has to hold together as a whole — which is why most rejections are mechanical (a failed LEI checksum, a dangling reference) rather than a matter of interpretation.
What the Register of Information is
The Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — makes ICT third-party risk a first-class supervisory concern for EU financial services. One of its most concrete obligations is the Register of Information (RoI): a machine-readable inventory of all contractual arrangements for the use of ICT services provided by third-party providers, maintained at both entity and group level.
The register isn't a document you write — it's a set of structured tables with fixed columns, defined by the Implementing Technical Standards (Commission Implementing Regulation (EU) 2024/2956). Financial entities submit it to their national competent authority (NCA), which forwards it to the European Supervisory Authorities. The submission format is xBRL-CSV: one CSV per template, column codes in the c0010 / c0020 style, packaged against the EBA taxonomy. Because the format is rigid and cross-referenced, most of the effort is assembling accurate data and getting every identifier and reference to line up.
DORA applies to a broad set of "financial entities" under its Article 2 — banks, insurers and reinsurers, investment firms, payment and e-money institutions, crypto-asset service providers, fund managers, and more. A group files per authorised entity, plus a consolidated view. Confirm your own scope and submission timetable with your NCA.
The fifteen templates, in plain English
Each template has a code (for example B_02.02) and a fixed set of columns (c0010, c0020…). Here is what each one captures:
| Template | What it records |
|---|---|
B_01.01 | The entity maintaining the register — LEI, name, country and entity type. |
B_01.02 | Every entity covered by the register, on a solo, sub-consolidated or consolidated basis. |
B_01.03 | Branches of in-scope entities that make use of ICT services. |
B_02.01 | Each contractual arrangement in overview — reference number, type, overarching reference, annual expense and currency. |
B_02.02 | Per arrangement and ICT service: provider, service type, functions supported, storage and processing locations, data sensitiveness, dates, notice periods, governing law. |
B_02.03 | Arrangements where the provider belongs to the same group as the financial entity. |
B_03.01 | Which in-scope entity signs each arrangement to receive ICT services. |
B_03.02 | Which provider entity signs each arrangement. |
B_03.03 | Arrangements signed by one entity on behalf of others within the scope of consolidation. |
B_04.01 | Which entities and branches actually use each contracted ICT service. |
B_05.01 | The providers themselves — LEI or EUID, name, country, type of person, ultimate parent. |
B_05.02 | The supply chain per arrangement: rank 1 the direct provider, rank 2 and beyond the material subcontractors. |
B_06.01 | Your firm's functions — identifier, name, licensed activity, and whether the function is critical or important. |
B_07.01 | The assessment for services supporting a critical or important function — substitutability, reintegration difficulty, discontinuation impact, exit plan, last audit date. |
B_99.01 | An LEI-keyed glossary of the entity-specific definitions used across the register. |
Read together, the tables answer one question in a way a supervisor can audit: for every critical function you run, exactly who — and whose subcontractors — could disrupt it, and what happens if they fail?
The four identifiers that have to line up
The templates are relational, and four identifiers carry the joins. Get these consistent and the register assembles itself; get one of them wrong in one table and the submission fails on a reference that points at nothing.
| Identifier | What it joins |
|---|---|
| Contractual arrangement reference | Your own unique reference for each contract. It threads B_02.01, B_02.02, B_03.01–B_03.03, B_04.01 and B_05.02 together. It must be stable between filings. |
| LEI | Identifies every legal entity — yours, your providers, their ultimate parents. Twenty characters, with a checksum (see below). |
| Function identifier | Defined by you in B_06.01 and cited by every arrangement that supports the function. It has to stay unique per licensed activity — the same ICT service supporting two regulated activities needs two identifiers, not one reused. |
| Type of ICT service | An Annex III code, not free text. It classifies the service in B_02.02 and follows the arrangement down the supply chain in B_05.02. |
The Annex III service types
Annex III of the ITS fixes the vocabulary for what a provider actually does. Firms that describe services in their own words rather than these codes fail validation on a field that never involved judgement:
| Code | Type of ICT service |
|---|---|
S01 | ICT project management |
S02 | ICT Development |
S03 | ICT help desk and first level support |
S04 | ICT security management services |
S05 | Provision of data |
S06 | Data analysis |
S07 | ICT, facilities and hosting services (excluding Cloud services) — this is also where payment-processing activities and payment infrastructure sit |
S08 | Computation |
S09 | Non-Cloud Data storage |
S10 | Telecom carrier |
S11 | Network infrastructure |
S12 | Hardware and physical devices |
S13 | Software licencing (excluding SaaS) |
S14 | ICT operation management (including maintenance) |
S15 | ICT Consulting |
S16 | ICT Risk management |
S17 | Cloud services: IaaS |
S18 | Cloud services: PaaS |
S19 | Cloud services: SaaS |
Four things that trip firms up
1. A single mistyped LEI
Every legal entity in the register — your entities, your providers, their parents — is identified by a 20-character Legal Entity Identifier. An LEI carries a built-in checksum (ISO 17442, the MOD 97-10 scheme, the same maths as an IBAN), so a transposed or fat-fingered digit is mathematically detectable. Regulators run that check; a register full of LEIs that fail it comes straight back. Validate every identifier before you file — and reconcile it against your procurement master data rather than re-typing it. We cover the checksum itself in how to validate an LEI.
2. Stopping at your direct provider
The supply chain table (B_05.02) is where registers are most often incomplete. DORA cares about the whole chain that supports a critical function — not just the vendor you signed with, but the cloud region they run on and the firm they depend on.
The chain is recorded by rank. Rank 1 is the provider you signed with. Rank 2 is that provider's material subcontractors. Rank 3 is theirs, and so on down. Everyone in the chain hangs off the same contractual arrangement reference and the same Annex III service type, which is what lets a supervisor collapse thousands of arrangements into a concentration view across the market. Article 30(2) sets what makes a subcontractor material enough to name; the practical difficulty is that the answer lives with your provider, not with you, so it has to be asked for and chased.
If a subcontractor supporting a critical function is missing, the register understates concentration risk — exactly the blind spot the requirement exists to remove. We go deeper in mapping the ICT subcontracting chain.
3. Getting "critical or important" wrong
The criticality flag in B_06.01 drives everything downstream: it decides which arrangements need the full assessment in B_07.01. Marked too loosely, you file thin assessments where deep ones were required; too broadly, you drown the register in noise. This is a genuine judgement call — one of the few places the register needs a human view.
4. Referential integrity across tables
The templates are relational. An arrangement referenced in B_02.02 must exist in B_02.01; a provider LEI must appear in B_05.01; a function identifier cited by an arrangement must be defined in B_06.01. A register assembled by hand across fifteen spreadsheets accumulates orphaned references quietly — and each one is a validation failure at submission.
The rules that catch it, before a supervisor does
Every mistake above is mechanical, which means code can catch it. These are the deterministic rules the Qgentic engine runs over a register before it will let a run reach an approver. No model judgement is involved in any of them; a rule either passes or stops the run.
| Rule | What it refuses to let through |
|---|---|
QG-STRUCT-000 | A register that does not match the schema — wrong shape, unknown field, missing table, or a value outside a closed list such as the Annex III service types. |
QG-LEI-001 | Any LEI failing its ISO 17442 MOD 97-10 checksum or 20-character shape — the maintaining entity's, an in-scope entity's, a provider's, an ultimate parent's, an arrangement's entity or provider reference, or a supply-chain row's. |
QG-ISO-002 | A country outside ISO 3166-1 alpha-2. User-assigned codes are downgraded to a warning rather than blocked, because a supervisor may accept them. |
QG-ISO-003 | An annual-expense currency outside ISO 4217. |
QG-DT-004 | A date that is not a real calendar date, and an arrangement that ends before it starts. |
QG-REF-005 | An arrangement citing a provider LEI absent from B_05.01, or an entity LEI absent from B_01.02. |
QG-REF-006 | An arrangement citing a function identifier that B_06.01 never defines. |
QG-REF-007 | A supply-chain row for an unknown arrangement; a rank-1 row naming someone other than the arrangement's direct provider; a chain that does not start at rank 1. Non-contiguous ranks are a warning. |
QG-REF-008 | A B_07.01 assessment keyed to a contractual arrangement reference no arrangement carries — an orphan row whose join key resolves to nothing in the filing. |
QG-CIF-008 | An arrangement supporting a critical or important function with no B_07.01 assessment behind it. |
QG-CIF-009 | Silently filing a critical or important function with no documented exit plan — raised as a warning, because the absence may be the true state of the world. |
QG-CIF-010 | An arrangement supporting a critical or important function with no rank-1 supply-chain row identifying who actually delivers it. |
QG-ENT-011 | A maintaining entity that does not itself appear in the list of in-scope entities. |
QG-ENT-012 | A duplicate contractual arrangement reference — the key every other template joins on. |
QG-CMP-013 | Silently filing without the fields the EBA's own validation rules expect populated: the competent authority, a provider's ultimate parent identification, an arrangement's end date, and the dates of the last criticality assessment and last audit. Warnings, mirroring the published severity. |
Fifteen rules, and between them they account for the overwhelming majority of what gets a register bounced. That is the point worth taking away even if you never buy anything: the expensive part of the Register of Information is not interpretation. It is arithmetic, and arithmetic is checkable.
How Qgentic builds the register for you
This is exactly the work Qgentic DORA does. It reads the contracts and vendor master data your firm already holds, assembles the entity, arrangement, provider, supply-chain, function and assessment templates, and runs the rules above over the result. When it meets a broken LEI it repairs it from your own master data and records the correction; when a critical function's subcontractor is undisclosed, it drafts the outreach and parks the run until the answer arrives. A named person approves the finished package, and every step lands in a tamper-evident audit trail.
DORA is available today, with a fully air-gapped edition for firms that can't send contract data off their own network. You can watch the whole cycle — including the broken-LEI repair — in the live browser demo.
This guide is engineering-and-compliance orientation, not legal advice, and the ITS is periodically updated. Confirm the current templates, your scope and your submission timetable with your national competent authority or counsel before you file.
See it on your own data. A four-to-six-week shadow run builds your register alongside your current process, credited against year one.
Watch the live demo Book a consultation