REGISTER OF INFORMATION STEP BY STEP

What the register of information is and what supervisors use it for

The register of information is a structured record of contractual arrangements on the use of ICT services. The duty to maintain and update it follows from Article 28(3) of Regulation (EU) 2022/2554 (DORA) and covers all contractual arrangements on ICT services provided by third-party service providers, not only those supporting critical or important functions. It is maintained at three levels: at entity level and at sub-consolidated and consolidated level.

The format is not left to the entity. The standard templates are set by Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024, published in the Official Journal on 2 December 2024 and adopted under the empowerment in the second subparagraph of Article 28(9) of DORA. It has seven articles and four annexes; under Article 7 it enters into force on the twentieth day following publication and sets no separate date of application.

Why supervisors go into this much detail is explained by Article 31(10) of DORA. Competent authorities transmit the reports referred to in the third subparagraph of Article 28(3) on an annual and aggregated basis to the Oversight Forum, which uses them to assess the dependency of financial entities on ICT third-party service providers. The register is therefore not merely an internal inventory: it is an input to the process in which critical providers are designated. Hence the emphasis on machine-processable identifiers and on closed code lists — data from different entities has to be comparable.

Besides maintaining the register itself, Article 28(3) attaches three further duties to it that are easy to miss: to report to the competent authorities at least yearly the number of new arrangements, the categories of providers, the type of contractual arrangements and the ICT services and functions provided; to make available upon request the full register or specified sections of it, together with any further information necessary for effective supervision; and to inform the authority in good time about any planned arrangement on services supporting critical or important functions, as well as about a function having become critical or important.

• Scope: all arrangements on ICT services. Narrowing this down to critical providers only does not follow from the text of Article 28(3) or from the implementing regulation. Under the second subparagraph, arrangements are documented distinguishing between those covering services supporting critical or important functions and those that do not — the distinction is therefore made inside the register, not by filtering at the entrance.
• Three levels of maintenance. Entity level, sub-consolidated and consolidated. Under Article 6 of the implementing regulation, a register maintained at sub-consolidated and consolidated level covers all financial entities and ICT service providers within the group that are part of the sub-group and the group.
• The reporting duty is not the same as handing over the register. What is reported yearly is the summary under the third subparagraph of Article 28(3); the register in whole or in part is made available upon request of the competent authority under the fourth subparagraph.
• Planned arrangements are reported in advance. The fifth subparagraph requires timely information about any planned arrangement on services supporting critical or important functions — that is, before it appears in the register as an existing contract.
• The register lives with changes in functions. Information is also required where a function only becomes critical or important later. Reclassifying a function has an effect on several templates at once.
• Data quality is prescribed. Article 3(4) of the implementing regulation names six principles: accuracy, completeness, consistency, integrity, uniformity and validity. Under Article 3(3) the data is reviewed regularly and any errors or discrepancies detected are corrected promptly.

How the register is submitted in the Czech Republic and what dates the supervisor sets is described in the section on the supply chain in the DORA guide in this category. The implementing regulation itself sets no periodic deadline for submission — the filing date is a matter of the supervisory process, not of the text of the standard.

What goes into the register and which subcontractors are not in it

The most important sentence of the whole implementing regulation is Article 3(2), and it is asymmetric. The register contains, on the one hand, the relevant information on all ICT services provided by direct ICT third-party service providers and, on the other, information on all subcontractors that effectively underpin ICT services supporting critical or important functions or material parts of them.

In practice that means two different rules for two different layers. For direct providers nothing is filtered: even a minor service with no bearing on critical functions belongs in the register. For subcontractors, by contrast, there is a double filter — the service has to support a critical or important function or a material part of it, and the subcontractor has to be the one effectively underpinning it. A complete map of the subcontracting chain for non-critical services is therefore not required.

Three definitions from Article 1 go with this. A direct ICT third-party service provider is one that has signed a contractual arrangement with a financial entity to provide its services directly to that entity, or with a financial or non-financial entity to provide services to other financial entities within the same group. An ICT service supply chain is the sequence of contractual arrangements starting with the direct provider, which has one or more subcontractors as counterparties. And rank is the position of a provider in that chain.

What an ICT service actually is, however, is not settled by the implementing regulation but by Article 3(21) of DORA — digital and data services provided on an ongoing basis through ICT systems to one or more internal or external users, including hardware as a service and hardware services with technical support through software or firmware updates, excluding traditional analogue telephone services. A provider is, under Article 3(19), any undertaking providing ICT services, with no size threshold.

• Direct provider: always reported, with all its services. Regardless of whether the service in question supports a critical or important function.
• Subcontractor: only for critical or important functions. And only where it effectively underpins the service or a material part of it. An intermediary that effectively underpins nothing does not fall into this category.
• An ICT intra-group service provider appears in the register in its own right — template B_02.03 links intra-group arrangements to arrangements with providers outside the group by means of contractual reference numbers.
• Reference numbers of contracts with subcontractors are not reported. The instructions to template B_02.01 say so expressly: where external direct providers use subcontractors, the reference numbers of the arrangements between them and their subcontractors are not reported in the register.
• Additional information is allowed. Under Article 5(2) a financial entity may include further information in the register in the format most appropriate to it, where this is relevant to risk management or contract management.
• Your own terminology has to be explained. Template B_99.01 exists so that supervisors know what "low", "medium" and "high" impact mean in your assessment columns. Without it, your scales are unreadable.

The phrase "effectively underpin" causes the greatest difficulty in practice with multi-tier cloud chains. What matters is who actually operates the service or a material part of it, not who is named in the contract as the counterparty. The answer is usually not evident from the paperwork and has to be obtained from the direct provider — which is at the same time why the Article 30 addenda contain such detailed information duties.

Rank in the ICT service supply chain and template B_05.02

Rank is the mechanism by which the depth of the chain is modelled in the register. Under Article 2 of the implementing regulation the financial entity assigns a rank to every ICT third-party service provider, being any natural number greater than or equal to one, where the lower the number, the closer the arrangement is to the financial entity. The rank of a direct provider is always 1 and the rank of a subcontractor always higher than 1. The standard fixes no number of layers.

The modelling itself takes place in template B_05.02 (ICT service supply chain). Its instructions contain an example worth knowing: a financial entity has a contract with provider X for two services, service A and service B, and the provider uses subcontractor Y to provide service B. For service A the chain consists of provider X alone with rank 1. For service B it consists of provider X with rank 1 and subcontractor Y with rank 2.

An important point follows from this: the chain is determined separately for each ICT service in each contractual arrangement, not for the provider as such. The same provider can be the only link for one service and the start of a three-tier chain for another. The instructions add that all providers belonging to the same supply chain carry the same contractual reference number as reported in template B_02.01, and the same type of ICT services.

Links inside the chain are made through a pointer to the recipient of the subcontracted services. For every subcontractor with a rank higher than 1, columns B_05.02.0060 and B_05.02.0070 identify the provider that is the recipient of its subcontracted services. For rank 1 those columns are left empty. The instructions also anticipate that where several providers hold the same position in the same chain, they are given the same rank.

• B_05.02.0010 — contractual arrangement reference number. The same for the whole chain of the service concerned, taken over from B_02.01.
• B_05.02.0020 — type of ICT services. The code from the closed list in Annex III, again the same for the whole chain.
• B_05.02.0030 and 0040 — provider identification code and its type. Taken over from B_05.01, so that the same entity does not appear in the register under two different identities.
• B_05.02.0050 — rank. A natural number from 1 upwards; one for the direct provider, higher for subcontractors.
• B_05.02.0060 and 0070 — recipient of the subcontracted services and the type of its code. Completed only for ranks higher than 1 and has to match the identifier of that same provider in B_05.01.
• The chain attaches to the service, not to the provider. Two services from the same provider may have chains of different depth, and therefore a different number of rows.
• Only subcontractors for critical or important functions belong in the chain. This follows from Article 3(2)(b) — for other services the chain does not extend below the direct provider.

The most common mistake in this part is to fill in the chain according to the provider's organisational structure instead of according to who actually provides the specific service. The second most common is forgetting that the same provider has to be identified by the same code in all templates — otherwise the register falls apart into records that cannot be joined and the consistency check under Article 3(4) fails.

Identifiers: LEI, EUID and when something else may be used

Identification of providers is strict in the register, because it is what makes the data joinable across entities. Under Article 3(5) of the implementing regulation, all ICT third-party service providers that are legal persons are identified by a valid and active legal entity identifier (LEI) or by the European Unique Identifier (EUID) under Article 16 of Directive (EU) 2017/1132, or by both where both have been assigned. The exception is natural persons acting in a business capacity.

For critical and important functions the requirement travels further down the chain. Under Article 3(6) the financial entity ensures, through the direct provider, that a valid and active LEI is used or an EUID provided by all subcontractors reported in the register under Article 3(2)(b) that effectively underpin those services — again with the exception of natural persons in business. The financial entity therefore has no duty to obtain the code itself, but it does have a duty to require it along the chain.

The instructions to template B_05.01 take that logic down to column level: for legal persons only the LEI or the EUID is used, whereas an alternative code may be used only for a natural person acting in a business capacity. In practice this means that a supplier number from your internal system is not a usable substitute where the provider is a company — and that is the most frequent reason a return fails validation.

Besides providers, your own entities are identified as well. The financial entity maintaining the register and the entities in the consolidation are identified in templates B_01.01 and B_01.02 by a twenty-character alphanumeric LEI under ISO 17442; in template B_01.03 branches are reported either with their own LEI, where it is unique and different from the LEI of the parent entity, or with another identification code used by the financial entity.

• LEI, or EUID, or both. There is no other option for legal persons. Where both codes have been assigned, both are reported.
• An alternative code only for natural persons in business. For a sole trader supplying an ICT service an alternative identification may be used; for a limited company it may not.
• Valid and active. The standard does not merely require the code to exist, but also to be current. An unsupported LEI counts as an invalid value and runs into the data validity principle in Article 3(4).
• The ultimate parent undertaking. Template B_05.01 also records the identifier of the provider's ultimate parent undertaking; where the provider is not part of a group, its own identifier is repeated in that field.
• Consistency across templates. The provider identifier is carried over from B_05.01 into B_02.02, B_03.02, B_05.02 and B_07.01. Anyone keeping identifiers separately in each table will produce an inconsistent register.
• Obtaining the code is work on the provider's side. Getting an LEI takes days and is an administrative step that cannot be sorted out on the day of submission. With new providers it pays to ask about the code as early as the tender.

The LEI requirement is at the same time the easiest question to put into an onboarding questionnaire — and the best advance test of how cooperation on register updates will go. A provider that has no code and refuses to obtain one cannot be reported in the register at all.

Fifteen templates in the order they are filled in

Annex I to Regulation (EU) 2024/2956 contains fifteen templates and Article 5(1) lists them under points (a) to (o). The codes run from B_01.01 to B_99.01 and they are interlinked: most templates take values from others, so the order of completion is not arbitrary. The numerical order of the codes roughly matches the order of the work, but not entirely — template B_05.01 with provider identifiers and template B_06.01 with the identification of functions have to be finished before templates with lower numbers can be completed.

The practical order looks like this: first describe your own organisation (B_01.01 to B_01.03), then identify the functions and their criticality (B_06.01), then set up the provider register with identifiers (B_05.01), only then complete the contract templates (B_02.01, B_02.02, B_02.03) and the links to signatories and users (B_03.01 to B_03.03, B_04.01), followed by the supply chain (B_05.02), the assessment of services for critical functions (B_07.01) and finally the glossary of your own scales (B_99.01).

Under Article 4, each template is a table with a predefined number of columns and an indeterminate number of rows. Each data item is completed with a single value, and where there are several valid values, a further row is added for each. That rule is why the register grows quickly: template B_02.02 reports combinations of ICT services and supported functions, so a single contract covering three services that support two functions means six rows.

• 1. B_01.01 — Entity maintaining the register of information. Identification of the entity that maintains and updates the register at entity level and at sub-consolidated and consolidated level. The shortest template and at the same time the reference point for the others.
• 2. B_01.02 — List of entities within the scope of consolidation. All entities belonging to the group. Where an entity is not part of a group, only that entity is reported and the record is identical to B_01.01. This is also where the value of total assets is reported, following the instruction in Annex IV.
• 3. B_01.03 — List of branches. Branches of the entities listed in B_01.02 that are located outside the home country.
• 4. B_06.01 — Functions identification. Brought forward deliberately: without function identification codes, B_02.02 cannot be completed. Details are in a separate section below.
• 5. B_05.01 — ICT third-party service providers. A list and general information on direct providers, intra-group providers, all subcontractors reported in B_05.02 and ultimate parent undertakings. The source of identifiers for every other template.
• 6. B_02.01 — Contractual arrangements, general information. A list of all contractual arrangements with direct providers. This is where each arrangement is given a unique reference number that four other templates refer to. It distinguishes standalone, overarching and subsequent arrangements and reports the annual expense or estimated cost.
• 7. B_02.02 — Contractual arrangements, specific information. The detail for every arrangement from B_02.01, in combinations of ICT service and supported function: start and end dates, reason for termination, notice periods for both parties in days, country of the governing law, country of provision of the service, storage of data, location of data storage, location of management, sensitivity of the data and the level of reliance for critical functions.
• 8. B_02.03 — List of intra-group contractual arrangements. The links between intra-group arrangements and arrangements with providers outside the group, by means of contractual reference numbers, where part of the supply chain sits inside the group.
• 9. B_03.01 — Entities signing the contractual arrangements. Who signed the contract with the direct provider, whether for itself or on behalf of the entity that uses the service. At entity level the signatory and the user are the same financial entity; in a consolidation they differ.
• 10. B_03.02 — Providers signing the contractual arrangements. Identification of all providers from B_05.01 that signed the arrangements listed in B_02.01.
• 11. B_03.03 — Entities providing ICT services to other entities in the consolidation. Entities from B_01.02 that signed arrangements from B_02.01 on the provision of ICT services to other entities in the group.
• 12. B_04.01 — Entities making use of the ICT services. The users of the services; under the instructions these are either financial entities within scope or ICT intra-group service providers.
• 13. B_05.02 — ICT service supply chain. The rank and the links between providers in the same chain, see the separate section above.
• 14. B_07.01 — Assessments of the ICT services. Completed only for services supporting a critical or important function or a material part of it. Details in a separate section below.
• 15. B_99.01 — Definitions from entities making use of the ICT services. Your own explanations, meanings and definitions of the fixed scales used in the register. Completed last, because it refers to the values used in the other templates.

The order above is a working one, not a normative one: the regulation lays down the content of the templates and their cross-references, not a sequence of steps. Experience says that teams which start with the contract templates B_02.01 and B_02.02 sooner or later return to the beginning — without the list of functions and without a provider register with identifiers, those tables cannot be finished.

Functions, criticality and assessment of services: templates B_06.01 and B_07.01

Template B_06.01 (Functions identification) is where the register meets your internal organisation. The financial entity identifies, according to its own organisation, all functions supported by an ICT service from a third-party provider and assigns each of them a unique function identification code in the form of the letter F followed by a natural number. Uniqueness is required for each combination of the financial entity's LEI, the licensed activity and the name of the function.

The example in the instructions shows this clearly: an entity operating under two licensed activities receives two different identification codes for one and the same function — sales, say — one for activity A and one for activity B. In substance it is the same process; in the register it is two records. The list of licensed activities by entity type is in Annex II; where a function is not linked to a registered or licensed activity, it is reported as a support function.

Besides identification, B_06.01 also carries your own assessment: whether the function is critical or important (with the options yes, no, assessment not performed), a brief reason for the classification of no more than 300 characters, the date of the last assessment, the recovery time objective and the recovery point objective in whole hours, and the impact of discontinuing the function on a scale of low, medium, high, assessment not performed. Where an assessment has not yet been carried out, 9999-12-31 goes into the date; where a recovery objective is not defined, the value 0.

Template B_07.01 (Assessments of the ICT services) is completed only where the service supports a critical or important function or a material part of it, and, under the instructions, including for the first subcontractor outside the group where the earlier links of the chain are inside it. It is the most analytical template in the whole register: it does not ask what you have, but where you would stand if it ended.

• Substitutability of the provider on a four-step scale: not substitutable, highly complex substitutability, medium complexity in terms of substitutability, easily substitutable.
• The reason for difficult substitutability from a closed list: a lack of real alternatives on the market or the technical complexity of the service, difficulties in migrating data and workloads or in reintegrating them in house, or both. Completed for the two highest steps of non-substitutability.
• The date of the last audit of the provider. The instructions expressly delimit what counts — an audit by an internal function or by qualified staff, a pooled audit with other clients of the same provider, or an audit by a third party appointed by the supervised entity. What does not count is the date of a certification, the date of the provider's own internal audit report, the date of the yearly monitoring of the arrangement or the date of a review of your own risk assessment. Where no audit was carried out, 9999-12-31 is entered.
• The existence of an exit plan for the specific service, yes or no.
• The possibility of reintegrating the services on a scale of easy, difficult, highly complex; completed for providers outside the group.
• The impact of discontinuing the ICT services on a scale of low, medium, high, assessment not performed.
• Alternative providers. Whether they have been identified (yes, no, assessment not performed) — the instructions add that an assessment to identify an alternative provider has to be carried out for every provider supporting a critical or important function. Naming the alternative is optional.

The columns of template B_07.01 read like a checklist for third-party risk management: who is not substitutable, when you last audited them, whether you have an exit plan for them and whether you know of an alternative. One of the few ways to turn the register to your own advantage is to treat this template as a work assignment for internal work, rather than as a table to be filled in before submission.

Code lists: service types S01 to S19 and Annexes II and IV

The type of ICT service is not reported in the register in words. Annex III contains a closed code list with identifiers from S01 to S19 and the instruction is unambiguous: only the code is reported in the templates. The list is the same for all entities in the Union, which is exactly what allows supervisors to aggregate data across the market — and it also means your own categorisation of providers has to be mapped onto that list.

Classification tends to be contentious mainly for software and for cloud, because the list draws its dividing lines somewhere other than ordinary commercial language does. Software delivered as a service falls under S19, whereas licensing of software used on premises falls under S13. Cloud services have three separate codes by model, while hosting and infrastructure services outside cloud sit under S07 and non-cloud storage under S09. For telecommunication services the list expressly recalls that traditional analogue telephone services are excluded under Article 3(21) of DORA.

The remaining two annexes are auxiliary, but the register cannot be finished without them. Annex II contains the list of licensed activities by entity type — from credit institutions through payment institutions, account information service providers, electronic money institutions and investment firms to crypto-asset service providers and issuers of asset-referenced tokens. It is used in template B_06.01, where the licensed activity is part of the combination that determines the function identification code. Annex IV then gives, for each entity type, the instruction on how to report the value of total assets in template B_01.02.

• S01 to S04 — services around management and security: ICT project management, ICT development (business analysis, software design and development, testing), ICT help desk and first level support, ICT security management services including incident handling and forensic analysis.
• S05 and S06 — data services: provision of data, that is subscriptions to data provider services, and data analysis.
• S07 to S09 — infrastructure outside cloud: ICT, facilities and hosting services excluding cloud, computation and non-cloud data storage.
• S10 to S12 — networks and hardware: telecom carrier, network infrastructure, hardware and physical devices provided as a service.
• S13 — software licensing excluding software as a service, that is software used on premises.
• S14 to S16 — operations and advisory: ICT operation management including maintenance, where the list expressly places managed service providers as well, ICT consulting, and ICT risk management in the sense of compliance verification under Article 6(10) of DORA.
• S17 to S19 — cloud: infrastructure as a service, platform as a service and software as a service, each with its own code.
• One contract, several codes. Where a provider supplies several types of service under one contract, that produces several rows — and several chains in the dependent templates, because chains are determined per service.

The surest way to verify how a service is classified is to ask the provider which category it reports under with its other customers. The code appears in several registers at once, and a mismatch between them is precisely the kind of inconsistency that surfaces when data is aggregated at supervisory level.

Where the register usually gets stuck

The register is a data exercise, not a documentation exercise, and mistakes in it therefore look like mistakes in any other regulatory return: at the edges, in the links, and in what did not fit into the table. Below is an overview of the places that recur most often, ordered roughly by how expensive they are to put right.

The most expensive is a badly drawn scope. Narrowing the register to large providers only, overlooking services bought outside the IT function, or leaving out intra-group providers means the register does not get topped up — it gets rebuilt. The second most expensive is a missing link to functions: without identified functions and their criticality there is no way to decide where B_07.01 is completed and where the supply chain extends below the direct provider.

The rest are recurring details — date formats, codes, scales, one value per cell. On their own they are not dramatic, but in a return that is checked by machine they decide whether the submission passes.

• A narrowed scope. The register is maintained for all contractual arrangements on ICT services. The distinction between critical and non-critical is made inside the register under the second subparagraph of Article 28(3) of DORA, not by selecting at the entrance.
• Purchases outside IT. Data service subscriptions, tools acquired by the sales or marketing function and software as a service paid for by card are ICT services in exactly the same way as centrally managed contracts.
• Missing identifiers. An internal supplier number is no substitute for an LEI or an EUID. The alternative code is reserved for natural persons acting in a business capacity.
• Inconsistent identity across templates. The provider identifier is taken over from B_05.01; when the same provider appears in two templates under different codes, the register falls apart.
• Underestimating the multiplication of rows. Article 4(2) requires one value per data item and a further row for each further valid value. B_02.02 reports combinations of services and functions, so the number of rows grows as a product, not as a sum.
• Formats and placeholder values. Dates in ISO 8601 format, countries as a two-letter ISO 3166-1 code, notice periods in whole calendar days, recovery objectives in whole hours. For an assessment not performed or an audit that never happened, 9999-12-31 is used; for an undefined recovery objective, 0; and for a contract of indefinite duration, again 9999-12-31.
• An unfilled glossary of scales. Without template B_99.01 supervisors have no way to interpret your low, medium and high values. It is the last template in the order and at the same time the one most often forgotten.
• A one-off collection with no owner. The data quality principles in Article 3(4) and the duty to correct detected errors promptly presuppose ongoing management. A register assembled once, just before submission, is out of date within six months — and in the meantime it has become an input to supervisory decisions.

A practical piece of advice at the end: the register stays current most easily when it is hooked into processes that run anyway — approval of new providers, change management and periodic contract reviews. A spreadsheet managed to one side of those processes goes stale faster than it can be submitted.

The order of work when building the register for the first time

The steps follow from the links between the templates: each step needs the output of the previous one. This is not a requirement of the regulation but an order that saves rework — particularly for entities building the register for the first time or after a change in group structure.

Official sources

The information on templates, columns and code lists on this page is based on the following legal acts, as of 9 August 2026. This material does not replace their wording.