What the register is for, from the supervisor's side
The register supports your own third-party risk management and aggregation by supervisors.
The European Supervisory Authorities collect registers through national competent authorities and use the aggregate to see which ICT providers the European financial sector actually depends on. That is not a theory about the file format. On 18 November 2025 the ESAs published the first list of designated critical ICT third-party service providers, and they were explicit that the exercise began with data collected from the registers of information maintained by financial entities.
Use the identifier and type required by the template. EU legal-person ICT providers may use a valid active LEI or EUID; non-EU legal persons use LEI. Natural persons acting in a business capacity have specified alternatives. Supply both LEI and EUID where required and available. Follow the authority’s current technical package rather than inventing columns or a submission format.
Article 28(3) also asks for something that is not the annual file. You must inform the competent authority in good time about a planned arrangement covering ICT services that support a critical or important function, and about a function that has become critical or important. That one catches organisations out, because it is event-driven and nobody owns it.
One point for small entities specifically. The simplified ICT risk-management framework in Article 16 disapplies Articles 5 to 15 for small and non-interconnected investment firms, exempted payment and e-money institutions and small IORPs. Article 28 is not in that list. The register is not part of the relief.
Fifteen tables, and the links between them
The structure is relational, which is the part that surprises people who were told to fill in a spreadsheet. A contractual arrangement in one template is referenced by a key in another. A provider identified in one table must be the same provider referenced everywhere else. The most common class of error follows directly: a reference pointing at a record that does not exist in another template. Nothing is missing in a way you would notice by reading; the join is broken.
Two scoping rules are worth memorising, because they save work. Direct providers are all in scope. Subcontractors are in scope only where they effectively underpin ICT services supporting critical or important functions, or material parts of them — you do not owe the supervisor a map of the whole internet. And ranking in the supply chain is fixed: the direct provider is always rank 1, a subcontractor is always higher than 1.
| Block | What it holds | Usual source inside the company | Most common defect |
|---|---|---|---|
| B_01.01–B_01.03 | The entity keeping the register, the entities in scope of consolidation, the branches | Legal, corporate secretary | Branches left out; the entity's own LEI lapsed at GLEIF |
| B_02.01 | Contractual arrangements: general references, type, currency and annual expense or estimated cost | Contract archive | Check the template’s field and applicability rules |
| B_02.02 | Specific information on ICT service arrangements, including dates, notice, law and locations; not limited to critical functions | Legal plus finance | Check the template’s field and applicability rules |
| B_02.03 | Intra-group contractual arrangements | Group, parent entity | Omitted entirely because "they are us" |
| B_03.01–B_03.03 | Who signed: your entities, the provider, and entities providing services to others in the group | Legal | The signing entity confused with the entity that uses the service |
| B_04.01 | Which of your entities actually uses each ICT service | Business owners | One line for the group where three subsidiaries each use the service |
| B_05.01 | The ICT third-party service provider itself | Procurement, vendor management | The same supplier entered three times under three names |
| B_05.02 | The ICT service supply chain, with ranks | Provider questionnaires | Rank 1 filled in, nothing behind it, for services that are plainly resold |
| B_06.01 | Functions and their criticality assessment | Risk, business continuity | "Critical" asserted with no written method and no assessment date |
| B_07.01 | Assessment of ICT services supporting critical or important functions | Risk plus IT | Check the template’s field and applicability rules |
| B_99.01 | Entity-specific definitions and explanations where applicable | Nobody, usually | Check the template’s field and applicability rules |
Where it actually goes wrong
The ESAs’ 2024 dry run identified data-quality problems across submitted registers. Treat that exercise as evidence that validation needs time, not as proof that a particular failure pattern describes every current register.
Identifiers that must be consistent and are not. LEI is checked against GLEIF, so an LEI that lapsed because nobody renewed it fails, and a national company number typed into the LEI field fails. Then there is the harder version: a subcontractor three levels down whom you must identify and with whom you have no contract, no contact and no reason to be in their systems. You have to ask your direct provider, in writing, and keep the answer.
Criticality decided by a method nobody wrote down. DORA defines a critical or important function in Article 3(22) by the effect of its disruption. Delegated Regulation (EU) 2024/1773 requires your policy to establish or refer to a methodology for determining which ICT services support such functions, and to say when that assessment is made and reviewed. In practice the register is often the first place the criticality flag is written, by whoever is filling in the file, on the afternoon it is due. The flag then drives contractual requirements, exit planning and reporting. Write the method first, even if it is one page.
The same supplier, three times, under three names. Legal name in the contract, trading name in the IT inventory, whatever the invoice says in the ledger. Reconcile on identifier and identifier type, including additional identifiers where available; do not merge solely on a trading name.
Contracts that exist in procurement but not in the register. Auto-renewing SaaS bought on a card, a tool a team adopted and expensed, a service that arrived as part of a larger deal. Scope is decided by whether it is an ICT service, not by whether it was material enough for anyone to notice.
Intra-group arrangements omitted. There is a dedicated template for them. If the group's shared service centre runs your core platform, that is an ICT service under a contractual arrangement, and the fact that everyone shares a parent is not a scope exclusion.
Data in five systems owned by four departments. Contracts in legal, spend in finance, the real list of systems in IT, function ownership in the business, criticality in risk — never reconciled, because nothing had ever forced a reconciliation. That is the honest reason the first register takes months and the second takes days.
What you can reuse, and what you have to do by hand
Genuinely reusable: the contract archive gives you reference numbers, parties, dates, notice periods and governing law. The accounts-payable ledger finds the arrangements legal never saw — run it against the contract list and the gap is your missing-contracts report. The asset inventory gives you what is actually running. A business impact analysis kept for continuity purposes already contains functions and an implicit criticality view. Your GDPR processor records overlap heavily with the provider table and usually carry the correct legal entity name and locations.
Automate mechanical checks where possible: LEI lookup against GLEIF, allowed values, missing keys and cross-template references. Human owners still need to validate business meaning, criticality and the service-to-function mapping. Obtain missing supply-chain evidence through the direct provider, as described in the supplier-to-a-bank guide. A tool can reconcile data; it cannot make an unsupported business classification reliable.
The submission itself
Check the current reporting instructions of your competent authority, including scope, reference date, format, validation and cut-off. An annual collection exercise is not the only reason the underlying register needs updating.
The FSC’s 5 March 2026 notice illustrates the distinction between national and European dates: the ESAs’ production collection window ran from 25 February to 31 March 2026; the FSC asked supervised entities to provide registers by 23 March to allow forwarding, with corrections to the ESAs through 30 April. Those are historical cycle dates, not the deadline for your next submission.
Retain the submitted version, validation output, acknowledgement and corrections. Assign an owner to resolve rejected records and maintain the source data after filing.
What to do first
- Reconcile the contract archive, payments and live service inventory. Investigate differences; not every payment is itself an ICT service arrangement.
- Establish provider identifiers and their types, keeping evidence of the correct legal entity.
- Approve the criticality methodology and apply it to the relevant functions and services.
- Obtain the required subcontracting-chain information through direct providers.
- Run the current validation rules and check the business meaning of the results.
- Own event-driven updates and notifications, including planned arrangements supporting critical or important functions.
The DORA evidence guide links the register to contracts, tests, decisions and exit planning.
If a submission is rejected, the worked validation example shows how to trace the error to its source and document the correction.
The boundary
Passing validation means your file is well-formed. It says nothing about whether your third-party risk management is adequate, and a clean register sits comfortably alongside a bad contract. The contractual requirements in Articles 28 and 30, exit strategies and testing are separate obligations with separate evidence. Whether a particular arrangement is in scope, and whether your entity qualifies for the Article 16 simplified framework, depends on your licence and is a question for your competent authority and your counsel. If you also fall inside the national cybersecurity regime, the interaction is covered in the pillar on DORA and NIS2 and in the note on NIS2 in Bulgaria.
If you want the register built once, properly, and handed over with the reconciliation behind it, that is the DORA work we do for financial entities.
General information, not legal advice. What applies to you depends on your entity, activity, licence, size, group structure and the national implementation.