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. It is filed across eleven templates set by the Implementing Technical Standards, Commission Implementing Regulation (EU) 2024/2956, covering entities, contracts, providers, the functions they support and the subcontracting chain. Because those 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. Because the format is rigid and cross-referenced, most of the effort isn't judgement — it's 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 eleven templates, in plain English
The register is delivered as a set of linked CSV tables. Each 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 — its LEI, name, country and entity type. |
B_01.02 | The entities within the group's scope, with their place in the hierarchy. |
B_02.01 | Each contractual arrangement in overview — reference, type, annual expense and currency. |
B_02.02 | The detail of each arrangement — the provider's LEI, the ICT service, the functions it supports, dates, notice period and governing law. |
B_03.01 / B_03.02 | Who is party to each arrangement — which in-scope entity uses it, and which provider signs it. |
B_04.01 | The entities making use of each ICT service, linked back to the arrangement. |
B_05.01 | The ICT third-party providers themselves — LEI, name, country and ultimate parent. |
B_05.02 | The subcontracting chain per arrangement — each subcontractor, ranked, with what it does. |
B_06.01 | Your firm's functions — an ID, name, the licensed activity, and whether the function is critical or important. |
B_07.01 | The resilience assessment for arrangements supporting critical functions — substitutability, reintegration, discontinuation impact, exit plan and last audit. |
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?
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 subcontracting 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. 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 resilience 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 ID cited by an arrangement must be defined in B_06.01. A register assembled by hand across eleven spreadsheets accumulates orphaned references quietly — and each one is a validation failure at submission.
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 all eleven templates, and validates every field deterministically — the LEI checksums, the cross-template references, the criticality-to-assessment linkage. 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