Published on · Facts reviewed by
What the register is for
The register has three readers, and each one shapes a requirement. The financial entity itself uses it as the backbone of its ICT third-party risk strategy: which services it depends on, through which contracts, for which functions, with what fallback. The competent authority uses it for supervision: Article 28(3) obliges the entity to make the full register available on request and to report, at least yearly, the number of new arrangements, the categories of providers, the types of contracts and the services and functions they support. The European Supervisory Authorities use the consolidated registers to designate the critical ICT third-party providers that fall under their direct oversight (Article 31).
Because the third reader aggregates registers across the Union, the format is not the entity’s to choose. Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024 lays down the templates, the identifiers and the closed lists every register uses, so that a cloud provider named by two hundred entities is counted once. That is why identifiers, not narratives, are the heart of the exercise.
What goes in: the templates
The standard organises the register as linked tables rather than one spreadsheet, each keyed by an identifier that the other tables reference. Read together they answer one question: which legal entity relies on which ICT service, under which contract, from which provider and its subcontractors, for which function, with what criticality and what exit. The families of templates are the following.
- The entities: the entity maintaining the register, every financial entity the register covers (at consolidated level, the whole group), and the branches.
- The contractual arrangements: a unique reference number per arrangement, its type (standalone, master agreement, subsequent or associated arrangement), the linked arrangements, start and end dates, notice periods for the entity and for the provider, governing law, the country of provision, the storage and processing locations, the sensitivity of the data, and the level of reliance on the service.
- The parties: the entities signing each arrangement, the ICT third-party providers signing it, and the entities that make use of the service, which is not always the signatory.
- The providers: each ICT third-party provider with its identifier (a Legal Entity Identifier, or a European Unique Identifier for EU companies), its country, its type of person, its ultimate parent, and the currency of the annual expense.
- The supply chain: for each service, the provider at rank 1 and the subcontractors at rank 2 and below that effectively underpin the service, which is where the critical or important functions demand depth.
- The functions: the identifier of each function, the licensed activity it belongs to, whether it is critical or important, the reasons, the impact of a discontinuation, and the recovery time and recovery point objectives.
- The assessment of the services: substitutability of the provider, reintegration possibility, existence of an exit plan, the date of the last audit, and the alternative providers identified.
Identifiers: the part that fails first
A register is rejected by the authority’s validation long before anyone reads its content. The usual causes: a provider without a Legal Entity Identifier or with an expired one, a contract reference reused across two arrangements, a function identifier that differs between the functions template and the arrangements template, a service type outside the standard’s closed list, a country in the wrong code system, a currency missing on an expense. The standard’s closed lists (types of ICT services, types of arrangements, reasons for criticality, sensitivity levels) leave no room for local vocabulary, and the ESAs’ data-quality checks on the collected registers treat a mismatch as an error, not a nuance.
The remedy is to decide the identifiers before the inventory starts. One naming rule for arrangement references that survives renewals, one table of functions signed off by the business continuity owner, the LEI of every provider requested at onboarding and renewed yearly, and one translation table from the entity’s service catalogue to the standard’s service types. The inventory then fills a structure that already validates.
Six steps to build it
The register is built from the functions down, not from the contracts up: a contract only matters for the functions it supports, and criticality is a property of the function.
- Fix the scope of entities. List the financial entities and branches the register covers, decide the level (entity, sub-consolidated, consolidated) each report is made at, and name the entity that maintains it. A group builds one register and slices it per authority.
- List the functions and grade them. Start from the business impact analysis: every function, its licensed activity, whether it is critical or important under Article 3(22) (a function whose disruption would materially impair financial performance, the soundness or continuity of services, or the compliance with authorisation conditions), the recovery objectives. This table is the register’s spine and it needs a business owner’s signature.
- Inventory every ICT service contract. Not the critical ones, all of them: cloud, software as a service, data feeds, managed services, outsourced operations, intra-group services. Article 3(21) defines ICT services broadly, as digital and data services provided through ICT systems on an ongoing basis, and the register covers them all, flagging those that support a critical or important function.
- Resolve the providers and their chain. For each contract, the signing provider with its identifier and ultimate parent, then the subcontractors that effectively underpin the service, at rank 2 and below, with the same identifiers. For critical or important functions the chain must be known; for the others, the provider at rank 1 is the minimum.
- Fill the assessment fields. Substitutability, reintegration, exit plan, last audit, alternative providers: these are risk judgements, not data entry, and they belong to the third-party risk function with the contract owner. A field left empty is a finding the supervisor will read as such.
- Consolidate, validate, submit. Assemble the templates at the reporting level, run the standard’s validations (keys that resolve, closed lists, dates that order), then file with the competent authority in the format it prescribes, in France the ACPR or the AMF depending on the entity, and keep the version filed.
Keeping it alive
The register is a living record, and DORA reads it that way: a new arrangement, a renewal, a change of subcontractor or a termination changes the register the day it happens, and the yearly report counts the year’s changes. For arrangements that support critical or important functions, Article 28(8) also asks the entity to inform the authority in a timely manner of planned arrangements and of any material change, which presupposes that the register knows about the contract before it is signed. The practical consequence is that the register cannot be a yearly spreadsheet campaign; it has to sit where contracts, suppliers and functions are managed, and be fed by the events that change them.
That is also where it becomes useful beyond compliance. A register that knows the chain of subcontractors is the first input to concentration risk (Article 29): how many critical functions depend on one provider, one region, one hyperscaler at rank 2. A register that knows the exit plans is the test of the exit strategy DORA requires for critical functions. And a register that carries the last audit date is the calendar of the assurance program.
Where the register meets NIS2
Financial entities apply DORA rather than the NIS2 measures, so the register has no NIS2 twin. Its logic does travel: NIS2’s supply-chain security measure asks essential and important entities in the other sectors to know their direct suppliers and the risks they carry, and the register’s structure, functions first, then contracts, providers and chain, is the sound way to do it. Groups that hold both a bank and an industrial subsidiary tend to keep one supplier inventory and produce the DORA templates from it.
What Mindlapse does with the register
On the platform the register is the supplier hub read through the DORA templates: suppliers with their identifiers and chain, contracts with their dates and clauses, functions with their criticality, and the assessment fields kept current by the third-party risk workflow rather than by a campaign. Each supplier carries a Trust Grade that moves with its signals, and the export produces the templates the authority expects. The DORA use case page and the third-party risk module walk through it pillar by pillar.