Risk ManagementOperational ResilienceThird-Party RiskDORA
DORA Register of Information: A Complete Template and Walkthrough
The Register of Information (RoI) is the single most data-intensive deliverable in the entire DORA framework. Mandated by Article 28(3) of Regulation (EU) 2022/2554 and structured by Implementing Technical Standard (ITS) 2024/2956, it is a machine-readable dataset — fifteen interlinked templates, over a hundred defined data points, submitted annually in xBRL-CSV format — documenting every contractual arrangement between a financial entity and its ICT third-party service providers.
Two full reporting cycles in, the evidence is unambiguous about how hard firms find it. In the ESAs' 2024 dry run, only 6.5% of nearly a thousand participating firms passed all 116 data quality checks. In the first live cycle, supervisors reported that at the majority of banks, 35–50% of contracts had at least one mandatory field missing or invalid. And the bar rises each year: validation rules applied in 2026 were explicitly stricter than the dry run's, with several national regulators warning that a register accepted in 2025 could be rejected in 2026.
This walkthrough covers what the register is, how the templates fit together, the annual cycle, the failure modes two rounds of submissions have exposed, and how to build a register that survives contact with a validator.
What the register is — and isn't
The RoI is not a vendor inventory, a risk register or a procurement database. It is a regulatory dataset with a specific supervisory purpose: giving the European Supervisory Authorities system-wide visibility of ICT dependencies across the EU financial sector. The aggregated data is the primary input for designating Critical ICT Third-Party Providers (CTPPs) under Article 31 — the 2025 registers fed the designation of nineteen CTPPs in November 2025 — and national competent authorities use it to supervise concentration risk at entity level. BaFin, for one, has been explicit that dependencies on US hyperscaler cloud providers are on its watch list, and that firms with significant exposure should expect questions about exit strategies.
Read that as the strategic framing: everything you submit becomes the lens through which your supervisor views your ICT estate. A sloppy register doesn't just risk rejection; it shapes the questions you'll be asked for years.
Scope is broader than firms often assume. The register must cover all contractual arrangements with ICT third-party service providers — not only those supporting critical or important functions — and must be maintained at entity level and, where relevant, sub-consolidated and consolidated levels. Intra-group ICT providers count. Subcontracting chains for critical or important functions must be documented. And the maintenance obligation is continuous: the register must be kept up to date at all times and provided to your NCA on request, not just at the annual submission.
The template structure
ITS 2024/2956 defines fifteen templates forming a relational data model across six logical layers:
- Entity layer — who is reporting: the financial entity (or entities, for consolidated reports), identified by LEI, with branch detail.
- Contractual arrangement layer — one record per arrangement (not per provider): reference numbers, contract type, start and end dates, notice periods, governing law, and the criticality flag.
- Provider layer — the ICT third-party service providers themselves: legal identifiers, headquarters location, and their position in any subcontracting chain.
- ICT service layer — what is actually being provided, classified against the ESA service-type taxonomy, with data-processing locations and storage detail.
- Function layer — the business functions each service supports, with the critical-or-important-function (CIF) assessment under Article 3(22) that drives the flags supervisors examine first.
- Sub-outsourcing layer — the chain beneath your direct provider for critical or important functions, with ranks linking each subcontractor to its position.
The templates are interdependent — a provider referenced in a contract record must exist in the provider template; a service must link to a function; criticality flags must agree wherever the same arrangement appears. That relational structure is precisely why errors cascade: one wrong identifier can fail referential-integrity checks across several templates at once.
The format: xBRL-CSV, and no room for creativity
Submissions are an xBRL-CSV report package: a metadata JSON file plus one CSV per template named to ESA conventions, referencing the published ESA taxonomy, zipped for upload. Coded fields accept only the prescribed vocabularies — ISO 3166 country codes, ISO 4217 currency codes, 20-character LEIs, ESA service-type codes. Free text where a code is expected is a rejection, not a style choice.
The practical traps are mundane and merciless. National regulators' guidance from the 2026 window reads like a museum of them: editing CSVs in Excel silently corrupts date formats (use a text editor); filenames must follow the convention exactly, with no spaces and unique timestamps; currency symbols anywhere in a CSV cause failures; boolean filing indicators are case-sensitive. Several NCAs also require portal roles to be assigned in advance — a submission can be blocked on deadline day simply because nobody holds the reporting permission.
The annual cycle
The rhythm is now established: the register snapshot reflects a 31 December reference date, national submission windows run through Q1, and NCAs consolidate onward to the ESAs by 30 April. Exact dates are set nationally and vary meaningfully — in the 2026 round, windows ranged from late February to the end of March across jurisdictions — so confirming your own NCA's window and channel early is part of the job. Most NCAs validate on receipt and return errors for correction within the window, which is why every regulator's guidance says the same thing: submit early, because a rejection at 5pm on deadline day leaves you nowhere to go.
The next reference date is 31 December 2026, with submissions due in Q1 2027 — which means the register your supervisor reads next spring is being written now, in the contracts you're signing and the data you're capturing this quarter. (UK-regulated firms: the FCA's separate material third-party reporting regime lands in the same quarter — see our March 2027 deadline guide. Same discipline, different template, and a copy-paste between the two will satisfy neither.)
The failure modes, from two live cycles
Supervisory feedback across the 2025 and 2026 rounds converges on a consistent list:
- Missing or invalid LEIs — implicated in roughly a third of first-cycle submissions. Smaller providers often have no LEI at all, which needs resolving with the provider months before the deadline, not discovering in February.
- Aggregating contracts by provider instead of one record per arrangement — structurally wrong, and it breaks the relational model.
- Over-conservative criticality classification — flagging arrangements non-critical to shrink reporting scope. Supervisors read a bank with no critical cloud dependencies as implausible on its face.
- Empty sub-outsourcing templates for major cloud providers — same problem: a hyperscaler with no documented subcontracting chain invites the question of whether you asked.
- Blank exit-strategy fields for critical arrangements — both a validation failure and a substantive Article 28 breach.
- Inconsistent reference dates and criticality flags across templates — the single most common trigger for supervisory follow-up.
And the newest development: NCAs now run automated cross-referencing between entities' registers. If two firms report the same provider inconsistently, or a provider visible in one register is absent from a peer's, the anomaly surfaces without a human ever reading your file.
A six-step build walkthrough
1. Fix the scope. Identify which group entities are in scope and whether you report at individual or consolidated level; confirm the NCA, channel and window. Errors here cascade through everything downstream.
2. Inventory everything. Compile every ICT third-party arrangement from every source you have — contract repositories, accounts payable, IT asset inventories, security tooling, business-owner interviews. At this stage completeness beats accuracy: you can correct data, but you cannot report what you haven't found.
3. Map functions and run the CIF assessment. Classify each arrangement against the Article 3(22) criteria and carry the flag consistently through every template it touches. This is the data supervisors examine first.
4. Extract and close the gaps. Pull the mandated fields from each contract. This is where firms discover missing LEIs, undefined notice periods, and governing law never made explicit — each gap needing a contract amendment, a provider conversation, or a documented and signed-off assumption.
5. Validate before your regulator does. Generate the xBRL-CSV package against the current ESA taxonomy and run the published validation rules internally. Errors caught in-house cost hours; errors caught by your NCA cost a resubmission cycle against a closing window.
6. Submit early, then keep it alive. File at the start of the window, retain the artefact, treat NCA feedback as a quality-improvement input — and then maintain the register continuously. New vendors, amendments and terminations should update it within your BAU vendor process, because the alternative is rebuilding it from scratch every January under deadline pressure.
The honest conclusion: this is a data engineering problem
Strip away the regulatory framing and the RoI is a relational dataset with referential integrity constraints, controlled vocabularies, a strict serialisation format and annually tightening validation — populated from contracts, procurement records and vendor conversations scattered across your organisation. Firms that treat it as an annual form-filling sprint keep landing in the 35–50% error statistics; firms that treat it as a living dataset with automated quality controls pass.
That is, unsurprisingly, how we built VANCE. The Agency's regulatory reporting lead assembles the register continuously from the RiskXchange platform's system of record — NOVA gathers the provider evidence and chases the missing LEIs, REX keeps the arrangement data current as your estate changes, and VANCE generates the validated, taxonomy-aligned output when the window opens. One customer's DORA reporting went from a quarter's work to a morning, with their first board pack produced in under an hour. If you'd rather your Q1 2027 submission were an export than a project, see how it works — pricing's on the page.
Frequently asked questions
What is the DORA Register of Information?
A machine-readable register of all contractual arrangements between a financial entity and its ICT third-party service providers, mandated by Article 28(3) of DORA and structured by ITS 2024/2956 as fifteen interlinked templates submitted annually in xBRL-CSV format.
Who must submit the Register of Information?
All financial entities in scope of DORA, at entity level and where relevant at sub-consolidated and consolidated levels. Following ESA Q&A guidance, third-country branches of in-scope entity types are also required to submit in a number of jurisdictions.
When is the Register of Information due?
The register reflects a 31 December reference date, with national submission windows through Q1 and NCA consolidation to the ESAs by 30 April each year. Exact windows are set nationally, so confirm your own NCA's dates — and submit early, as validation errors must be fixed within the window.
Does the register only cover critical or important functions?
No — all ICT third-party contractual arrangements must be included. The critical-or-important-function flag determines which arrangements need the deepest detail, including full sub-outsourcing chains and exit-strategy data.
What are the most common Register of Information errors?
Missing or invalid LEIs, aggregating contracts by provider rather than per arrangement, inconsistent criticality flags across templates, empty sub-outsourcing data for major cloud providers, blank exit-strategy fields, and format failures from editing CSVs in Excel.
Can the register be automated?
Yes — and given annually tightening validation and automated supervisory cross-referencing, continuously maintained, machine-generated registers are rapidly becoming the only sustainable approach. RiskXchange's VANCE produces taxonomy-aligned register output directly from live vendor data.
Last updated: July 2026. This walkthrough summarises DORA, ITS 2024/2956 and supervisory guidance for general information; it isn't legal advice, and firms should confirm requirements with their NCA.
Done reading? See it on your vendors.
Book a 30-minute call and we'll have NOVA, ARIA and REX produce a complete posture report on a vendor of your choice inside 24 hours.