The DORA register of information

Article 28(3) of DORA, Regulation (EU) 2022/2554, requires each financial entity to maintain and update a register of information on all contractual arrangements for the use of ICT services provided by ICT third-party service providers, at entity level and, where applicable, at sub-consolidated and consolidated level.

The format is not left to the firm. Commission Implementing Regulation (EU) 2024/2956 sets the standard templates, 15 of them, each with a code such as B_01.01 for the entity maintaining the register, B_02.01 for the contractual arrangements and B_05.01 for the providers. They are relational: a contract references a provider by its identifier and a function by its own key, so a missing identifier breaks every row that points at it.

Beyond the names and dates, four groups of fields carry the supervisory content. The function fields say which business function the service supports and whether that function is critical or important. The service fields name the ICT service type from a fixed taxonomy and the countries where the data is stored and processed. The contract fields carry the start and end dates, the notice period, the governing law and the annual expense or estimated cost.

The fourth group is the assessment. The register records whether the provider is substitutable and how difficult substitution would be, whether an exit plan exists, the date of the last audit, and whether alternative providers were identified. These are judgments the firm has to be able to defend, and they are the fields an examiner compares against what the business actually says about the provider.

All of them. The register covers every contractual arrangement for the use of ICT services, not only the ones supporting a critical or important function, which is the first thing firms get wrong when they map an existing outsourcing register onto the new one.

What the criticality assessment changes is the depth. For a service supporting a critical or important function the register demands the subcontracting chain, the substitutability assessment and the exit arrangements; for the rest the entry is shorter. Under Article 28 a firm assesses criticality itself, and under DORA Article 30 the contract for a critical or important function has mandatory contents, which ICT third-party risk management sets out.

For a service supporting a critical or important function the register has to show the chain of ICT subcontractors that effectively supports it, with the rank of each link. A cloud provider running on another provider's infrastructure, a software vendor hosting at a hyperscaler, a processor using an offshore support desk: each one is a row, with its own identifier and country.

This is the part firms cannot complete from their own records, because the information sits with the provider and arrives late or not at all. The European Supervisory Authorities reported on the dry run exercise they ran before the first collection and found the recurring defects in exactly these areas: identifiers, the templates' relational integrity and the subcontracting data. A chain that stops at the first provider is the most common reason a file comes back.

Providers are identified by their Legal Entity Identifier. The reporting rules make the LEI the key that links a provider row to every contract row, so a provider without one cannot be entered the ordinary way. Small vendors, public bodies and non-EU support entities are the usual cases, and a firm that waits for the provider to obtain an LEI misses the window.

The rules provide for the European Unique Identifier for EU-registered companies and for a small set of other identifier types, and the practical route is to clear the identifier question for every provider months before the submission. An identifier invented for the file is worse than a late one, because it links to nothing and makes the provider look new every year.

In Germany the register goes to BaFin. BaFin collects it once a year through its reporting platform MVP, with the contract data as of December 31 of the previous year, and the file has to pass BaFin's validation without errors by the stated deadline. A rejected file comes back with an error log and goes in again, which is why firms treat the validation rules as part of the data model and not as a formality.

BaFin passes the registers to the European Supervisory Authorities, which use them to designate the critical ICT third-party providers for the whole EU financial sector. A firm's register therefore has an effect beyond its own supervision: it is one of the inputs that decides which providers get an EU oversight regime of their own.

The register is the data set the concentration analysis runs on. Article 29 of DORA requires a firm to assess, when it enters a contract for a critical or important function, whether the arrangement adds to concentration, including through subcontracting, and whether a provider is substitutable.

At entity level the question is how much of the firm's critical estate rests on one name. Across the sector the authorities ask the same question with every register combined, which is how a provider nobody considered systemically important becomes a designated critical provider. Cybersecurity in German finance and what DORA is cover the surrounding picture.

The DORA register of information is a structured record of every contractual arrangement a financial entity has for the use of ICT services, kept under Article 28(3) of Regulation (EU) 2022/2554 and filed with the national supervisor once a year. Its format is fixed by Commission Implementing Regulation (EU) 2024/2956 in 15 relational templates covering the entity, its providers, the contracts, the functions supported and the subcontracting chains.

No. An outsourcing register under German law covers outsourced functions and is driven by materiality; the register of information covers all ICT service contracts regardless of criticality and has a fixed EU data model. The notification duties for outsourcing did not disappear either, so a German institution keeps both, and BaFin still wants ICT outsourcing reported through its own notification procedure. Outsourcing and cloud use in German banks covers that side.

Because the file fails a validation rule, not because a supervisor disagreed with a judgment. The recurring causes are a missing or invalid provider identifier, a contract row referencing an entity or function that does not exist in its template, a subcontracting chain that stops at the first provider, an ICT service type outside the permitted taxonomy, and inconsistent criticality flags between the function and the contract that supports it.

One function owns the file and the deadline, usually ICT risk or the outsourcing officer, while the content comes from procurement for the contracts, IT for the services and legal for the governing law and the notice periods. The management body carries the responsibility for ICT risk under DORA and therefore for the register. A register assembled once a year from four sources that do not reconcile is the version that produces an error log.