DORA register of information: how to build it, reconcile it and keep it current

What the DORA register of information is

Article 28(3) of the Digital Operational Resilience Act requires each financial entity to maintain and update a register of information covering all contractual arrangements on the use of ICT services provided by ICT third-party service providers. A group keeps it at three levels: for each entity, and at sub-consolidated and consolidated level. The same paragraph requires you to report to your competent authority at least yearly, to make the full register available when the authority asks for it, and to inform the authority in good time of any planned arrangement for a service that will support a critical or important function.

The European Banking Authority's preparation page states that from 17 January 2025 every financial entity in scope needed a comprehensive register available at all three levels. There was no grace period for building it after the application date.

This guide covers how to build the register and keep it trustworthy. The template structure, scoping rules and reconciliation checks are the subject of our companion guide, The register of information: templates, scope and reconciliation. It explains the texts, not legal advice; your competent authority and your own legal counsel have the final word on how the rules apply to you.

Why supervisors care about the register

The register is more than an internal list. On 15 November 2024 the three European Supervisory Authorities announced that competent authorities were to report the registers they collected by 30 April 2025, and that the first oversight activity would be the designation of critical ICT third-party service providers. On 18 November 2025 the ESAs published the first list of designated critical providers, 19 in all, built in part on the data financial entities supplied about their ICT service arrangements. Article 31(9) requires that list to be updated every year.

Two consequences follow. First, errors in your register flow into a European dataset; the EBA published an explanation of the data-quality feedback it returned on registers in February 2025, and has issued draft validation rules and a reporting FAQ, first issued in February 2025 and updated twice in March. Second, your authority reads your register as evidence of how well you know your own dependencies. A register that lists a cloud platform under one name in procurement, another in finance and a third in the ICT inventory tells the supervisor that the third-party framework does not yet work.

Building the register: a practical sequence

Most firms that struggle start with the template and try to fill it. It works better the other way round: assemble clean source data, agree who owns each part, then map it to the template fields. The sequence below is the one Sterling's consultants use; the order matters more than the tool.

Step 4 is where time goes. The register asks which functions each ICT service supports, and that answer depends on work that sits in the ICT risk management framework rather than in procurement. If the function list is not settled, the register cannot be.

Step 5 connects to the Article 30 contract terms and to Delegated Regulation (EU) 2025/532 on subcontracting; our guide DORA for ICT providers: the Article 30 contract terms covers what the contracts must say. Here the point is simpler: if the contract does not oblige the provider to tell you about its subcontractors, you will struggle to record them.

Making the register reconcile

A register reconciles when the same arrangement looks the same from every direction. In practice that means three checks run together.

• Money to contracts. Every recurring ICT payment in the ledger maps to a register entry, or has a recorded reason why it does not (for example, a one-off purchase that is not an ongoing ICT service).
• Contracts to inventory. Every arrangement in the register points to services and assets in the ICT inventory, and every externally supplied asset in the inventory points back to an arrangement.
• Functions to arrangements. Every critical or important function shows the ICT services it relies on, so that concentration on a single provider is visible, which the concentration risk assessment of Article 29 needs.

Differences are normal the first time. The records that satisfy a supervisor are the reconciliation itself, the list of differences found, the decision taken on each and the date it was closed.

Keeping the register current

Article 28(3) uses the words maintain and update, and the yearly reporting line assumes the register is right on any given day, not only in the weeks before submission. The simplest way to achieve that is to make the register a step in processes that already exist, rather than a separate annual project.

Build it into the contract lifecycle

Add a register update to the approval workflow for new ICT contracts, renewals, material amendments, novations after a provider is acquired, and terminations. If a contract can be signed without the register being touched, the register will drift.

Set triggers outside procurement

• A change to the list of critical or important functions, which may change the classification of existing services.
• A provider disclosing a new subcontractor or a new data or processing location.
• A group restructuring, a new entity coming into scope or an entity leaving it.
• An ICT-related incident that reveals a dependency nobody had recorded; the major ICT-related incidents guide explains the reporting side.
• A new annual list of designated critical providers, so that designated providers are flagged in your records.

Review it on a schedule

Run the three reconciliation checks at least quarterly, and in full before each annual submission. Record who reviewed the register, what changed and which differences remain open. That record belongs with the yearly review of the ICT risk management framework that Article 6(5) requires.

Where registers usually go wrong

• Only large contracts are listed. Article 28(3) covers all contractual arrangements for ICT services, not only those supporting critical or important functions; the extra detail for those functions is on top, not instead.
• Providers are recorded by brand. The same provider appears under several names, so concentration is understated.
• Functions are guessed by procurement. The mapping of services to functions is written without the function owners, and it contradicts the business continuity work.
• The register is outsourced and forgotten. Article 28(1)(a) leaves the financial entity fully responsible, whoever does the work.
• The certificate is taken as proof. An ISO/IEC 27001 supplier register helps, but a certificate does not produce a register in the DORA template; see DORA vs NIS2, ISO/IEC 27001 and ISO 22301.

DORA register of information: questions buyers ask