Register of Information: What DORA Article 28(3) Requires

The register of information is the DORA deliverable that turns ICT third-party risk from an internal discipline into a supervisory one. It is also routinely underestimated, because “register” sounds like a spreadsheet and Article 28(3) asks for considerably more than that.

Four separate obligations sit in a single paragraph, and the ones organisations miss are not the ones about building it.

What Article 28(3) actually requires

Article 28(3) requires financial entities, as part of their ICT risk management framework, 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.

Three phrases in that sentence do the work.

“All contractual arrangements.” Not the critical ones, not the material ones — all of them. The criticality distinction comes later and governs how they are documented, not whether they appear.

“At entity level, and at sub-consolidated and consolidated levels.” A group cannot satisfy this with one flat list. The register has to exist at each level, which is a data modelling problem before it is a compliance one.

“Maintain and update.” It is a live record. A register assembled for a submission and left alone until the next one does not meet the wording.

The distinction that drives the register of information

The second subparagraph requires contractual arrangements to be appropriately documented, distinguishing between those that cover ICT services supporting critical or important functions and those that do not.

That classification is the spine of the whole DORA third-party regime. It determines contractual content, exit planning, testing expectations and supervisory attention — and it is decided in the register.

Which makes the register of information a governance artefact, not an inventory. If your criticality determinations live in someone’s judgement rather than in a recorded, defensible assessment, the register documents a decision nobody can explain.

The register of information reporting obligation people miss

Financial entities shall report at least yearly to the competent authorities on:

• the number of new arrangements on the use of ICT services;
• the categories of ICT third-party service providers;
• the type of contractual arrangements; and
• the ICT services and functions being provided.

“At least yearly” is a floor, not a schedule. And note what is being reported: change over the period, provider categories and service types — which is only extractable if the register carries those attributes consistently from the start. Retrofitting a taxonomy across hundreds of arrangements the month before a submission is where these programmes fail.

Two obligations that are not periodic at all

On request. Financial entities shall make available to the competent authority, upon its request, the full register of information or specified sections, along with any information deemed necessary to enable effective supervision. There is no notice period in the text. The register must be in a producible state continuously.

In advance. This is the sentence most often overlooked. Financial entities shall inform the competent authority in a timely manner about any planned contractual arrangement on the use of ICT services supporting critical or important functions — as well as when a function has become critical or important.

Read that twice. Two separate triggers, both forward-looking:

• You are contemplating a new arrangement for a critical or important function — tell the regulator before, not at the next reporting cycle.
• An existing function becomes critical or important — tell them then, even though no contract changed.

The second trigger has no natural owner in most organisations. Nobody is watching for the moment a previously routine service becomes critical, and there is no procurement event to prompt it. That is a monitoring control you have to build deliberately.

The register of information templates are prescribed

You do not get to design the format. Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024 lays down the implementing technical standards for the application of DORA with regard to standard templates for the register of information.

That matters more than it sounds for a register of information programme. A prescribed template means the fields, relationships and identifiers are fixed — so the question is not “what should we record?” but “can our contract and asset data populate these fields?” Most of the effort in a register programme is reconciliation: matching legal entities, provider identifiers, contracts and the functions they support across systems that were never designed to join up.

Where the register of information sits in DORA

Where to start with the register of information

1. Work from the prescribed templates first. Design your data model to populate 2024/2956, not to a format of your own.
2. Fix entity identifiers early. Entity, sub-consolidated and consolidated levels means the same provider and contract must resolve consistently across the group.
3. Record the criticality assessment, not just the conclusion. The distinction drives the rest of the regime and will be challenged.
4. Build the taxonomy before the volume. Provider categories, contract types and service types are what the yearly report is drawn from.
5. Create an owner for the “has become critical” trigger. It has no procurement event to prompt it and no natural home.
6. Keep it continuously producible, because the on-request obligation has no lead time.

This guide reflects Regulation (EU) 2022/2554 and Implementing Regulation (EU) 2024/2956 as published on EUR-Lex, read at 16 August 2026. Competent authorities publish their own submission arrangements — confirm yours.

The DORA Toolkit provides 100+ editable templates covering the ICT third-party risk framework, the register of information structure, the pre-contractual assessment and criticality determination, and the contractual and exit documentation DORA expects.