DORA Register of Information: Software & Templates

DORA Register of Information software automates the structured register of ICT third-party arrangements that every EU financial entity must maintain under Articles 28-30 and file to its competent authority in the EBA’s implementing technical standards (ITS) format — a rigid multi-table spreadsheet linking entities, ICT service providers, contractual arrangements, the functions they support and sub-outsourcing chains. A free template will get a small firm started; it stops working past roughly 50 ICT contracts, when referential integrity across the tables and the annual refresh overwhelm Excel. This page covers the actual ITS structure, when to move off spreadsheets, and which tools automate the annual submission.

DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025, and the first Register of Information collections have already run. If you need the conceptual grounding before the tooling, read the DORA Register of Information guide first.

Key Takeaways

• The Register of Information is filed in the EBA’s ITS format — a set of interlinked tables, not a free-form document.
• It must cover all ICT third-party arrangements, including sub-outsourcing and the functions each supports.
• Excel breaks past ~50 contracts because of cross-table referential integrity and versioning, not row count.
• Competent authorities collect the register annually; getting the format wrong triggers resubmission and scrutiny.
• Personal data inside those contracts also engages GDPR, so the same inventory feeds your processor records.

What the EBA’s ITS Structure Actually Requires

The Register of Information is not one list — it is a relational data model. The European Banking Authority coordinated the ITS on behalf of the three ESAs, and the template comprises multiple linked tables that must reconcile against each other. In practice you populate, at minimum:

Table area	What it captures
Entity information	The regulated entity(ies) maintaining the register
ICT third-party providers	Identity, LEI, country, provider type
Contractual arrangements	Each contract, dates, value, governing law
ICT services	The specific service and whether it supports a critical/important function
Function mapping	Business functions and their criticality
Sub-outsourcing chains	The chain of subcontractors behind a provider

The keys must match across tables: a contractual arrangement points to a provider, a service points to a contract and a function, a sub-outsourcing entry points up the chain. Break one identifier and the whole submission fails validation. This relational structure — not the number of rows — is what makes the register hard.

There is also a data-quality dimension that catches firms off guard. The template requires standardised values in many fields — legal entity identifiers (LEI) for providers, country codes, provider-type categories, function-criticality ratings — and the collection is validated against those controlled vocabularies. A provider without an LEI, a contract with an ambiguous governing law, or a function that nobody has formally rated as critical or important will each stall the submission. Gathering this data is not a compliance-team task alone; it pulls in procurement (for the contracts), IT and security (for the services and functions), and legal (for the sub-outsourcing terms). Coordinating those inputs once a year, by hand, across a spreadsheet with strict internal references, is the work that quietly consumes hundreds of hours — and it is exactly the work purpose-built software is designed to remove.

Why a Template Gets You Started, Then Breaks

A well-built template is genuinely useful for a small firm with a handful of providers. Below roughly 50 ICT contracts, a disciplined team can maintain the tables in Excel. Beyond that, four things break:

1. Referential integrity. Keeping identifiers consistent across six linked tables by hand invites errors that only surface at submission.
2. Sub-outsourcing depth. Cloud and SaaS providers bring chains of subcontractors; mapping them in flat sheets is fragile.
3. Versioning and the annual refresh. The register must be current and re-filed annually; last year’s spreadsheet is stale within months.
4. Multi-entity roll-up. Groups need per-entity registers plus a consolidated view — see the enterprise DORA software angle.

This is the same failure mode we document for manual privacy records — structured obligations rot in spreadsheets. For the underlying third-party obligations, see DORA ICT third-party risk management.

Software That Automates the Register

Legiscope — generates and maintains the Register of Information in the ITS structure, keeps identifiers consistent across tables, and produces the annual export, without a consultant. A strong fit for financial entities that need the register current and defensible without an enterprise GRC project.

Enterprise GRC (ServiceNow IRM, Archer, MetricStream) — full multi-entity register consolidation and concentration-risk analytics, at six-figure cost; the right call for significant institutions. Compared in our ranked best DORA compliance software list.

ICT TPRM specialists (Prevalent, ProcessUnity) — strong on third-party inventory and sub-outsourcing mapping, which is exactly the register’s hard part; lighter on the rest of DORA.

Template + spreadsheet — the free starting point; viable only below ~50 contracts and only with discipline.

Firm profile	Contracts	Suggested approach
Small PI / SME fintech	<50	Template, then Legiscope entry
Mid-sized bank/insurer	50-200	Focused platform or TPRM specialist
Significant institution / group	200+	Enterprise GRC with consolidation

For the full evaluation methodology across all five DORA pillars, use the DORA compliance software buyer’s guide.

The Register Also Feeds Your GDPR Records

Most ICT arrangements in the register involve personal data processing, which means the same providers appear in your Article 30 GDPR processor records. The EDPB’s guidance on controllers and processors (edpb.europa.eu) governs those contracts, so a tool that treats the ICT inventory and the processor inventory as one dataset removes duplicate work — the register you build for DORA is most of the mapping GDPR already required.

How to Prepare Your Data Before You File

Most of the pain in a Register of Information submission is not the tool — it is the state of the underlying data, and that work starts weeks before any filing window. Begin with a clean provider inventory. Every ICT third party needs a legal entity identifier; if a provider has no LEI, chasing one takes time you will not have in the final week, so front-load that request. Reconcile the provider list against procurement’s contract database and against what security actually sees running in production, because the three rarely match — shadow SaaS and expired-but-still-live contracts are the usual culprits.

Next, resolve the classification decisions the template forces on you. Each function a provider supports must be formally rated as critical, important or neither, and that rating cannot be improvised at submission time; it is a business judgement the relevant function owner should sign off. Map the sub-outsourcing chain for your material providers now, while you can still ask them, rather than discovering an undocumented fourth-party dependency during validation. Confirm governing law and contract dates against the signed agreements, not the CRM, since those fields are validated.

Finally, do a dry-run export and read it as an auditor would. Check that every contractual arrangement points to a real provider, every service points to a contract and a function, and every sub-outsourcing entry resolves up its chain — the cross-table keys are where submissions fail. Good software enforces this integrity continuously so the annual filing is a button, not a project; but even the best tool cannot invent an LEI or a criticality rating your organisation never decided. Prepare the data first, keep procurement, IT and legal aligned on it through the year, and the annual register files itself instead of consuming the hundreds of hours a manual reconciliation would.

FAQ

What is the DORA Register of Information?

It is the structured record, required by Articles 28-30 of DORA, of all contractual arrangements with ICT third-party providers — including the services, supported functions and sub-outsourcing chains — that financial entities must maintain and file to their competent authority in the EBA’s ITS template format.

Can I keep the Register of Information in Excel?

For a small firm with under about 50 ICT contracts, yes, using a disciplined template. The relational structure — identifiers that must reconcile across multiple linked tables — and the annual refresh make Excel fail beyond that, which is why most institutions move to software within one compliance cycle.

What format must the register be filed in?

The EBA’s implementing technical standards fix a multi-table template with cross-referencing keys. Submissions are validated against that structure, so a register that does not match the ITS format is rejected or returned for resubmission.

How often must the Register of Information be submitted?

Competent authorities collect it annually, and it must be kept current between filings. Because ICT arrangements change through the year, a static once-a-year spreadsheet drifts out of date quickly, which is the main argument for automation.

Conclusion

The Register of Information is a relational filing, not a list, and its difficulty scales with cross-table integrity and sub-outsourcing depth rather than row count. A template is a fine start below ~50 ICT contracts; past that, dedicated software keeps identifiers consistent, maps sub-outsourcing, and produces the annual ITS-format submission without manual reconciliation. Whichever tool you choose, validate it the honest way: export a complete register from your real contracts and check it passes the EBA’s format before a supervisor does it for you.