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.

The register covers every contractual arrangement for the use of ICT services, not only the ones supporting a critical or important function.

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 services supporting critical or important functions, record the subcontractors that effectively underpin those services or material parts of them. This includes subcontractors whose disruption would impair security or service continuity. The register rules require a rank for each provider: the direct provider is rank 1, with subcontractors further down the chain.

The direct provider needs to supply this information; procurement records alone may not describe its hosting and support arrangements. Ask for the relevant chain and stable identifiers early, then check that the provider entries match the service and contract records.

EU-based providers that are legal persons can be identified by an LEI or EUID; non-EU legal persons use an LEI. Other identifier types are reserved for individuals acting in a business capacity, not companies that have no LEI. The EBA identifier guidance explains these distinctions.

Check the identifier type and value before linking a provider to contract records. A VAT number is not a general substitute for a company's LEI or EUID.

In Germany the register goes to BaFin. BaFin collects it once a year through its reporting platform MVP, with the contract data as of 31 December of the previous year, and the file has to pass validation by BaFin 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.

Several contracts can still depend on one provider. Before contracting ICT services for a critical or important function, Article 29 DORA requires an assessment of concentration and substitutability, including relevant subcontracting risks.

The register makes those relationships visible. The authorities also use collected registers to identify critical ICT providers. Cybersecurity in German finance and the DORA overview explain the broader risk requirements.

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. The format of the DORA register of information 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. The register covers contracts for ICT services, including arrangements that are not outsourcing. Non-ICT outsourcing is outside its scope. The BaFin explanation of the register distinguishes these categories. An institution should map its obligations for each arrangement instead of treating one register as a replacement for every outsourcing requirement. Outsourcing and cloud use in German banks covers the related rules.

A submission can fail technical or data-quality checks. Check identifiers, cross-template references and the permitted field values before filing. The EBA reporting resources include validation rules and sample feedback. Use the returned findings to distinguish a rejected file from an accepted file with issues requiring correction.

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.