Building your DORA Register of Information.

What the register is

Article 28(3) of Regulation (EU) 2022/2554 requires financial entities to maintain and update, at entity level and at sub-consolidated and consolidated levels, a register of information covering all contractual arrangements for the use of ICT services provided by ICT third-party service providers. The register is reported to the competent authority at least yearly and made available on request.

Commission Implementing Regulation (EU) 2024/2956 supplies the shape. It sets out standard templates in Annexes I to IV together with completion instructions, and requires financial entities to use them. The practical effect is that the register stops being an internal artefact and becomes a supervisory dataset with a fixed structure, controlled vocabularies and machine validation.

The fifteen templates

The Implementing Regulation defines fifteen templates. They cluster into eight subject groups, and reading them as groups rather than as fifteen separate forms is the single most useful shift a project team can make.

How the templates link

The templates form a relational model. Each row is identified by a key, and other templates refer to that key rather than repeating the data. A contractual arrangement is entered once and then referenced by the service rows, the signatory rows and the function-mapping rows. A provider is entered once and referenced wherever it appears in a supply chain.

This is why a change in one place propagates. Renaming a provider, correcting a legal entity identifier or splitting one arrangement into two does not touch a single row — it changes every row that pointed at the old key. Registers built as fifteen independent spreadsheets fail at exactly this point, because nothing enforces the references between them.

A build sequence that works

Populating the templates in the order they appear in the Annexes creates rework, because the later templates define the keys the earlier ones need. A sequence that holds up in practice runs from the stable data outwards.

1. Fix the entity perimeter. Decide which financial entities are in the register and at which level, and settle their identification codes before anything else.
2. Map functions and criticality. The critical-or-important determination drives how much of the supply chain has to be documented, so doing it late means re-opening provider work.
3. Inventory arrangements, then providers. An arrangement is the contractual unit; a provider may sit under many arrangements. Allocate arrangement keys and provider identifiers once, centrally.
4. Decompose arrangements into services. One contract commonly delivers several ICT services with different types, locations and dates. This is where most registers grow unexpectedly.
5. Attach the supply chain. Rank subcontractors supporting critical or important functions, following the chain as far as the Implementing Regulation requires.
6. Complete assessments and links. Substitutability, exit arrangements and reintegration, then the mapping rows that tie services to functions.
7. Validate, then reconcile. Machine validation first, then a reconciliation against contract and finance records to catch arrangements that exist in one system and not the other.

Entity, sub-consolidated and consolidated

The Implementing Regulation addresses the scope of the register at sub-consolidated and consolidated level separately from entity level. A group therefore produces more than one register, drawn from one dataset, with the entity perimeter and the consolidation scope differing between them. Building three independent registers is the expensive way to do this; building one dataset with a scope flag is not.

Keeping it current

The obligation is to maintain and update, not to produce once a year. Between reporting reference dates, three events change the register: a new or amended arrangement, a change in the criticality of a function, and a change in the supply chain supporting a critical or important function. Each has an owner outside the reporting team — procurement, the business, and the provider respectively — which is why registers decay quietly unless those three feeds are wired in.

Reporting reference dates and submission dates are set by your competent authority and differ across the Union. Confirm yours with the authority rather than inferring it from another jurisdiction’s timetable.

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.