Guide / DORA

Updated 25 May 2026

The DORA Register of Information, explained

The Register of Information is a structured record of every contractual arrangement an EU financial entity has with its ICT third-party service providers. DORA requires it to be maintained continuously and reported to your regulator in a machine-readable format. It is defined by an EU Implementing Technical Standard and is far more detailed than a GDPR subprocessor list.

Key facts

  • 01The Register of Information is mandated by DORA (Regulation (EU) 2022/2554), which has applied since 17 January 2025.
  • 02It records all contractual arrangements with ICT third-party service providers, structured by an Implementing Technical Standard (Commission Implementing Regulation (EU) 2024/2956).
  • 03It is reported to your national competent authority in a machine-readable format (xBRL-CSV), and authorities forward the registers to the European Supervisory Authorities.
  • 04For the 2026 cycle the reference date is 31 December 2025 and authorities forward to the ESAs by 31 March 2026 - but many national regulators set their own earlier cut-off.
  • 05It is broader and more granular than a GDPR subprocessor list: it captures contracts, the functions each provider supports, criticality, and subcontracting chains - not just vendor names.
§ I

What the Register of Information is

The Register of Information is a structured, continuously maintained record of every contractual arrangement an EU financial entity has with its ICT third-party service providers. It is one of the cornerstone obligations of the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), which has applied across the EU since 17 January 2025.

DORA exists because the financial sector now runs on outsourced technology - cloud platforms, data providers, payment rails, software vendors - and a failure at one widely-used provider can cascade across the whole system. The Register of Information is how supervisors get visibility into that dependency: every financial entity has to map its ICT third parties in a common format, so regulators can see concentration risk and designate the providers that are critical to the system as a whole.

§ II

Who has to maintain one

The obligation falls on the broad population of EU financial entities in scope of DORA:

  • -credit institutions, payment institutions, and electronic-money institutions;
  • -investment firms and crypto-asset service providers;
  • -insurance and reinsurance undertakings and intermediaries;
  • -fund managers, trading venues, and a long list of other regulated entities.

The register is maintained at entity level, and for groups at consolidated level as well. There are limited proportionality allowances for some small entities, but most regulated firms - including small EU fintechs that often assume DORA is a big-bank problem - are squarely in scope. Your national competent authority is the body that confirms your status and sets your filing channel.

§ III

What the register must contain

The structure of the register is fixed by an Implementing Technical Standard (Commission Implementing Regulation (EU) 2024/2956), which defines a set of linked templates rather than a free-form document. Between them, those templates capture:

  • -The entity maintaining the register, and the group structure where relevant.
  • -The ICT third-party providers themselves, identified consistently so regulators can aggregate across firms.
  • -Each contractual arrangement - its terms, duration, governing law, and termination provisions.
  • -The ICT services and functions each provider supports, and whether those functions are critical or important.
  • -The subcontracting chain behind each provider - the fourth parties your third parties rely on.

That last point is the one most firms underestimate: DORA cares not just about your direct providers but about who they depend on. Mapping that chain accurately, and keeping it accurate, is the heavy lifting of the register.

§ IV

Format, deadlines, and the link to your vendor list

The register is filed with your national competent authority in a machine-readable format - xBRL-CSV - not as a document; regulators publish Excel templates that convert into it. For the 2026 cycle, the reference date is 31 December 2025 and authorities forward the registers to the European Supervisory Authorities by 31 March 2026. The deadline that actually binds you, though, is usually earlier: national regulators set their own cut-off so they can validate and forward in time, and the validation rules tighten between cycles - a register accepted last year can be rejected this year.

The Register of Information is its own regime, distinct from GDPR Article 28. But the two share a root problem: both depend on an accurate, current inventory of who your third parties are and who sits behind them. A well-maintained subprocessor register is the same underlying data the DORA register is built from - so the discipline of keeping it fresh pays off in both directions.

FAQ

Frequently asked questions

Who has to maintain a Register of Information?
A wide range of EU financial entities in scope of DORA: credit institutions, payment and electronic-money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, fund managers, and others. The obligation sits at entity level and, for groups, at consolidated level too. There are limited proportionality carve-outs for certain small entities, but most regulated financial firms - including small EU fintechs - are in scope. If you are unsure, your national competent authority is the authority that confirms your status.
What does the register have to contain?
The Implementing Technical Standard defines a set of linked templates covering: the entity maintaining the register, the ICT third-party service providers themselves, each contractual arrangement, the ICT services provided and the business functions they support, whether those functions are critical or important, intra-group arrangements, and the subcontracting chain that sits behind each provider. The point is to give regulators a complete, comparable map of a financial entity’s ICT dependency - not just a list of vendor names but how each one is wired into the business.
How is the Register of Information different from a GDPR subprocessor list?
They overlap in the vendors they name but serve different regimes. A GDPR subprocessor list is a data-protection disclosure under Article 28: who processes personal data on your behalf, for what, and where. The DORA Register of Information is an operational-resilience filing: every ICT contractual arrangement, the functions it supports, its criticality, and the subcontracting chain, submitted to a financial regulator in a fixed machine-readable format. A cloud provider might appear on both, but the register asks far more about it, and your data-protection list does not satisfy the DORA obligation or vice versa.
What format and deadline applies?
The register is submitted to your national competent authority in a machine-readable format - xBRL-CSV - rather than as a free-form document; regulators also publish Excel templates that convert into it. For the 2026 reporting cycle the reference date is 31 December 2025, and national authorities forward the registers to the European Supervisory Authorities by 31 March 2026. Crucially, many national regulators set their own earlier submission deadline so they have time to validate and forward, so the date that binds you is your own authority’s, not the ESA backstop. Validation rules also tighten between cycles, so a register accepted one year can be rejected the next.
Does keeping a subprocessor page help with DORA at all?
It is the foundation, not the whole answer. The hardest, most error-prone part of the register is maintaining an accurate, continuously updated inventory of who your ICT third parties are and what sits behind them - and that inventory is exactly what a well-maintained, monitored subprocessor register gives you. It does not produce the regulatory filing on its own, but a current, monitored vendor inventory is the data the register is built from, and keeping it fresh year-round is what makes the annual submission tractable instead of a fire drill.

This guide is general information only and does not constitute legal advice. For advice on your specific situation, consult a qualified legal professional.

Your turn

Keep your subprocessor register current - automatically.

Registora hosts your register on your own domain, monitors every upstream provider for changes daily, and drafts the customer notification when one updates.