RegAlertConsultation · ESMA · 17 Jan 2024
Final Report on Draft Implementing Technical Standards on Standard Templates for the Register of Information under Article 28(9) of Regulation (EU) 2022/2554
The draft ITS establish 15 standard templates for the register of information on all contractual arrangements for ICT services provided by ICT third-party service providers, to be maintained by financial entities at entity, sub-consolidated and consolidated levels. Financial entities and ICT third-party service providers that are legal persons must obtain and maintain a valid Legal Entity Identifier. Additional information, such as risk assessments and ICT supply chain details, is required only where ICT services support critical or important functions. The final draft ITS will be submitted to the European Commission for adoption.
JC 2023 85
10 01 2024
Final Report
On Draft Implementing Technical Standards on the standard templates for the purposes of the register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers under Article 28(9) of Regulation (EU) 2022/2554
Contents
ABBREVIATIONS .................................................................................................................................. 3
1. EXECUTIVE SUMMARY ...............................................................................................................................4
2. BACKGROUND AND RATIONALE ...................................................................................................................6
3. NEXT STEPS ............................................................................................................................................16
4. DRAFT IMPLEMENTING TECHNICAL STANDARDS ...........................................................................................17
5. DRAFT COST- BENEFIT ANALYSIS / IMPACT ASSESSMENT .................................................................................6
6. FEEDBACK ON THE PUBLIC CONSULTATION ..................................................................................................18
7. FEEDBACK FROM THE STAKEHOLDER GROUPS .............................................................................................39
Abbreviations
| CP | Consultation Paper |
|---|---|
| DORA | Digital Operational Resilience Act |
| EBA | European Banking Authority |
| EIOPA | European Insurance and Occupational Pensions Authority |
| ESMA | European Securities and Markets Authority |
| ESAs | European Supervisory Authorities |
| EU | European Union |
| ICT | Information and Communication Technology |
| ITS | Implementing Technical Standards |
| ICT TPP | ICT third-party service provider |
| JC | Joint Committee of the ESAs |
| CA | Competent Authority |
| IA | Impact assessment |
1. Executive Summary
One of the objectives of Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) is to ensure a sound monitoring of ICT third-party risk in the financial sector. The conduct of such monitoring should follow a strategic approach to ICT third-party risk formalised through a dedicated ICT third-party risk strategy adopted by the management bodies of the financial entities (FEs), rooted in a continuous screening of all ICT third-party dependencies.
In light of the above and considering the need to enhance supervisory awareness and enable effective supervision of FEs’ ICT third-party dependencies by Competent Authorities (CAs), and with a view to further supporting the work in the context of the Oversight Framework established by the DORA, all FEs are required to maintain and update at entity level, at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT Third-Party Service Providers (ICT TPPs).
Article 28(9) of DORA mandates the European Supervisory Authorities (ESAs) to develop draft implementing technical standards to establish the standard templates for the purposes of the register of information, including information that is common to all contractual arrangements on the use of ICT services.
In fulfilment of the mandate, the draft ITS presented in this final report includes the templates of the register of information which are designed to achieve all the three purposes as described in the first two paragraphs above. Although the ITS does not contain specifications regarding the process of sharing information from FEs to CAs and from CAs to the Oversight Forum1 , the templates and the requirements of their data points have been designed considering a data management and reporting perspective to ensure consistency and harmonisation by design and avoid burdensome reprocessing of data for reporting purposes.
Furthermore, and with specific reference to the first key purpose mentioned above, the FEs’ ICT risk management, the register of information aims at ensuring a minimum level of content and harmonisation. FEs may complement the information required by the templates included in the draft ITS by tailoring them to their internal risk management purposes.
The standard templates of the register of information are proportionate by design as the scale of information is subject to the contractual relationship on ICT services with ICT TPPs. Therefore, a FE relying on a significant number of ICT TPPs or a complex level of ICT dependencies has more information to report in the register of information than a FE depending on a small number or ICT TPPs.
[1] Following Article 32 of DORA.
For proportionality purposes, FEs are required to report additional information (such as information on risk assessment, ICT supply chain or involvement of subcontractors) in case the ICT services provided support critical or important functions.
The development of these templates leveraged on current supervisory practices, existing sectorial guidance and also lessons learned from previous data collection exercises carried out by the CAs and the ESAs.
2. Background and rationale
1. Article 28(3) of Regulation (EU) 2022/2554 (DORA) requires financial entities (FEs), as part of their ICT risk management framework, to maintain and update at entity level, at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers. FEs shall also make available to the competent authorities (CAs) the register of information along with any information deemed necessary to enable the effective supervision of FEs and for acquiring a broader understanding of the ICT dependencies of FEs with a view to support the Oversight Framework of critical ICT third-party service providers.
2. In this regard, Article 28(9) mandates the ESAs to develop draft implementing technical standards (ITS) to establish the standard templates for the purposes of the register of information, including information that is common to all contractual arrangements on the use of ICT services.
3. The following chapter sets out how the ESAs are proposing to fulfill this mandate and the key underlying reasoning and considerations taken into account when developing the templates constituting it. In addition, the Impact Assessment (IA) section and the feedback statement at the end of the Final Report (FR) provides additional choices and options that have been considered by the ESAs when developing this mandate.
4. Considering the feedback received during the public consultation, the information to be recorded in the register of information has been reduced and the templates of the register of information have been streamlined. Instead of a template for financial entities at entity level and another one at (sub)consolidated level, the draft ITS included in this Final Report defines one single set of templates for the register of information. In comparison with the ITS publicly consulted:
-
former templates RT.05.03 and RT.07.01 in the consultation paper have been removed;
-
the number of columns (quantity of information requested) has been reduced;
-
some columns and the template RT.07.01 (former template RT.08.01 in the consultation paper) are to be completed only if relating to ICT services supporting critical or important functions;
-
the templates and columns (data fields) have been reviewed from a data management perspective considering also reporting implications. For this reason, some columns have
been deleted from some templates and 3 small technical templates (containing only keys) have been added to ensure an efficient management of the information recorded in the register of information.
5. In order to fulfill the purpose of the register of information outlined in point 1, the templates included in the draft ITS aim to:
a. capture minimum and necessary information concerning the contractual arrangements and the assessment of the related risks stemming from them for FEs;
b. capture the ICT service supply chain with a focus on subcontractors of ICT services supporting a critical or important function or material parts thereof (‘material subcontractors’);
c. identify unambiguously and consistently the ICT third-party service providers and the FEs by using the Legal Entity Identifier (LEI)2 to enable an efficient aggregation of relevant information;
d. identify the (critical or important) functions supported by the ICT services provided by ICT third-party service providers following the steps listed below:
i. FEs to identify all their operational and business functions;
ii. FEs to identify which functions are critical or important according to their internal assessment considering the definition in Article 3(22) of the DORA;
iii. FEs to identify the ICT services provided by ICT third-party service providers supporting the functions, (not only the critical or important functions);
iv. in case of groups, there is the additional need to capture the following links:
1. contracts between entities within the group only (internal contracts);
2. contracts between an entity within the group and an external ICT third-party service provider (external contracts).
e. facilitate the collection of the registered information by competent authorities.
6. When it comes to groups, Article 3 of DORA makes reference to Directive 2013/34/EU (the Accounting Directive) to define the meaning of a ‘group’, a ‘parent undertaking’ and a ‘subsidiary’. However, it is silent on how the FEs shall define the perimeter of sub-consolidation and the entities to be included in the scope of both sub-consolidation and consolidation. Considering the practices stemming from the different financial regulations, the draft ITS contains the principles to be followed by the parent undertaking of a sub-group and
[2] The draft ITS sets the requirement for all the financial entities and the ICT third-party service providers that are legal persons to procure and maintain for themselves a valid LEI.
group while defining the scope of sub-consolidation and consolidation. More specifically, the draft ITS requires the parent undertaking to make reference to the relevant financial services regulations when defining the scope of sub-consolidation and consolidation. In this context the term “relevant financial services regulations” should be applied considering the relevant regulations referred to in Article 3 points (31) to (59) and Article 46 of DORA, which include also Directive 2002/87/EC “financial conglomerates directive”.
7. The register of information is composed of a set of open tables, all linked to each other by using different specific keys in order to form a relational structure. In order to ensure clarity, the draft ITS proposes a single set of templates that is common to all financial entities, subgroup and group to be used to report information in the register of information.
Structure of the register of information templates
8. The register of information is composed of 15 templates. Illustration 1 shows the relational structure between the templates highlighting some of the relational keys used to link one template to another.
Illustration 1: Structure of the Register of Information
Each box represents one template of the Register of information.
9. As illustration 1 above shows, all templates are linked to each other by using relational keys. Some of the keys used are the following ones: (i) the contractual arrangement reference number; (ii) the LEI of the entity making use of the ICT services, (iii) the ICT third-party service provider identifier; (iv) the function identifier and (v) the type of ICT services (provided in Annex III).
These keys are represented by coloured circles in the illustration above. The colour code of the circles matches the one of the templates where the relational keys are defined (except for the type of ICT services which is a closed list provided in Annex III). For example, the relational key “contractual arrangement reference number” is defined in templates RT.02.01. Furthermore, illustration 1 shows the presence of the different relational keys in the various templates. For example, the relational key ‘contractual arrangement reference number’ is used to link the information of templates RT.02.01, RT.02.02, RT.02.03, RT.03.01, RT.03.02, RT03.03, RT.04.01, RT.05.02, RT.05.03 and RT.07.01.
Table 1: Objectives of the templates of the register of Information
| Template Code | Template Name | Short Description |
|---|---|---|
| RT.01.01 | Entity maintaining the register of information | This template identifies the entity maintaining and updating the register of information at entity, sub-consolidated and consolidated level, respectively. |
| RT.01.02 | List of entities within the scope of consolidation | This template identifies all the entities belonging to the group. In case the financial entity responsible for maintaining and updating the register of information does not belong to a group, only this financial entity shall be reported in this template. |
| RT.01.03 | List of branches | Objective of this template is to identify the branches of the financial entities referred to in template RT.01.02 in order to be able to map them with the contractual arrangements. |
| RT.02.01 | Contractual arrangements – general Information | Objective of this template is to list all contractual arrangements with direct ICT third-party service providers. For each contractual arrangement with direct ICT third-party service provider, the financial entity maintaining the register of information shall assign a unique ‘contractual arrangement reference number’ to identify unambiguously the contractual arrangement itself. |
| RT.02.02 | Contractual arrangements – specific information | Objective of this template is to provide details in relation to each contractual arrangement listed in template RT.02.01 with regard to: (i) the ICT services included in the scope of the contractual arrangement; (ii) the functions of the financial entities supported by those ICT services; |
| (iii) other important information in relation to the specific ICT services provided (e.g. notice period, law governing the arrangement, etc.). | ||
| RT.02.03 | List of intra-group contractual arrangements | Objective of this template is to identify the links between intra-group contractual arrangements and contractual arrangements with ICT third-party service provider which are not part of the group using the contractual reference numbers when part of the ICT service supply chain. |
| RT.03.01 | Entities signing the contractual arrangements for receiving ICT service(s) or on behalf of the entities making use of the ICT service(s) | Objective of this template is to provide information on the entity signing the contractual arrangements with the direct ICT third-party service provider for the entity making use of the ICT services. In case the register of information is maintained and updated at entity level, the entity signing the contractual arrangement and the entity making use of the ICT services are the financial entity maintaining the register. Within the scope of sub-consolidation and consolidation, the financial entity making use of the ICT services provided is not necessarily the entity signing the contractual arrangement with the ICT third-party service providers. |
| RT.03.02 | ICT third-party service providers signing the Contractual arrangements for providing ICT service(s) | Objective of this template is to identify all the ICT third-party service providers referred to in template RT.05.01 signing the contractual arrangements referred to in template RT.02.01 for providing the ICT services. |
| RT.03.03 | Entities signing the Contractual | Objective of this template is to identify all the entities referred to in template RT.01.02, signing |
Template
Code
Template Name
Short Description arrangements for providing ICT service(s) to other entities within the scope of consolidation the contractual arrangements referred to in template RT.02.01 for providing ICT services to other entities in the scope of consolidation RT.04.01 Entities making use of the ICT services Objective of this template is to ensure that all entities making use of the ICT services provided by ICT third-party service providers are registered in the register of information. The entities making use of the ICT services shall be either the financial entities in scope, or the ICT intra-group service providers. In case the register of information is maintained and updated at entity level, the entity signing the contractual arrangement and the entity making use of the ICT services are the financial entity maintaining the register. RT.05.01 ICT third-party service providers Objective of this template is to list and provide general information to enable the identification of:
(i) the direct
ICT third-party service providers;
(ii) the ICT intra-group service providers;
(iii) all subcontractors included in template
RT.05.02 on ICT service supply chains;
(iv) and identify the ultimate parent undertaking of the ICT third-party service providers listed in points (i) to (iii) above.
RT.05.02
ICT service supply chains
Objective of this template is to identify and link one to another the ICT third-party service providers part of the same ICT service supply chain.
Template
Code
Template Name
Short Description
Financial entities shall identify and rank the ICT third-party service providers for each ICT service included in the scope of each contractual arrangement.
Example: a financial entity has a contractual arrangement with an ICT third-party service provider (say, ICT third-party service provider X) to receive 2 specific ICT services (say ICT service A and ICT service B) and the service provider makes use of a subcontractor (say, ICT third-party service provider Y) to provide one of these services (say ICT service B). In relation to ICT service A, the ICT service supply chain is composed by one ICT third- party service provider, ICT third-party service provider X, which will be given ‘rank’ 1 in the template. ICT third-party service provider X is the direct ICT third-party service provider. In relation to ICT service B, the ICT service supply chain is composed by two ICT third- party service providers:
(i) ICT third-party service provider X, which will be given ‘rank’ 1 in the template. ICT third-party service provider X is the direct ICT third- party service provider.
(ii) ICT third-party service provider Y, which will be given ‘rank’ 2 in the template. ICT third-party service provider Y is a subcontractor.
All ICT third-party service providers belonging to the same ICT service supply chain share the same ‘contractual arrangement reference number’ as referred to in template RT.02.01 and the same type of ICT services
| Template Code | Template Name | Short Description |
|---|---|---|
| RT.06.01 | Functions identification | Objective of this template is to identify and provide information on the functions of the financial entity making use of the ICT services. Within the information to be provided within this template, financial entities shall include a unique identifier, the ‘function identifier’ for each combination of a financial entity’s LEI, licenced activity and function. Example: a financial entity (LEI: 21USLEIC20231109J3Z8) which operates under two licensed activities (say, activity A and activity B) will identify two unique ‘function identifiers’ for the same function X (e.g. Sales) performed for activity A and activity B. The function identifier will be: F1 for the combination of “21USLEIC20231109J3Z8” “Activity A” and ‘Function X” F2 for the combination of “21USLEIC20231109J3Z8” “Activity B” and ‘Function X” |
| RT.07.01 | Assessments of the ICT services | Objective of this template is to capture information in relation to the risk assessment on the ICT services (e.g. substitutability, date of last audit, etc.) when the latter are supporting a critical or important function or material part thereof. |
| RT.99.01 | Definitions from Entities making use of the ICT Services | Objective of this template is to capture entity-internal explanations, meanings and definitions of the closed set of indicators used in the register of information. For example, in template RT.07.01 financial entities shall provide an indication of the impact |
Template
Code
Template Name
Short Description of discontinuation of the ICT services by using a closed set of options (low medium, high). In template RT99.01 the financial entity needs to specify the meaning of those options.
ICT service supply chain
5. Another key objective of the register of information as described in paragraph 4 is to capture the ICT service supply chain. As described above, Template RT.05.02 aims at fulfilling this specific objective. Illustration 2 provides an illustrative and simplified example of an ICT service supply chain.
Illustration 2: Example of an ICT service supply chain
6. To acquire a clear and precise visualisation of an ICT service supply chain in the register of information, the following information is required:
a. the contractual arrangement reference number between the FE and the first ICT third-party service provider(s) in the ICT service supply chain (direct ICT third-party service provider) which shall be unique and common for all the elements of a same ICT service supply chain3 ;
b. The ICT service identifier, which is common for all the elements of the same ICT service supply chain4 ;
[3] The contractual arrangement reference number is defined by the FE in Template RT.02.01
[4] The types of ICT services are listed in Annex III
c. The rank of each ICT third-party service provider, which is part of the ICT service supply chain, starting from the direct ICT third-party service providers (at rank 1) up to the last material subcontractor in the ICT service supply chain;
d. The link between all ICT third-party service providers, which are part of the same ICT service supply chain (the provider and receiver of ICT services).
3. Next steps
The final draft ITS will be submitted to the European Commission for adoption.
4. Draft implementing technical standards
COMMISSION IMPLEMENTING REGULATION (EU) …/... of XX Month YYYY laying down implementing technical standards with regard to standard templates for the register of information according to Regulation (EU) 2022/2554 of the European Parliament and of the Council (Text with EEA relevance)
THE EUROPEAN COMMISSION, Having regard to the Treaty on the Functioning of the European Union,
Having regard to Regulation (EU) 2022/2554 of the European Parliament and of the Council, of 14 December 2022 on digital operational resilience for the financial sector and amending Regulations (EC) No 1060/2009, (EU) No 648/2012, (EU) No 600/2014, (EU) No 909/2014 and (EU) 2016/10115 and in particular the second subparagraph of Article 28(9) thereof,
Whereas:
(1) This Regulation establishes standard templates for the purposes of the register of information, including information that is common to all contractual arrangements on the use of information and communication technology (ICT) services. Information gathered from the register of information is essential for (i) the financial entities’ internal ICT risk management, (ii) the effective supervision of the financial entities by their competent authorities and (iii) the establishment and conduct of oversight of the critical ICT third-party providers by the Lead Overseer as well as the annual process to designate critical ICT third-party service providers by the European Supervisory Authorities (ESAs).
(2) To ensure supervisory outcomes which are consistent with the existing supervisory frameworks, the parent undertaking of financial entities that are part of a group as defined in the applicable financial services regulations should define the scope of entities to be included in the register of information at sub-consolidated and consolidated level by applying these financial services regulations. To reduce their administrative costs, groups may develop a single register of information at entity, sub-consolidated and consolidated levels in relation to all contractual arrangements on the
[5] OJ L 333, 27.12.2022, p. 1.
use of ICT services provided by ICT third-party service providers to all the financial entities, which are part of the group. In such cases, the single register of information should allow each financial entity to fulfil its obligation to maintain and update the register of information at entity and sub-consolidated level, when applicable, including its reporting to its competent authority.
(3) Pursuant to Article 28(1), point (b) of Regulation (EU) 2022/2554, the financial entities’ management of ICT third-party risks takes into account the nature, scale, complexity and importance of ICT-related dependencies, as well as the risks arising from contractual arrangements on the use of ICT services concluded with ICT third-party service providers. This should take into account the criticality or importance of the service, process or function and the potential impact on the continuity and availability of financial services and activities, at entity and at group level.
(4) Union financial services sectoral specific laws contain certain rules on outsourcing, which have been further detailed by the ESAs through the development of guidelines containing the expectation for some financial entities to record specific information on their outsourcing arrangements, in some cases also in the form of registers, as part of their outsourcing risk management. In recent years, several National and European Competent Authorities performed data collection of information included in such registers as part of their supervision of financial entity compliance to the outsourcing requirements. Leveraging on the lessons learned from the different data collection exercises of outsourcing registers performed in the recent years by competent authorities and the ESAs, the templates established by this Regulation are designed in a technology-neutral manner building up on open tables, which have a predefined number of columns but an indefinite number of rows. In addition, the templates are linked to one another by using different specific keys to form a relational structure between them.
(5) In order to receive ICT services from an ICT third-party service provider, including ICT intra-group service providers, financial entities conclude a written contract with the ICT third-party service provider. In case of groups, ICT intra-group service providers may conclude a contract with ICT third-party providers external to the group to provide ICT services to one or more financial entities of the group. In order to capture the full ICT service supply chain, financial entities maintaining the register of information should report information on both the contractual arrangement with their ICT intra-group service provider as well as information on the arrangement stipulated by the ICT intra-group service provider and the ICT third-party providers external to the group as subcontractors. To reflect this practice, the register of information includes a specific template allowing the reconciliation between the intra-group contracts and the contracts with ICT third-party service providers external to the group.
(6) The provision of ICT services to financial entities may rely on potentially long or complex chains of subcontracting which should be monitored by the financial entities. Financial entities should assess the associated risks, including ICT third-party concentration risk with regard to the ICT third-party service providers supporting a critical or important function or material part thereof, considering a risk-based approach and the principle of proportionality. To enable this assessment, financial entities should be required to document within the register of information only those subcontractors that effectively underpin ICT services supporting critical or important functions or material part thereof, including all the subcontractors providing ICT services whose disruption would impair the security or the continuity of the service provision. In identifying those subcontractors, financial entities should consider business and ICT service continuity and ICT security aspects.
(7) In case a financial entity outsources a function or activity to a service provider, and this service provider makes use of ICT services to support this function or activity, the responsibility for ensuring the operational resilience of that function or activity remains with the financial entity. Therefore, for the purpose of the register of information, the service provider should be treated as a direct ICT third-party service provider. In the case where a financial entity or a management entity acting on behalf of the financial entity, outsources all its activity to a service provider, the ICT third-party service providers to that service provider should be treated as a direct ICT third-party service provider of the financial entity or of the management entity, respectively.
(8) To allow transparency and comparability of contractual arrangements and their ongoing monitoring, the register of information focuses on the operational links between the financial entities and the ICT third-party service providers. This is enabled by using four keys, which, among others, serve to link relevant data to each other across the templates of the register of information: (i) the contractual arrangement reference number between the financial entity signing the contractual arrangement and the direct ICT third-party provider, (ii) the legal entity identifier (LEI) of financial entities and the ICT third-party service providers, (iii) the function identifier and (iv) the type of ICT services.
(9) The templates of the register of information use a valid LEI to identify financial entities and the ICT third-party service providers who provide ICT services to financial entities either directly or through subcontracting. To enable the competent authorities, the Oversight Forum and the ESAs to carry out their duties as stipulated in Regulation (EU) 2022/2554, it is necessary to use a unique international identifier for an unambiguous and consistent identification of financial entities and ICT third-party service providers at a global level. In contrast to national codes or names of legal entities, LEI is a widely recognised and financially accessible international identifier suited for overseeing complex subcontracting chains where providers from multiple jurisdictions provide ICT services. Only an international identifier allows for aggregation of information at the European level, improving the quality and timeliness of aggregated data and reducing the reporting burden for reporting entities. The template ensures that individuals acting in a business capacity as ICT third-party service providers have an alternative to LEI.
(10) As each financial entity, including financial entities from the same group, have their own internal taxonomy of functions depending on their specific business models and internal organisations, financial entities should themselves identify relevant functions by the function identifier at individual and group level to allow for a clear monitoring between the functions of the financial entities and the ICT services.
(11) To enable the operability of the register of information at entity, sub-consolidated and consolidated level across all the financial entities that are part of the same group, financial entities should ensure the uniformity, correctness and consistency of all the data in the register of information. In particular, ensuring the unicity and consistency across the scope of consolidation of the different keys e.g. the contractual arrangement reference numbers, the function identifier and the unique identifiers of the financial entities and ICT third-party service providers (i.e. ‘LEI’) is crucial to ensure such operability.
(12) The structure of the templates and the requirements of the data points are designed considering data management and reporting perspectives to ensure consistency and harmonisation by design and avoid burdensome reprocessing of data for reporting purposes. When maintaining and updating the register of information, financial entities should adhere to data quality principles and ensuring therefore full comparability of the information reported in the register of information with the one provided in other regulatory or statistical reporting.
(13) This Regulation is based on the draft implementing technical standards submitted to the European Commission by the European Banking Authority, the European Insurance and Occupational Pensions Authority, and the European Securities and Markets Authority (the ESAs).
(14) The ESAs have conducted open public consultations on the draft implementing technical standards on which this Regulation is based, analysed the potential related costs and benefits and requested the advice of the ESAs’ Stakeholder Groups established in accordance with Article 37 of Regulation (EU) No 1093/2010 of the European Parliament and of the Council6 , Article 37 of Regulation (EU) No 1094/2010 of the European Parliament and of the Council7 and Article 37 of Regulation (EU) No 1095/2010 of the European Parliament and of the Council8 .
HAS ADOPTED THIS REGULATION:
CHAPTER I
SUBJECT MATTER AND DEFINITIONS
Article 1
Subject matter
This Regulation lays down implementing technical standards to establish the standard templates for the purposes of the register of information in relation to all contractual arrangements on the use of information and communication technology (ICT) services provided by ICT third-party service providers referred to in Article 28(3) of Regulation (EU) 2022/2554.
[6] Regulation (EU) No 1093/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Banking Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/78/EC (OJ L 331, 15.12.2010, p. 12).
[7] Regulation (EU) No 1094/2010 of the European Parliament and of the Council of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Insurance and Occupational Pensions Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/79/EC (OJ L 331, 15.12.2010, p. 48).
[8] Regulation (EU) No 1095/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Securities and Markets Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/77/EC (OJ L 331, 15.12.2010 p. 84).
Article 2 Definitions
1. For the purposes of this Regulation, the following definitions shall apply:
(a) ‘direct ICT third-party service provider’ means an ICT third-party service provider or ICT intra-group service provider that signed a contractual arrangement with:
a. a financial entity to provide its ICT services directly to that financial entity;
b. a financial or a non-financial entity to provide its services to other financial entities within the same group.
The rank of the direct ICT third-party service provider in the ICT service supply chain is always ‘1’.
(b) ‘subcontractor’ means an ICT third-party service provider or ICT intra-group service provider that provides ICT services to another ICT third-party service provider in the same ICT service supply chain.
The rank of the subcontractor in the ICT service supply chain is always higher than ‘1’;
(c) ‘ICT service supply chain’ means a sequence of contractual arrangements connected with the ICT service being provided by the direct ICT third-party service provider to the financial entity, starting with the direct ICT third-party service provider which has one or multiple other ICT third-party service providers as counterparties (subcontractors);
(d) ‘rank’ means the position of an ICT third-party service provider in the ICT service supply chain. The rank assigned to each ICT third-party service provider is any natural number higher or equal to ‘1’. The lower the natural number assigned to the rank, the closer the arrangement is to the financial entity.
CHAPTER II CONTENT OF THE REGISTER OF INFORMATION
Article 3 General requirements for maintaining and updating the register of information
1. Financial entities that maintain and update the register of information shall ensure that:
a. the register of information includes the required information in relation to all the ICT services provided by direct ICT third-party providers; and
b. the register of information includes information on all subcontractors that effectively underpin ICT services supporting critical or important functions or material part thereof.
2. Financial entities shall ensure that the information contained in the register of information is accurate and consistent. To this end, financial entities shall review the information contained in the register of information on a regular basis. Financial entities shall promptly correct any errors or discrepancies detected. In case of groups, financial entities responsible for maintaining and updating the register of information at sub-consolidated and consolidated level shall ensure that information in relation to entity level within the scope of consolidation is correct and consistent with the information at the sub-consolidated and consolidated level.
3. Financial entities shall maintain the information in the register of information in relation to contractual arrangements that are terminated for at least 5 years after the termination of the provision of the ICT services. This requirement shall apply to the contractual arrangements in force from the date of application of Regulation (EU) 2022/2554.
4. Financial entities shall ensure that the information contained in the register adhere to the principles of data quality, i.e., accuracy, completeness, consistency, integrity, uniqueness, and validity.
5. Financial entities shall use a valid and active legal entity identifier (LEI) to identify all of their ICT third-party service providers that are legal persons, except for individuals acting in a business capacity who chose not to obtain an LEI.
6. When an ICT service provided by a direct ICT third-party service provider is supporting a critical or important function of the financial entities, financial entities shall ensure through the direct ICT third-party service provider, that all the subcontractors included in the register of information according to paragraph (1) point b. of this Article, obtain and maintain a valid and active LEI except if these are individuals acting in a business capacity who chose not to obtain an LEI.
Article 4 Data format requirement
Financial entities maintaining and updating the register of information at entity level, or at sub-consolidated and consolidated level shall complete the templates of the register of information using the formats set out in the instructions in Annex I, in accordance with the following requirements:
1. each template composing the register of information shall be a table with a predefined number of columns but an indefinite number of rows;
2. financial entities shall complete each data point with a single value. If more than one value is valid for a specific data point, the financial entities shall add an additional row in the corresponding template for each valid value;
3. financial entities shall report all data points in the register of information at entity level, sub-consolidated and consolidated level, as applicable. If the data is not applicable, financial entities shall record the string ‘not applicable’;
4. financial entities shall express all amounts in the same currency used by the financial entity for the preparation of the financial statements at entity, sub-consolidated or consolidated level, as applicable;
5. when amounts are in a currency other than the currency used for the purposes of maintaining the register of information, financial entities shall convert the amounts into the reporting currency using the same basis of conversion as they use for accounting purposes.
Article 5
Content of the register of information
1. Financial entities shall include in the register of information at least the following information:
(a) general information on the financial entity maintaining and updating the register of information at entity, sub-consolidate and consolidated level, respectively as specified in template RT.01.01 and in accordance with the instructions set out in Annex I of this Regulation;
(b) general information on the entities in the scope of consolidation as specified in template RT.01.02 and in accordance with the instructions set out in Annex I of this Regulation;
(c) identification of the branches of financial entities located outside the home country listed in template RT.01.02, where applicable, as specified in template RT.01.03 and in accordance with the instructions set out in Annex I of this Regulation;
(d) general information on the contractual arrangements as specified in template RT.02.01 and in accordance with the instructions set out in Annex I of this Regulation;
(e) specific information on the contractual arrangements as specified in template RT.02.02, and in accordance with the instructions set out in Annex I of this Regulation;
(f) information on the links between intra-group contractual arrangements and contractual arrangements with ICT third-party service provider which are not part of the group using the contractual reference numbers when part of the ICT service supply chain is intra-group as specified in template RT.02.03, and in accordance with the instructions set out in Annex I of this Regulation;
(g) information on the links between intra-group contractual arrangements and contractual arrangements with ICT third-party service provider which are not part of the group using the contractual reference numbers when part of the ICT service supply chain is intra-group as specified in template RT.02.03, and in accordance with the instructions set out in Annex I of this Regulation;
(h) information on the entities signing the contractual arrangements with the direct ICT third-party service providers for receiving ICT services or on behalf of the entities making use of the ICT services as specified in template RT.03.01 and in accordance with the instructions set out in Annex I of this Regulation;
(i) identification of the ICT third-party service providers signing the contractual arrangements for providing ICT service(s) as specified in template RT.03.02 and in accordance with the instructions set out in Annex I of this Regulation;
(j) identification of the entities signing the contractual arrangements for providing ICT service(s) to other entities within the scope of consolidation as specified in template RT.03.03 and in accordance with the instructions set out in Annex I of this Regulation;
(k) information on the entities making use of the ICT services provided by the ICT third-party service providers as specified in template RT.04.01 and in accordance with the instructions set out in Annex I of this Regulation;
(l) information on the direct ICT third-party service providers and subcontractors, as specified in template RT.05.01 and in accordance with the instructions set out in Annex I of this Regulation;
(m)information on the ICT service supply chain, as specified in template RT.05.02 and in accordance with the instructions set out in Annex I of this Regulation;
(n) information on the identification of functions as specified in template RT.06.01, and in accordance with the instructions set out in Annex I of this Regulation;
(o) information on the assessment of the ICT services provided by ICT third-party service providers supporting a critical or important function or material part thereof provided as specified in template RT.07.01 and in accordance with the instructions set out in Annex I of this Regulation;
(p) information on the internal definitions used by financial entities and the terms included in close lists and taxonomies used when filling in the templates as
specified in template RT.99.01 and in accordance with the instructions set out in Annex I of this Regulation.
2. Where relevant for their risk management or contract management purposes, financial entities may include into the register of information additional information not specified in this Regulation in the format that is most appropriate for the purposes of such additional information.
CHAPTER III
SCOPE OF CONSOLIDATION
Article 6
Scope of the register of information at sub-consolidated and consolidated level
1. In the case of groups, the parent undertakings shall take into account the relevant financial services regulations when identifying the scope of entities to be included in the register of information.
2. Register of information maintained and updated at sub-consolidated and consolidated levels shall encompass all financial entities and ICT intra-group service providers, which are part of the sub-group and group.
CHAPTER IV
FINAL PROVISIONS
Article 7
Entry into force
This regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union
This Regulation shall be binding in its entirety and directly applicable in all Member States.
Done at Brussels,
For the Commission
The President
On behalf of the President
[Position]
.ANNEX I
Instructions for completing the register of information
Part 1
General instructions
Financial entities while maintaining and updating the register of information at entity, subconsolidated and consolidated level, shall fill-in the templates of the register of information with data using the formats set out in the instructions in Part 2 of this annex.
Part 2 of this annex lays down instructions to be followed by financial entities to complete each column of each template. In order to complete the information of certain columns, financial entities shall refer to other annexes of this Regulation or other external sources to complete the templates. In such cases, the reference to the relevant annexes or external sources is indicated in the instructions.
List of the templates
| Template Code | Template Name | Short Description |
|---|---|---|
| RT.01.01 | Entity maintaining the register of information | This template identifies the entity maintaining and updating the register of information at entity, sub-consolidated and consolidated level, respectively. |
| RT.01.02 | List of entities within the scope of consolidation | This template identifies all the entities belonging to the group. In case the financial entity responsible for maintaining and updating the register of information does not belong to a group, only this financial entity shall be reported in this template. |
| RT.01.03 | List of branches | Objective of this template is to identify the branches of the financial entities referred to in template RT.01.02. |
| RT.02.01 | Contractual arrangements – general information | Objective of this template is to list all contractual arrangements with direct ICT third-party service providers. For each contractual arrangement with direct ICT third-party service provider, the financial entity maintaining the register of information shall assign a unique ‘contractual arrangement reference number’ to identify unambiguously the contractual arrangement itself. |
| RT.02.02 | Contractual arrangements – specific information | Objective of this template is to provide details in relation to each contractual arrangement listed in template RT.02.01 with regard to: (i) the ICT services included in the scope of the contractual arrangement; (ii) the functions of the financial entities supported by those ICT services; (iii) other important information in relation to the specific ICT services provided (e.g. notice period, law governing the arrangement, etc.). |
| RT.02.03 | List of intra-group contractual arrangements | Objective of this template is to identify the links between intra-group contractual arrangements and contractual arrangements with ICT third-party service provider which are not part of the group using the contractual reference numbers when part of the ICT service supply chain. |
| RT.03.01 | Entities signing the contractual arrangements for receiving ICT service(s) or on behalf of the entities making use of the ICT service(s) | Objective of this template is to provide information on the entity signing the contractual arrangements with the direct ICT third-party service provider for the entity making use of the ICT services. In case the register of information is maintained and updated at entity level, the entity signing the contractual arrangement and the entity making use of the ICT services is the financial entity maintaining and updating the register of information. Within the scope of sub-consolidation and consolidation, the financial entity making use of the ICT services provided is not necessarily the entity signing the contractual arrangement with the ICT third-party service providers. |
| RT.03.02 | ICT third-party service providers signing the Contractual arrangements for | Objective of this template is to identify all the ICT third-party service providers referred to in template RT.05.01 signing the contractual arrangements referred to in template RT.02.01 for providing the ICT services. |
| providing ICT service(s) | ||
| RT.03.03 | Entities signing the Contractual arrangements for providing ICT service(s) to other entities within the scope of consolidation | Objective of this template is to identify all the entities referred to in template RT.01.02 signing the contractual arrangements referred to in template RT.02.01 for providing the ICT services to other entities in the scope of consolidation. |
| RT.04.01 | Entities making use of the ICT services | Objective of this template is to ensure that all entities making uses of the ICT services provided by ICT third-party service providers are registered in the register of information. The entities making use of the ICT services shall be either the financial entities in scope, either the ICT intra-group service providers. In case the register of information is maintained and updated at entity level, the entity signing the contractual arrangement and the entity making use of the ICT services are the financial entity maintaining the register. |
| RT.05.01 | ICT third-party service providers | Objective of this template is to list and provide general information to enable the identification of: (i) the direct ICT third-party service providers; (ii) the ICT intra-group service providers; (iii) all subcontractors included in template RT.05.02 on ICT service supply chain; (iv) and identify the ultimate parent undertaking of the ICT third-party service providers listed in points (i) to (iii) above. |
| RT.05.02 | ICT service supply chain | Objective of this template is to identify and link one to another the ICT third-party service providers that are part of the same ICT service supply chain. |
Template
Code
Template Name Short Description
Financial entities shall identify and rank the ICT third- party service providers for each ICT service included in the scope of each contractual arrangement.
Example: a financial entity has a contractual arrangement with an ICT third-party service provider (say, ICT third-party service provider X) to receive 2 specific ICT services (say ICT service A and ICT service B) and the service provider makes use of a subcontractor (say, ICT third-party service provider Y) to provide one of these services (say ICT service B). In relation to ICT service A, the ICT service supply chain is composed by one ICT third-party service provider, ICT third-party service provider X, which will be given ‘rank’ 1 in the template. ICT third- party service provider X is the direct ICT third- party service provider. In relation to ICT service B, the ICT service supply chain is composed by two ICT third-party service providers:
(i) ICT third-party service provider X, which will be given ‘rank’ 1 in the template. ICT third-party service provider X is the direct ICT third-party service provider.
(ii) ICT third-party service provider Y, which will be given ‘rank’ 2 in the template. ICT third-party service provider Y is a subcontractor.
All ICT third-party service providers belonging to the same ICT service supply chain share the same ‘contractual arrangement reference number’ as referred to in template RT.02.01 and the same type of ICT services RT.06.01 Functions identification Objective of this template is to identify and provide information on the functions of the financial entity making use of the ICT services.
| Template Code | Template Name | Short Description |
|---|---|---|
| Within the information to be provided within this template, financial entities shall include a unique identifier, the ‘function identifier’ for each combination of a financial entity’s LEI, licenced activity and function. Example: a financial entity (LEI: 21USLEIC20231109J3Z8) which operates under two licensed activities (say, activity A and activity B) will identify two unique ‘function identifiers’ for the same function X (e.g. Sales) performed for activity A and activity B. The function identifier will be: F1 for the combination of “21USLEIC20231109J3Z8” “Activity A” and ‘Function X” F2 for the combination of “21USLEIC20231109J3Z8” “Activity B” and ‘Function X” | ||
| RT.07.01 | Assessments of the ICT services | Objective of this template is to capture information in relation to the risk assessment on the ICT services (e.g. substitutability, date of last audit, etc.) when the latter are supporting a critical or important function or material part thereof. |
| RT.99.01 | Definitions from Entities making use of the ICT Services | Objective of this template is to capture entity-internal explanations, meanings and definitions of the closed set of indicators used in the register of information. For example, in template RT.07.01 financial entitiy shall provide an indication of the impact of discontinuation of the ICT services by using a closed set of options (low medium, high). In template RT99.01 the financial entity needs to specify the meaning of those options. |
Part 2 Template-specific instructions
–
1. Instructions to complete template RT.01.01 — Entity maintaining the register of information
Identify the entity maintaining and updating the register of information.
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.01.01.0010 | LEI of the entity maintaining the register of information | Alphanumerical | Identify the entity maintaining and updating the register of information using the LEI, 20-character, alpha-numeric code based on the ISO 17442 standard | Mandatory |
| RT.01.01.0020 | Name of the entity | Alphanumerical | Legal name of the entity maintaining and updating the register of information | Mandatory |
| RT.01.01.0030 | Country of the entity | Country | Identify the ISO 3166–1 alpha–2 code of the country where the license or the registration of the entity reported in the Register on Information has been issued. | Mandatory |
| RT.01.01.0040 | Type of entity | Closed set of options | Identify the type of entity using one of the options in the following closed list: 1. credit institutions; 2. payment institutions, including payment institutions exempted pursuant to Directive (EU) 2015/2366; 3. account information service providers; 4. electronic money institutions, including electronic money institutions exempted pursuant to Directive 2009/110/EC; 5. investment firms; 6. crypto-asset service providers as authorised under a Regulation of the European Parliament and of the Council on markets in crypto-assets, and amending Regulations (EU) No 1093/2010 and (EU) No | Mandatory |
| 1095/2010 and Directives 2013/36/EU and (EU) 2019/1937 (‘the Regulation on markets in crypto-assets’) and issuers of asset-referenced tokens; 7. central securities depositories; 8. central counterparties; 9. trading venues; 10. trade repositories; 11. managers of alternative investment funds; 12. management companies; 13. data reporting service providers; 14. insurance and reinsurance undertakings; 15. insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries; 16. institutions for occupational retirement provision; 17. credit rating agencies; 18. administrators of critical benchmarks; 19. crowdfunding service providers; 20. securitisation repositories. 21. Other financial entity 22. Non-financial entity: ICT intra-group service provider 23. Non-financial entity: Other | ||||
| RT.01.01.0050 | Competent Authority | Alphanumerical | Identify the competent authority according to Article 46 of Regulation (EU) 2022/2554 to which the register of information is reported. | Mandatory in case of reporting |
| RT.01.01.0060 | Date of the reporting | Date | Identify the ISO 8601 (yyyy–mm–dd) code of the date of reporting | Mandatory in case of reporting |
2. Instructions to complete template RT.01.02 —List of entities within the scope of the register of information
In case the register of information is maintained and updated at sub-consolidated and consolidated level, this template identifies all the entities belonging to the sub-group and group. In case the financial entity responsible for maintaining and updating the register of information does not belong to a group, only this financial entity shall be reported in this template and the entry of this template shall be the same as template RT.01.01.
In case a financial entity or a management entity acting on behalf of the financial entity outsources all its operational activities to a service provider, the ICT third-party service providers of the financial entity or of the management entity shall be recorded as the ICT third-party service providers of the financial entity. In this case, both, the financial entity or the management entity and the service provider shall be reported in this template.
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.01.02.0010 | LEI of the entity | Alphanumerical | Identify the entity reported in the Register on Information using the LEI, 20-character, alpha-numeric code based on the ISO 17442 standard | Mandatory |
| RT.01.02.0020 | Name of the entity | Alphanumerical | Legal name of the entity reported in the register of information. | Mandatory |
| RT.01.02.0030 | Country of the entity | Country | Identify the ISO 3166–1 alpha–2 code of the country where the license or the registration of the entity reported in the Register on Information has been issued. | Mandatory |
| RT.01.02.0040 | Type of entity | Closed set of options | Identify the type of entity using one of the options in the following closed list: 1. credit institutions; 2. payment institutions, including payment institutions exempted pursuant to Directive (EU) 2015/2366; 3. account information service providers; 4. electronic money institutions, including electronic money institutions exempted pursuant to Directive 2009/110/EC; 5. investment firms; 6. crypto-asset service providers as authorised under a Regulation of the European Parliament and of the Council on markets in crypto-assets, and amending Regulations (EU) No 1093/2010 and (EU) No 1095/2010 and Directives 2013/36/EU and (EU) 2019/1937 (‘the | Mandatory |
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| Regulation on markets in crypto-assets’) and issuers of asset-referenced tokens; 7. central securities depositories; 8. central counterparties; 9. trading venues; 10. trade repositories; 11. managers of alternative investment funds; 12. management companies; 13. data reporting service providers; 14. insurance and reinsurance undertakings; 15. insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries; 16. institutions for occupational retirement provision; 17. credit rating agencies; 18. administrators of critical benchmarks; 19. crowdfunding service providers; 20. securitisation repositories. 21. Other financial entity 22. Non-financial entity: ICT intra-group service provider 23. Non-financial entity: Other | ||||
| RT.01.02.0050 | Hierarchy of the entity within the group (where applicable) | Closed set of options | Identify the hierarchy of the entity within the scope of consolidation using one of the options in the following closed list: 1. The entity is the ultimate parent undertaking of the scope of consolidation; 2. The entity is the parent undertaking of a sub-consolidated part of the scope of consolidation; 3. The entity is a subsidiary within the scope of consolidation and is not a parent undertaking of a sub-consolidated part; | Mandatory |
| 4. The entity is not part of a group; 5. The entity is a service provider to which the financial entity (or the management entity acting on its behalf) is outsourcing all its operational activities. | ||||
| RT.01.02.0060 | LEI of the direct parent undertaking of the entity | Alphanumerical | Identify the direct parent undertaking of the entity reported in the Register on Information using the LEI, 20-character, alpha-numeric code based on the ISO 17442 standard | Mandatory |
| RT.01.02.0070 | Date of last update | Date | Identify the ISO 8601 (yyyy–mm–dd) code of the date of the last update made on the Register of information in relation to theentity. | Mandatory |
| RT.01.02.0080 | Date of integration in the Register of information | Date | Identify the ISO 8601 (yyyy–mm–dd) code of the date of integration in the Register of information | Mandatory |
| RT.01.02.0090 | Date of deletion in the Register of information | Date | Identify the ISO 8601 (yyyy–mm–dd) code of the date of deletion in the Register of information. If the entity has not been deleted, ‘9999-12-31’ shall be reported | Mandatory |
| RT.01.02.0100 | Currency | Currency | Identify the ISO 4217 alphabetic code of the currency used for the preparation of the financial entity’s financial statements | Mandatory |
| RT.01.02.0110 | Value of total assets - of the financial entity | Monetary | Monetary value of total assets of the entity making use of the ICT services as reported in the entity’s annual financial statement of the year before the date of the last update of the register of information. Refer to Annex IV for the approach to be followed when filling in this column. | Mandatory if the entity is a financial entity |
3. Instructions to complete template RT.01.03 — List of branches
In case a financial entity has branches located outside its home country, identify those branches through this template.
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.01.03.0010 | Identification code of the branch | Alphanumerical | Identify a branch of a financial entity located outside its home country using a unique code for each branch. One of the options in the following closed list shall be used: - LEI of the branch if unique for this branch and different from RT.01.03.0020; - Other identification code used by the financial entity to identify the branch (if the LEI of the branch is equivalent to the one in RT.01.03.0020 or equivalent to the LEI of another branch). | Mandatory |
| RT.01.03.0020 | LEI of the financial entity head office of the branch | Alphanumerical | As referred to in RT.01.02.0010 Identify the financial entity head office of the branch, using the LEI, 20-character, alpha-numeric code based on the ISO 17442 standard | Mandatory |
| RT.01.03.0030 | Name of the branch | Alphanumerical | Identify the name of the branch | Mandatory |
| RT.01.03.0040 | Country of the branch | Country | Identify the ISO 3166–1 alpha–2 code of the country where the branch is located. | Mandatory |
4. Instructions to complete template RT.02.01 — Contractual arrangements – General Information
Financial entities shall identify a ‘contractual arrangement reference number’ in relation to each contractual arrangement in scope of the register of information. In case the ICT third-party service provider is making use of subcontractors, financial entities shall not include in the register of information a ‘contractual arrangement reference number’ for the arrangements between the ICT third-party service providers and their subcontractors.
The ‘contractual arrangement reference number’ shall refer to the following type of contractual arrangements:
i. any kind of standalone arrangements.
ii. any kind of ‘overarching or framework arrangements’ such as master and framework arrangements;
iii. any kind of ‘subsequent or associated arrangements’ such as implementing arrangements, subservice arrangements, amendments, order forms;
The contract reference number does not refer to any kind of service level agreement subordinated to any of the above-mentioned types of contractual arrangements.
| Column Code | Column Name | Type | Fill -in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.02.01.0010 | Contractual arrangement reference number | Alphanumerical | Identify the contractual arrangement between the financial entity or, in case of a group, the group subsidiary and the direct ICT third-party service provider. The contractual arrangement reference number is the internal reference number of the contractual arrangement assigned by the financial entity. The contractual arrangement reference number shall be unique and consistent over time at entity, sub-consolidated and consolidated level, where applicable. The contractual arrangement reference number shall be used consistently across all templates of the register of information when referring to the same contractual arrangement. | Mandatory |
| RT.02.01.0020 | Type of contractual arrangement | Closed set of options | Identify the type of contractual arrangement by using one of the options in the following closed list: 1. Standalone arrangement | Mandatory |
| Column Code | Column Name | Type | Fill -in Instruction | Fill-in Option |
|---|---|---|---|---|
| 2. Overarching arrangement 3. Subsequent or associated arrangement | ||||
| RT.02.01.0030 | Overarching contractual arrangement reference number | Alphanumerical | Not applicable if the contractual arrangement is the ‘overarching contractual arrangement’ or a ‘standalone arrangement’. In the other cases, report the contractual arrangement reference number of the overarching arrangement, which shall be equal to value as reported in the column RT.02.01.0010 when reporting the overarching contractual arrangement. | Mandatory |
| RT.02.01.0040 | Currency of the amount reported in RT.02.01.0050 | Currency | Identify the ISO 4217 alphabetic code of the currency used to express the amount in RT.02.01.0050 | Mandatory |
| RT.02.01.0050 | Annual expense or estimated cost of the contractual arrangement for the past year | Monetary | Annual expense or estimated cost (or intragroup transfer) of the ICT service arrangement for the past year. The annual expense or estimated cost shall be expressed in the currency reported in RT.01.02.0040. In case of an overarching arrangement with subsequent or associated arrangements, the sum of the annual expenses or estimated costs reported for the overarching arrangement and the subsequent or associated arrangements shall be equal to the total expenses or estimated costs for the overall contractual arrangement. This means, there should be no repetition or duplication of annual expenses or estimated costs. The following cases should be reflected: (a) if the annual expenses or estimate costs are not determined at the level of the overarching arrangement (i.e. they are 0), the annual expenses or estimated costs | Mandatory |
| should be reported at the level of each subsequent or associated arrangements. | ||||
| (b) if the annual expenses or estimated costs cannot be reported for each of the subsequent or associated arrangements, the total annual expense or estimated cost should be reported at the level of the overarching arrangement. | ||||
| (c) if there are annual expenses or estimated costs related to each level of the arrangement, i.e. overarching and subsequent or associated, and this information is available, the annual expenses or estimated costs shall be reported without duplication at each level of the contractual arrangement. |
5. Instructions to complete template RT.02.02 — Contractual arrangements – Specific information
Financial entities shall maintain this template at the maximum level of granularity possible. In order to do so, in case the contractual arrangement includes multiple ICT services supporting multiple functions, use as many rows as the elements in the matrix resulting combining the ICT services covered in the contractual arrangement and the financial entity’s functions.
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.02.02.0010 | Contractual arrangement reference number | Alphanumerical | As reported in RT.02.01.0010 | Mandatory |
| RT.02.02.0020 | LEI of the entity making use of the ICT service(s) | Alphanumerical | As reported in RT.04.01.0020 Identify the entity making use of the ICT service(s) using the LEI, 20-character, alpha-numeric code based on the ISO 17442 standard | Mandatory |
| RT.02.02.0030 | Identification code of the ICT third-party service provider | Alphanumerical | As reported in RT.05.01.0010 Code to identify the ICT third-party service provider | Mandatory |
| RT.02.02.0040 | Type of code to identify the ICT third-party service provider | Pattern | As reported in RT.05.01.0020 Identify the type of code to identify the ICT third-party service provider in RT.02.02.0030 1. ‘LEI’ for LEI 2. ‘Country Code’+Underscore+’Type of Code’ for non LEI code Country Code: Identify the ISO 3166–1 alpha–2 code of the country of issuance of the other code to identify the ICT third-party service provider Type of Code: | Mandatory |
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| 1. CRN for Corporate registration number 2. VAT for VAT number 3. PNR for Passport Number 4. NIN for National Identity Number | ||||
| RT.02.02.0050 | Function identifier | Pattern | As defined by the financial entity in RT.06.01.0010 | Mandatory |
| RT.02.02.0060 | Type of ICT services | Closed set of options | One of the types of ICT services referred to in Annex III | Mandatory |
| RT.02.02.0070 | Start date of the contractual arrangement | Date | Identify the date of entry into force of the contractual arrangement as stipulated in the contractual arrangement using the ISO 8601 (yyyy–mm–dd) code | Mandatory |
| RT.02.02.0080 | End date of the contractual arrangement | Date | Identify the end date as stipulated in the contractual arrangement using the ISO 8601 (yyyy–mm–dd) code. If the contractual arrangement is indefinite, it shall be filled in with ‘9999-12-31’. If the contractual arrangement has been terminated on a date different than the end date, this shall be filled in with the termination date. In case the contractual arrangement foresees a renewal, this shall be filled in with the date of the contract renewal as stipulated in the contractual arrangement. | Mandatory |
| RT.02.02.0090 | Reason of the termination or ending of the contractual arrangement | Closed set of options | In case the contractual arrangement has been terminated or it is ended, identify the reason of the termination or ending of the contractual arrangements using one of the options in the following closed list: 1. Termination not for cause. The contractual arrangement has expired/ended and has not been renewed by any of the party; | Mandatory if the contractual arrangement is terminated |
| Column Code Column Name | Type | Fill-in Instruction | Fill-in Option | |
| 2. Termination for cause. The contractual arrangement has been terminated, being the ICT third-party service provider in a breach of applicable law, regulations or contractual provisions 3. Termination for cause. The contractual arrangement has been terminated, due to impediments of the ICT third-party service provider capable of altering the supported function are identified; 4. Termination for cause: The contractual arrangement has been terminated due to weaknesses of the ICT third-party provider regarding the management and security of sensitive data or information of any of the counterparty; 5. Termination following a request by any Authority. The contractual arrangement has been terminated following a request by a Competent Authority. 6. Other. The contractual arrangement has been terminated by any of the party for any reason different from the above. | ||||
| RT.02.02.0100 Notice period for the financial entity making use of the ICT service(s) | Natural number | Identify the notice period for terminating the contractual arrangement by the financial entity in a business-as-usual case. The notice period shall be expressed as number of calendar days from the receipt of the counterparty of the request to terminate the ICT service. | Mandatory if the ICT service is supporting a critical or important function | |
| RT.02.02.0110 Notice period for the ICT third-party service provider | Natural number | Identify the notice period for terminating contractual arrangement by the direct ICT third-party service provider in a business-as-usual case. The notice period shall be expressed as number of calendar days from the receipt of the counterparty of the request to terminate the ICT service. | Mandatory if the ICT service is supporting a critical or important function |
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.02.02.0120 | Country of the governing law of the contractual arrangement | Country | Identify the country of the governing law of the contractual arrangement using the ISO 3166–1 alpha–2 code. | Mandatory if the ICT service is supporting a critical or important function |
| RT.02.02.0130 | Country of provision of the ICT services | Country | Identify the country of provision of the ICT services using the ISO 3166–1 alpha–2 code. | Mandatory if the ICT service is supporting a critical or important function |
| RT.02.02.0140 | Storage of data | [Yes/No] | Is the ICT service related to (or foresees) storage of data? One of the options provided in the following closed list: 1. Yes 2. No | Mandatory if the ICT service is supporting a critical or important function |
| RT.02.02.0150 | Location of the data at rest (storage) | Country | Identify the country of location of the data at rest (storage) using the ISO 3166–1 alpha–2 code. | Mandatory if ’Yes’ is reported in RT.02.02.0140 |
| RT.02.02.0160 | Location of management of the data (processing) | Country | Identify the country of location of management of the data (processing) using the ISO 3166–1 alpha–2 code. | Mandatory if the ICT service is based on or foresees data processing |
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.02.02.0170 | Sensitiveness of the data stored by the ICT third-party service provider | Closed set of options | Identify the level of sensitiveness of the data stored or processed by the ICT third-party service provider using one of the options provided in the following closed list: 1. Low or Medium 2. High The most sensitive data take precedence: e.g. if both ‘Medium’ and ‘High’ apply, then ‘High’ shall be selected. | Mandatory if the ICT third-party service provider stores data and if the ICT service is supporting a critical or important function or material part thereof |
| RT.02.02.0180 | Level of reliance on the ICT service supporting the critical or important function. | Closed set of options | One of the options in the following closed list shall be used: 1. Not significant 2. Low reliance: in case of disruption of the services, the supported functions would not be significantly impacted (no interruption, no important damage) or disruption can be resolved quickly and with minimal impact on the function/s supported 3. Material reliance: in case of disruption of the services, the supported functions would be significantly impacted if the disruption lasts more than few minutes/few hours, and the disruption may engender damages, but still manageable 4. Full reliance: in case of disruption of the services, the supported functions would be immediately and severely interrupted/damaged, for a long period | Mandatory if the ICT service is supporting a critical or important function or material part thereof |
6. Instructions to complete template RT.02.03 — List of intra-group contractual arrangements
Template RT.02.03 aims at identifying contractual arrangements from the same ICT service supply chain using the intra-group contractual reference numbers in cases where the ICT service supply chain contains ICT intra-group service providers, i.e. when in case at least one of the ICT third-party service provider in the ICT service supply chain is an entity belonging to the same group of the entity making use of the ICT services.
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.02.03.0010 | Contractual arrangement reference number | Alphanumerical | Contractual arrangement reference number between the entity making use of the ICT service(s) provided and the ICT intra-group service provider. The contractual arrangement reference number shall be unique and consistent over time and across all the group. | Mandatory |
| RT.02.03.0020 | Contractual arrangement linked to the contractual arrangement referred in RT.02.03.0010 | Alphanumerical | Contractual arrangement reference number of the contractual arrangement between the ICT intra-group service provider of the contractual arrangement in RT.02.03.0010 and its direct ICT third-party service provider | Mandatory |
7. Instructions to complete template RT.03.01 — Entities signing the Contractual arrangements for receiving ICT service(s) or on behalf of the entities making use of the ICT service(s)
Identify all the entities referred to in template RT.01.02 signing the contractual arrangements referred to in template RT.02.01 for receiving the ICT services. In case the register of information is maintained and updated at entity level the entity signing the contractual arrangements is the financial entity maintaining and updating the register of information itself.
The entity signing the contractual arrangement is not necessarily a financial entity nor the entity making use of the ICT services provided by the ICT third-party service provider.
For example, the entity signing the contractual arrangement referred above could be an ICT intra-group service provider, a financial and/or non-financial entity belonging to the same group of the financial entities making use of the ICT services provided by the ICT third-party service provider.
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.03.01.0010 | Contractual arrangement reference number | Alphanumerical | As reported in RT.02.02.0010 Identify the contractual reference number signed by the entity | Mandatory |
| RT.03.01.0020 | LEI of the entity signing the contractual arrangement | Alphanumerical | Identify the entity signing the contractual arrangement using the LEI, 20-character, alpha-numeric code based on the ISO 17442 standard | Mandatory |
8. Instructions to complete template RT.03.02 — ICT third-party service providers signing the Contractual arrangements for providing ICT service(s)
Identify all the ICT third-party service providers referred to in template RT.05.01 signing the contractual arrangements referred to in template RT.02.01 for providing the ICT services.
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.03.02.0010 | Contractual arrangement reference number | Alphanumerical | As reported in RT.02.02.0010 | Mandatory |
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| Identify the contractual arrangement reference number signed by the ICT third-party service provider | ||||
| RT.03.02.0020 | Identification code of ICT third-party service provider | Alphanumerical | As reported in RT.05.01.0010 Code to identify the ICT third-party service provider | Mandatory |
| RT.03.02.0030 | Type of code to identify the ICT third-party service provider | Pattern | As reported in RT.05.01.0020 Identify the type of code to identify the ICT third-party service provider in RT.03.02.0020 1. ‘LEI’ for LEI 2. ‘Country Code’+Underscore+’Type of Code’ for non LEI code Country Code: Identify the ISO 3166–1 alpha–2 code of the country of issuance of the other code to identify the ICT third-party service provider Type of Code: 1. CRN for Corporate registration number 2. VAT for VAT number 3. PNR for Passport Number 4. NIN for National Identity Number | Mandatory |
9. Instructions to complete template RT.03.03 — Entities signing the Contractual arrangements for providing ICT service(s) to other entity within the scope of consolidation.
Identify all the entities referred to in template RT.01.02 signing the contractual arrangements referred to in template RT.02.01 for providing the ICT services to other entities in the scope of consolidation referred to in template RT.01.02.
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.03.03.0010 | Contractual arrangement reference number | Alphanumerical | As reported in RT.02.02.0010 Identify the contractual reference number signed by the entity for providing ICT service(s) | Mandatory |
| RT.03.03.0020 | LEI of the entity providing ICT services | Alphanumerical | As reported in RT.01.02.0010 Identify the entity providing ICT services using LEI, 20-character, alpha-numeric code based on the ISO 17442 standard | Mandatory |
10. Instructions to complete template RT.04.01 —Entities making use of the ICT services
All the entities referred to in template RT.01.02 and branches of financial entity referred in template RT.01.03 making use of the ICT services provided by ICT third-party shall be reported in this template.
| Column Code | Column Name | Type | Fil-in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.04.01.0010 | Contractual arrangement reference number | Alphanumerical | As reported in RT.02.01.0010 Identify the contractual reference number in relation to the entity making use of the ICT services provided | Mandatory |
| RT.04.01.0020 | LEI of the entity making use of the ICT service(s) | Alphanumerical | Identify the entity making use of the ICT service(s) using the LEI, 20-character, alpha-numeric code based on the ISO 17442 standard | Mandatory |
| RT.04.01.0030 | Nature of the entity making use of the ICT service(s) | Closed set of options | One of the options in the following closed list shall be used: 1. The entity making use of the ICT service(s) is a branch of a financial entity 2. The entity making use of the ICT service(s) is not a branch | Mandatory |
| RT.04.01.0040 | Identification code of the branch | Alphanumerical | Identification code of the branch as reported in RT.01.03.0010 | Mandatory if the entity making use of the ICT service(s) is a branch of a financial entity (RT.04.01.0030) |
11. Instructions to complete template RT.05.01 — ICT third-party service provider
This template aims at identifying all the relevant ICT third-party service providers:
-
all the direct ICT third-party providers;
-
the ICT intra-group service provider;
-
the subcontractors reported in template RT.05.02 on the ICT service supply chain (in line with Article 3);
-
and identify the ultimate parent undertaking of the ICT third-party service providers listed in the three points above.
Column Code Column Name Type Fill-in Instruction Fill-in Option RT.05.01.0010 Identification code of ICT third-party service provider Alphanumerical Code to identify the ICT third-party service provider Mandatory RT.05.01.0020 Type of code to identify the ICT third- party service provider Pattern Identify the type of code to identify the ICT third-party service provider in RT.05.01.0010
1. ‘LEI’ for LEI
2. ‘Country Code’+Underscore+’Type of Code’ for non LEI code
Country Code: Identify the ISO 3166–1 alpha–2 code of the country of issuance of the other code to identify the ICT third- party service provider Type of Code:
1. CRN for Corporate registration number
2. VAT for VAT number
3. PNR for Passport Number
4. NIN for National Identity Number
Mandatory
RT.05.01.0030 Name of the
ICT third-Alphanumerical Legal name of the ICT third-party service provider Mandatory
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| party service provider | ||||
| RT.05.01.0040 | Type of person of the ICT third-party service provider | Closed set of options | One of the options in the following closed list shall be used: 1. Legal person 2. Individual acting in a business capacity Providing the LEI is mandatory for legal person including natural persons acting in a business capacity | Mandatory |
| RT.05.01.0050 | Country of the ICT third-party service provider’s headquarters | Country | Identify the ISO 3166–1 alpha–2 code of the country in which the global operating headquarters of ICT third-party service provider are located. | Mandatory |
| RT.05.01.0060 | Currency of the amount reported in RT.05.01.0070 | Currency | Identify the ISO 4217 alphabetic code of the currency used to express the amount in RT.05.01.0070 | Mandatory if RT.05.01.0070 is reported |
| RT.05.01.0070 | Total annual expense or estimated cost of the ICT third-party service provider | Monetary | Annual expense or estimated cost for using the ICT services provided by the ICT third-party service provider to the entities making use of the ICT services | Mandatory if the ICT third-party service provider is a direct ICT third-party service provider |
| RT.05.01.0080 | Identification code of the ICT third-party service | Alphanumerical | Code to identify the ICT third-party service provider’s ultimate parent undertaking | Mandatory if the ICT third-party service provider is not the |
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| provider’s ultimate parent undertaking | ultimate parent undertaking | |||
| RT.05.01.0090 | Type of code to identify the ICT third-party service provider’s ultimate parent undertaking | Pattern | Identify the type of code to identify the ICT third-party service provider’s ultimate parent undertaking in RT.05.01.0080 1. ‘LEI’ for LEI 2. ‘Country Code’+Underscore+’Type of Code’ for non LEI code Country Code: Identify the ISO 3166–1 alpha–2 code of the country of issuance of the other code to identify the ICT third-party service provider Type of Code: 1. CRN for Corporate registration number 2. VAT for VAT number 3. PNR for Passport Number 4. NIN for National Identity Number | Mandatory if the ICT third-party service provider is not the ultimate parent undertaking |
12. Instructions to complete template RT.05.02 — ICT service supply chains
This template aims at identifying and linking one to each other the ICT third-party service providers part of the same ICT service supply chain.
In line with Article 3, the ICT service supply chain shall include, where applicable:
(i) all ICT direct ICT third-party service providers;
(ii) all ICT intragroup service providers;
(iii) in relation to the ICT services supporting a critical or important function or material part thereof, the register of information includes all subcontractors that effectively underpin the provision of these ICT services (i.e. all the subcontractors providing ICT services whose disruption would impair the security or the continuity of the service provision);
(iv) in case an ICT intragroup service provider makes use of subcontractors to provide their ICT services to the financial entity, at least the first extra-group subcontractor even if the ICT services provided do not support a critical or important function or material part thereof.
All ICT third-party service providers belonging to the same ICT service supply chain share:
(i) the same ‘contractual arrangement reference number’ as referred to in template RT.02.01;
(ii) the same ‘type of ICT services’ as referred to in Annex III;
Each ICT third-party service providers belonging to the same ICT service supply is assigned with a ‘rank’ (RT.05.02.0050) to identify its position within the ICT service supply chain. In case multiple ICT third-party service providers have the same position within the same ICT service supply chain, they will be assigned with the same ‘rank’. The direct ICT third-party service providers are therefore at rank 1. If the rank is higher than 1, the ICT third-party service providers are subcontractors.
In order to link one to each other the ICT third-party service providers belonging to the same ICT service supply chain, for each ICT subcontractor (i.e. where the ‘rank’ is higher than 1) it is needed to identify the ICT third-party service provider recipient of its subcontracted services. The identification of the ICT third-party service provider recipient of subcontracted services shall be carried out by using the columns RT.05.02.0060 and RT.05.02.0070.
For each ICT service supply chain (i.e., a combination of a "contractual arrangement reference number" and a "type of ICT services "), if there are multiple ICT third-party service providers receiving subcontracted services, all of these service providers shall be reported in separate rows in the template. The same logic applies at each rank of the ICT service supply chain.
| Column Code Column Name | Type | Fill-in Instruction | Fill-in Option | |
|---|---|---|---|---|
| RT.05.02.0010 Contractual arrangement reference number | Alphanumerical | As reported in RT.02.01.0010 | Mandatory | |
| RT.05.02.0020 Type of ICT services | Closed set of options | One of the types of ICT services referred to in Annex III | Mandatory | |
| RT.05.02.0030 Identification code of the ICT third-party service provider | Alphanumerical | As reported in RT.05.01.0010 | Mandatory | |
| RT.05.02.0040 Type of code to identify the ICT third-party service provider | Pattern | As reported in RT.05.01.0020 | Mandatory | |
| RT.05.02.0050 Rank | Natural number | If the ICT third-party service provider is signing the contractual arrangement with the financial entity, it is considered as a direct ICT third-party service provider and the ‘rank’ to be reported shall be 1; If the ICT third-party service provider is signing the contract with the direct ICT third-party service provider, it is considered as a subcontractor and the ‘rank’ to be reported shall be 2; The same logic apply to all the following subcontractors by incrementing the ‘rank’. In case multiple ICT third-party service providers have the same ‘rank’ in the ICT service supply chain, financial entities shall report the same ‘rank’ for all those ICT third-party service providers. | Mandatory | |
| RT.05.02.0060 Identification code of the recipient of sub- | Alphanumerical ‘Not applicable’ if the ICT third-party service provider RT.05.02.0030) is a direct ICT third-party service provider i.e. at ‘rank’ r = 1 (RT.05.02.0050); | Mandatory Not applicable for rank 1 | ||
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
| contracted ICT services | If the ICT third-party service provider is at ‘rank’ r = n where n>1, indicate the ‘Identification code of the recipient of sub-contracted services’ at ‘rank’ r=n-1 that subcontracted the ICT service (even partially) to the ICT third-party service provider at ‘rank’ r=n. | |||
| RT.05.02.0070 | Type of code to identify the recipient of sub-contracted ICT services | Pattern | ‘Not applicable’ if the ICT third-party service provider RT.05.02.0030) is at contracting rank r = 1 (RT.05.02.0050); If the ICT third-party service provider is at ‘rank’ r = n where n>1, indicate the ‘Type of code to identify the recipient of sub-contracted service’ at ‘rank’ r=n-1 that subcontracted the ICT service (even partially) to the ICT third-party service provider at ‘rank’ r=n. 1. ‘LEI’ for LEI 2. ‘Country Code’+Underscore+’Type of Code’ for non LEI code Country Code: Identify the ISO 3166–1 alpha–2 code of the country of issuance of the other code to identify the ICT third-party service provider Type of Code: 1. CRN for Corporate registration number 2. VAT for VAT number 3. PNR for Passport Number 4. NIN for National Identity Number | Mandatory Not applicable for rank 1 |
13. Instructions to complete template RT.06.01 — Functions identification
This template aims at identifying and providing information on the functions of the financial entity according to the financial entity’s internal organisation.Only functions supported by an ICT service provided by ICT third-party providers shall be reported.
Each combination of the three following items shall have a unique function identifier assigned:
i. ‘LEI of the financial entity making use of the ICT service(s)’ column RT.06.01.0040
ii. ‘Licenced activity’ column RT.06.01.0020
iii. ‘Function name’ column RT.06.01.0030
Financial entities shall use as many rows as the elements in the matrix resulting combining the two items above to fill-in this template.
| Column Code | Column Name | Type | Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.06.01.0010 | Function Identifier | Pattern | The function identifier shall be composed by the letter F (capital letter) followed by an natural number (e.g. “F1” for the 1st function identifier and “Fn” for the nth function identifier with “n” being an natural number). Each combination between ‘LEI of the financial entity making use of the ICT service(s)’ (RT.06.01.0040), ‘Function name’ (RT.06.01.0030) and ‘Licenced activity’ (RT.06.01.0020) shall have a unique function identifier Example: a financial entity which operates under two licensed activities (say, activity A and activity B) will identify two unique ‘function identifiers’ for the same function X (e.g. Sales) performed for activity A and activity B. | Mandatory |
| RT.06.01.0020 | Licenced activity | Closed set of options | One of the licenced activities referred to in Annex II for the different type of financial entities. In case the function is not linked to a registered or licenced activity, ‘support functions’ shall be reported. | Mandatory |
| RT.06.01.0030 | Function name | Alphanumerical | Function name according to the financial entity’s internal organisation. | Mandatory |
| Column Code | Column Name | Type | Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.06.01.0040 | LEI of the financial entity | Alphanumerical | As reported in RT.04.01.0020 Identify the financial entity using the LEI, 20-character, alpha-numeric code based on the ISO 17442 standard | Mandatory |
| RT.06.01.0060 | Criticality or importance assessment | Closed set of options | Use this column to indicate whether the function is critical or important according to the financial entity’s assessment. One of the options in the following closed list shall be used: 1. Yes 2. No 3. Assessment not performed | Mandatory |
| RT.06.01.0070 | Reasons for criticality or importance | Alphanumerical | Brief explanation on the reasons to classify the function as critical or important (300 characters maximum) | Optional |
| RT.06.01.0080 | Date of the last assessment of criticality or importance | Date | Identify the ISO 8601 (yyyy–mm–dd) code of the date of the last assessment of criticality or importance in case the function is supported by ICT services provided by ICT third-party service providers. In case the function’s assessment of criticality or importance is not performed, it shall be filled in with ‘9999-12-31’ | Mandatory |
| RT.06.01.0090 | Recovery time objective of the function | Natural number | In number of hours. If the recovery time objective is less than 1 hour, ‘1’ shall be reported. In case the recovery time objective of the function is not defined ‘0’ shall be reported. | Mandatory |
| RT.06.01.0100 | Recovery point objective of the function | Natural number | In number of hours. If the recovery point objective is less than 1 hour, ‘1’ shall be reported. In case the recovery time objective of the function is not defined ‘0’ shall be reported. | Mandatory |
| RT.06.01.0110 | Impact of discontinuing the function | Closed set of options | Use this column to indicate the impact of discontinuing the function according to the financial entity’s assessment. One of the options in the following closed list shall be used | Mandatory |
| 1. Low or Medium 2. High 3. Assessment not performed |
14. Instructions to complete template RT.07.01 — Assessment of the ICT services
When supporting a critical or important function or material part thereof, this template aims at further assessing the ICT services provided by ICT third-party service providers, including the first extra-group subcontractor in the ICT service supply chain when the prior ICT third-party service providers are intra-group, to the financial entity.
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| RT.07.01.0010 | Contractual arrangement reference number | Alphanumerical | As reported in RT.02.01.0010 | Mandatory |
| RT.07.01.0020 | Identification code of the ICT third-party service provider | Alphanumerical | As reported in RT.05.01.0010 | Mandatory |
| RT.07.01.0030 | Type of code to identify the ICT third-party service provider | Pattern | As reported in RT.05.01.0020 | Mandatory |
| RT.07.01.0040 | Type of ICT services | Closed set of options | One of the types of ICT services referred to in Annex III | Mandatory |
| RT.07.01.0050 | Substitutability of the ICT third-party service provider | Closed set of options | Use this column to provide the results of the financial entity’s assessment in relation to the degree of substitutability of the ICT third-party service provider to perform the specific ICT services supporting a critical or important function. One of the options in the following closed list shall be used: 1. Not substitutable 2. Highly complex substitutability | Mandatory |
| 3. Medium complexity in terms of substitutability 4. Easily substitutable | ||||
| RT.07.01.0060 | Reason if the ICT third-party service provider is considered not substitutable or difficult to be substitutable | Closed set of options | One of the options in the following closed list shall be used: 1. The lack of real alternatives, even partial, due to the limited number of ICT third-party service providers active on a specific market, or the market share of the relevant ICT third-party service provider, or the technical complexity or sophistication involved, including in relation to any proprietary technology, or the specific features of the ICT third-party service provider’s organisation or activity. 2. Difficulties in relation to partially or fully migrating the relevant data and workloads from the relevant ICT third- party service provider to another ICT third-party service provider or to reintegrate them in the financial entity’s operations, due either to significant financial costs, time or other resources that the migration process may entail, or to increased ICT risk or other operational risks to which the financial entity. 3. Both abovementioned reasons | Mandatory in case “not substitutable” or “highly complex substitutability” is selected in RT.07.01.0050 |
| RT.07.01.0070 | Date of the last audit on the ICT third-party service provider | Date | Use this column to provide the date of the last audit on the specific ICT services provided by the ICT third-party service provider. This column relates to audits conducted by: (i) the internal audit department or any other additional qualified personnel of the financial entity, (ii) a joint team together with other clients of the same ICT third-party service provider (“pooled audit”) or (iii) a third party appointed by the supervised entity to audit the service provider. | Mandatory |
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| This column does not relate to the reception or reference date of third-party certifications or internal audit reports of the ICT third-party service provider, the annual monitoring date of the arrangement by the financial entity or the date of review of the risk assessment by the financial entity. This column shall be used to report all types of audits performed by any of the subjects listed above concerning fully or partially the ICT services provided by the ICT third-party service provider. To report the date, the ISO 8601 (yyyy–mm–dd) code shall be used. If no audit has been performed, it shall be filled in with ‘9999-12-31’. | ||||
| RT.07.01.0080 | Existence of an exit plan | [Yes/No] | Use this column to report the existence of an exit plan from the ICT third-party service provider in relation to the specific ICT service provided. One of the options in the following closed list shall be used: 1. Yes 2. No | Mandatory |
| RT.07.01.0090 | Possibility of reintegration of the contracted ICT service | Closed set of options | One of the options in the following closed list shall be used: 1. Easy 2. Difficult 3. Highly complex | Mandatory |
| Column Code | Column Name | Type | Fill-in Instruction | Fill-in Option |
|---|---|---|---|---|
| In case the ICT service is provided by an ICT third-party service provider that is not an ICT intra-group service provider | ||||
| RT.07.01.0100 | Impact of discontinuing the ICT services | Closed set of options | Use this column to provide the impact for the financial entity of discontinuing the ICT services provided by the ICT third-party service provider according to the financial entity’s assessment. One of the options in the following closed list shall be used: 1. Low or medium 2. High 3.Assessment not performed | Mandatory |
| RT.07.01.0110 | Are there alternative ICT third-party service providers identified? | Closed set of options | One of the options in the following closed list shall be used: 1. Yes 2. No 3. Assessment not performed In principle, for each ICT third-party service provider supporting a critical or important function, the assessment to identify an alternative service provider shall be performed. | Mandatory |
| RT.07.01.0120 | Identification of alternative ICT TPP | Alphanumerical | If ‘Yes’ is reported in RT.07.01.0110, additional information could be provided in this column | Optional |
15. Instructions to complete template RT.99.01 — Definitions from Entities making use of the ICT Services
RT.99.01.C0010 RT.99.01.C0020 RT.99.01.C0030 RT.99.01.C0040 Column Code Column Name Option Description/Internal definition of the option RT.99.01.R0010 RT.02.01.0020 Type of contractual arrangement
1. Standalone arrangement
RT.99.01.R0020 2. Overarching arrangement
RT.99.01.R0030 3. Subsequent or associated arrangement RT.99.01.R0040 RT.02.02.0170 Sensitiveness of the data stored by the ICT third-party service provider
1. Low
RT.99.01.R0050 2. Medium
RT.99.01.R0060 3. High
RT.99.01.R0070
RT.06.01.0110
Impact of discontinuing the function
1. Low
RT.99.01.R0080 2. Medium
RT.99.01.R0090 3. High
RT.99.01.R0100
RT.07.01.0050
Substitutability of the ICT third-party service provider
1. Not substitutable
RT.99.01.R0110 2. Highly complex substitutability RT.99.01.R0120 3. Medium complexity in terms of substitutability RT.99.01.R0130 4. Easily substitutable RT.99.01.R0140 RT.07.01.0090 Possibility of reintegration of the contracted ICT service
1. Easy
RT.99.01.R0150 2. Difficult
RT.99.01.R0160 3. Highly complex
RT.99.01.R0170
RT.07.01.0100
Impact of discontinuing the
ICT services
1. Low
RT.99.01.R0180 2. Medium
RT.99.01.R0190 3. High
Annex II List of activities by type of entity
| Type of entity | List of activities and services |
|---|---|
| (a) credit institutions | Activities listed in Annex I of Directive 2013/36/EU and activities listed in Section A and B of Annex I of Directive 2014/65/EU |
| (b) payment institutions, including exempted payment institutions pursuant to Directive (EU) 2015/2366 | Activities listed in Annex I of Directive (EU) 2015/2366 of PSD2 |
| (c) account information service providers | Account information services as referred to in point (8) of Annex I of PSD2 |
| (d) electronic money institutions, including exempted electronic money institutions pursuant to Directive 2009/110/EC | Issuing electronic money in accordance with 2009/110/EC (EMD) and the activities listed in Annex I of PSD2 |
| (e) investment firms | Investment services and activities listed in Section A and B of Annex I of Directive 2014/65/EU |
| (f)* crypto-asset service providers pursuant to Regulation (EU) 2023/1114 | Services and activities listed in Article 3(16) of Regulation (EU) 2023/1114 (MiCAR) |
| (f)** issuers of asset-referenced tokens pursuant to Regulation (EU) 2023/1114 | Activities mentioned in Article 16(1) of Regulation (EU) 2023/1114 (MiCAR) |
| (g) central securities depositories | Activities listed in Annex of Regulation (EU) No 909/2014 (CSDR) |
| (h) central counterparties | Activity of CCPs as described in Article 2(1) of Regulation (EU) No 648/2012 (EMIR) |
| (i) trading venues | Activity of trading venues as described in Article 2(4) of Regulation (EU) No 648/2012 (EMIR) |
| (j) trade repositories | Activities of trade repositories a described in Article 2(2) of Regulation EU No 648/2012 and in Article 3(1) of Regulation EU No 2015/2365 |
| (k) managers of alternative investment funds | Activities listed in Article 6(4) + Annex I of Directive 2011/61/EU (AIFMD) |
| Type of entity | List of activities and services |
|---|---|
| (l) management companies | Activities listed in Article 6(3) + Annex II of Directive 2009/65/EC (UCITD) |
| (m) data reporting service providers | Services referred to in Article 3(1)(34), (35) and (36) of Regulation (EU) 600/2014 |
| (n) insurance and reinsurance undertakings | Activities authorised for the classes of non-life insurance as described in Annex I Section B of Directive 2009/138/EC and classes of life insurance as described in Annex II of Directive 2009/138/EC (Solvency II) |
| (o) insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries | Activities of insurance and reinsurance distribution as described in Articles 2(1)(1) and 2(1)(2) of Directive (EU) 2016/97 (IDD) |
| (p) institutions for occupational retirement provision | Activities of IORPs as described in Article 7 of Directive (EU) 2016/2341 (IORP II) |
| (q) credit rating agencies | Activities of CRAs as described in Articles 2(1) and 3.1(a) and (b) of Regulation (EC) No 1060/2009 |
| (r) administrators of critical benchmarks | Activity of administrators of benchmarks as defined in Article 3(1), (5) and (6) of Regulation (EU) 2016/1011, referred to the benchmarks defined in Article 3(1)(25) of the same Regulation |
| (s) crowdfunding service providers | Provision of crowdfunding services in accordance with Article 3 of Regulation (EU) 2020/1503 |
| (t) securitisation repositories | Activity of SRs as described in Article 2(23) of Regulation (EU) 2017/2402 |
| Non-financial entity: ICT intra-group service provider | Not applicable |
| Non-financial entity: Other intra-group entity | Not applicable |
| Non-financial entity: ICT third-party service provider | Not applicable |
Annex III Type of ICT services
When referring to a type of ICT services in the templates of the register of information, only the identifier (from S01 to S19) of the relevant type of ICT services shall be reported.
| Identifier | Type of ICT services | Description |
|---|---|---|
| S01 | 1. ICT project management | Provision of services related to Project Management Officer (PMO). |
| S02 | 2. ICT Development | Provision of services related to: business analysis, software design and development, testing. |
| S03 | 3. ICT help desk and first level support | Provision of services related to: helpdesk support and first level support on ICT incident |
| S04 | 4. ICT security management services | Provision of services related to: ICT security (protection, detection, response and recovering), including security incident handling and forensics. |
| S05 | 5. Provision of data | Subscription to the services of data providers. (digital data service) |
| S06 | 6. Data analysis | Provision of services related to the support for data analysis. (digital data service) |
| S07 | 7. ICT, facilities and hosting services (excluding Cloud services) | Provision of ICT infrastructure, facilities and hosting services. This includes the provision of utilities (energy, heat management…), telecom access and physical security. (excluding Cloud services) |
| S08 | 8. Computation | Provision of digital processing capabilities (including data computation). This excludes the computation services performed in the context of a cloud environment. |
| S09 | 9. Non-Cloud Data storage | Provision of data storage platform (excluding Cloud services). |
| S10 | 10. Telecom carrier | Operations for telecommunication systems and flow management. Traditional analogue telephone services are explicitly excluded as per Article 3(21) of Regulation (EU) 2022/2554 |
| S11 | 11. Network infrastructure | Provision of network infrastructure |
| S12 | 12. Hardware and physical devices | Provision of workstations, phones, servers, data storage devices, appliances, etc. in a form of a service |
| S13 | 13. Software licencing (excluding SaaS) | Provision of software run on premises. |
| S14 | 14. ICT operation management (including maintenance) | Provision of services related to: infrastructure (systems and hardware except network) configuration, maintenance, installing, capacity management, business continuity management, etc. Including Managed Service Providers (MSP) |
| S15 | 15. ICT Consulting | Provision of intellectual / ICT expertise services. |
| S16 | 16. ICT Risk management | Verification of compliance with ICT risk management requirements in accordance with Article 6(10) of Regulation (EU) 2022/2554 |
| S17 | 17. Cloud services: IaaS | Infrastructure-as-a-Service |
| S18 | 18. Cloud services: PaaS | Platform-as-a-Service |
| S19 | 19. Cloud services: SaaS | Software-as-a-Service |
Annex IV
Instruction to report the “total value of assets”
Value of total assets
| Type of entity | Instruction to report value of total assets in column RT.01.02.0110 |
|---|---|
| (a) credit institutions | Information as specified in Annex X, Template C40.00 Row 0410, Column 0010 of Commission Implementing Regulation (EU) 2021/451 |
| (b) payment institutions, including payment institutions exempted pursuant to Directive (EU) 2015/2366 | Value of the total assets in the statutory accounts |
| (c) account information service providers | Value of the total assets in the statutory accounts |
| (d) electronic money institutions, including electronic money institutions exempted pursuant to Directive 2009/110/EC | Value of the total assets in the statutory accounts |
Type of entity Instruction to report value of total assets in column RT.01.02.0110 (e) investment firms Information as specified in Annex I, template Z01.00, column 0090 of Commission Implementing Regulation (EU) 2018/1624 (f) crypto-asset service providers as authorised under a Regulation of the European Parliament and of the Council on markets in crypto-assets, and amending Regulations (EU) No 1093/2010 and (EU) No 1095/2010 and Directives 2013/36/EU and (EU) 2019/1937 (‘the Regulation on markets in crypto-assets’) and issuers of asset- referenced tokens Value of the total assets in the statutory accounts (g) central securities depositories Value of the total assets in the audited financial statements reported to CAs pursuant to article 41(a) Regulation (EU) 2017/392 (h) central counterparties Information as reported in "Public quantitative disclosure standards for central counterparties" of BIS/IOSCO9 , field 15.2 (i) trading venues Value of the total assets in the statutory accounts (j) trade repositories Value of the total assets in the statutory accounts (k) managers of alternative investment funds Value of the total assets in the statutory accounts (l) management companies Value of the total assets in the statutory accounts (m) data reporting service providers Value of the total assets in the statutory accounts (n) insurance and reinsurance undertakings Information as specified in Annex II and
Annex III, Template S02.01 Row 0500,
Column 0010 of Commission Implementing
Regulation (EU) 2015/2450
[9] https://www.bis.org/cpmi/publ/d125.pdf
| Type of entity | Instruction to report value of total assets in column RT.01.02.0110 |
|---|---|
| (o) insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries | Value of the total assets in the statutory accounts |
| (p) institutions for occupational retirement provision | Information as specified in ECB guideline 2021/831 Annex 1 Part 4 Section 2 |
| (q) credit rating agencies | Value of the total assets in the statutory accounts |
| (r) administrators of critical benchmarks | Value of the total assets in the statutory accounts |
| (s) crowdfunding service providers | Value of the total assets in the statutory accounts |
| (t) securitisation repositories | Value of the total assets in the statutory accounts |
| Non-financial entity: ICT intra-group service provider | Not applicable |
| Non-financial entity: Other intra-group entity | Not applicable |
| Non-financial entity: ICT third-party service provider | Not applicable |
- Draft cost-benefit analysis / impact
assessment
1. As per Article 15(1) of Regulation (EU) No 1093/2010 (EBA Regulation), of Regulation (EU) No 1094/2010 (EIOPA Regulation) and Regulation (EU) No 1095/2010 (ESMA Regulation), any draft implementing technical standards developed by the ESAs shall be accompanied by an Impact Assessment (IA) which analysis ‘the potential related costs and benefits’.
2. The next paragraphs present the IA of the main policy options included in this draft final report on implementing technical standards (ITS) to establish the standard templates for the purposes of the register of information as mandated by Regulation (EU) 2022/2554.
A. Problem identification
3. According to Article 28(3) of the Regulation 2022/2554 (DORA), financial entities (FEs) shall maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers. Those contractual arrangements shall be appropriately documented, distinguishing between those that cover ICT services supporting critical or important functions and those that do not. Article 28(9) of Regulation (EU) 2022/2554 mandates the ESAs to develop draft implementing technical standards to establish the standard templates for the purposes of the register of information.
B. Policy objectives
4. The register of information (i) will be used by FEs as part of their ICT and third-party risk management framework, (ii) will enable the effective supervision of the financial entities’ ICT and third-party risk management framework by competent authorities (CAs), and (iii) will support, as key source of information, the designation process of critical third-party providers subject to the DORA oversight framework.
5. The templates of the register of information included in the draft ITS should be designed to enable the fulfilment of the three objectives of the register of information itself as described in paragraph 4 above. In relation to the first objective of the register of information (i.e. FE internal management of ICT and third-party risk), the templates should be designed ensuring a minimum level of content harmonisation, giving however the possibility to FEs to tailor them to their internal and individual risk management purposes. Finally, the templates and the requirements of their data points should be designed considering a data management and reporting perspective to ensure consistency and harmonisation by design and avoid burdensome reprocessing of data for reporting purposes.
C. Baseline scenario
6. The baseline scenario differs from the different type of FEs in scope of DORA as certain FEs are subject already to outsourcing requirements stemming from their respective financial regulations (e.g. credit institutions or insurance and reinsurance undertakings), while others (e.g. insurance and reinsurance intermediaries) do not have specific outsourcing requirements in their financial regulations. Moreover, in relation to these requirements, it is important to highlight the different level of granularity and implementation by the different CAs in their supervisory practices.
7. For some of the FEs subject to outsourcing requirements, guidelines at national and European level (e.g. EBA guidelines on outsourcing10, EIOPA11 and ESMA12 guidelines on outsourcing to cloud service providers) contain the requirements for financial entities to maintain and update the structured recording of certain information, also in the form of a register, in relation to their outsourcing arrangements, including but not limited to those relating to ICT outsourcing. In the past years, national and European CAs have carried out data collection for supervisory purposes of these registers. It is however to be noted that the perimeter of ICT outsourcing and DORA ICT services does not match completely, with the latter (DORA perimeter) encompassing the first but extending also to services typically not included in the perimeter of ICT outsourcing (e.g. the purchase of licences for software)
8. Furthermore, as part of the preparatory activities for DORA, in July 2022 the ESAs have performed a first data collection exercise of the ICT landscape of a subset of financial entities in scope of DORA considering the definitions included in the Commission proposal of DORA regulation.
D. Options considered
In the process of developing the ITS a holistic approach was necessary to develop the templates of the register of information. The key drivers taken into account while evaluating the options outlined below are listed below:
[11] https://www.eiopa.europa.eu/publications/guidelines-outsourcing-cloud-service-providers_en
[12] https://www.esma.europa.eu/document/guidelines-outsourcing-cloud-service-providers
(i) the requirements of DORA, particularly the one requiring financial entities to include in the register of information all contractual arrangements concerning ICT services; (ii) the principle of proportionality, (iii) the need to define templates valid both at entity and sub-consolidated and consolidated level, considering the broad population of financial entities in scope of DORA, the requirements of the accounting directive and of the prudential regulations, where applicable; (iv) the need to be able to aggregate information contained in the register of information at group, national (by the CAs) and European (by the ESAs) level.
POLICY ISSUE 1: SCOPE IN TERMS OF CONTRACTS OF THE REGISTER OF INFORMATION
Options considered
Option A: include all contractual arrangements concerning all ICT services provided to FEs by ICT third-party service providers
Option B: include contractual arrangements concerning only ICT services provided to FEs by ICT third-party service providers supporting critical or important functions.
Cost-benefit analysis
Article 28(3) of Regulation (EU) 2022/2554 specifies that the scope of the register of information shall cover all contractual arrangements on the use of ICT services provided by ICT third-party service provider. Therefore, the option of considering as part of the scope only ICT third-party service providers providing ICT services supporting critical or important functions would not comply with the level 1 text.
Preferred option
Option A has been retained.
POLICY ISSUE 2: STRUCTURE OF THE REGISTER OF INFORMATION
Options considered
Option A: develop a set of minimum level of harmonised templates to cover the three purposes of the register of information as described in paragraph 4 of the policy objectives, encouraging financial entities to complement the register of information for ICT risk management purpose.
Option B: develop a set of prescriptive detailed templates to cover the three purposes of the register of information as described in paragraph 4 of the policy objectives.
Cost-benefit analysis
The register of information shall serve three different purposes, as described in paragraph 4 of the policy objectives, for a large number of FEs and CAs. In assessing the viability of this option, the ESAs have considered: (i) the different maturity of FEs in relation to their internal third-party risk management, (ii) the different business models and risk profile of the FEs in scope of DORA; and (iii) the principle of proportionality. Furthermore, in assessing this policy option the ESAs have considered that (i) the scope of the register of information (i.e. the contractual arrangements concerning ICT services) covers a high number of elements evolving over time and (ii) the FEs retain the ultimate responsibility in relation to the compliance with their obligations set out in DORA and other relevant applicable financial regulations. Finally, the ESAs have considered the need to define a harmonised set of templates to foster effective supervisory convergence in the area of third-party risk management supervision and to enable a structured shared of information for DORA oversight purposes.
Preferred option
Option A has been retained.
POLICY ISSUE 3: CONTRACTUAL STRUCTURE AND DOCUMENTATION
Options considered
Option A: Prescribe fields covering information on the contractual structure (documentation management)
Option B: Not including information on the contractual structure (documentation management)
Cost-benefit analysis
The objective of the register of information is to capture functions from the FEs and establish a link between those functions and the ICT TPPs, among other objectives. This can be achieved without imposing specific requirements for FEs to report the structure of the documents composing the different types of contractual arrangements and the relationships between them. Furthermore, it appears that option A would create a burdensome requirement with limited benefits concerning the three main purposes of the register of information.
Preferred option
Option B has been retained.
POLICY ISSUE 4: DEVELOP THE TEMPLATES AS FLAT TABLE OR USING A RELATIONAL STRUCTURE
Options considered
Option A: establishing the register of information templates as a unique flat table
Option B: establishing the register of information templates as a relational structure
Cost-benefit analysis
Leveraging on the lessons learned from the different exercise of data collection of outsourcing registers, the templates established are designed in a technology-neutral manner building up on open flat tables. Linking the templates to one another by using different specific keys to form a relational structure between them appears appropriate to avoid having multivalue datapoints, inconsistencies or excessively voluminous repetitions of rows in term of data management perspective.
Preferred option
Option B has been retained.
POLICY ISSUE 5: USE OF THE LEI TO IDENTIFY FINANCIAL ENTITIES AND ENTITIES PART OF GROUPS
Options considered
Option A: consider the LEI as a unique identifier for all financial entities and entities part of groups
Option B: consider other type of identifier for those entities
Cost-benefit analysis
In order to enable the CAs, the OF, and the ESAs to fulfill their duties under DORA, it is necessary to consistently and unambiguously identify financial entities and ICT third-party providers both at the national and international levels. Unlike national codes or company names, the legal entity identifier (LEI) provides a means for such unambiguous identification. The use of LEIs enhances the quality and timeliness of aggregated data and aims to reduce the reporting burden for entities that must report. Additionally, it is noted that a significant part of the FEs in scope of DORA are currently using an LEI for various purposes including for prudential supervisory reporting where applicable. For the FEs which have still not procure for themselves a valid LEI, the option A seems to be proportionate given the limited annual cost for procuring a valid LEI. Therefore, it seems appropriate to require all the financial entities to procure and maintain a valid LEI for themselves.
Preferred option
Option A has been retained.
POLICY ISSUE 6: USE OF THE LEI TO IDENTIFY ICT THIRD-PARTY SERVICE PROVIDERS
Options considered
Option A: consider the LEI as a unique identifier for all ICT third-party providers
Option B: consider the LEI as a unique identifier for all ICT third-party providers that are legal person except individuals acting in a business capacity.
Option C: not consider the LEI as a unique identifier for all ICT third-party providers
Cost-benefit analysis
To enable the Competent Authorities, the Oversight Forum and the ESAs to carry out their duties as stemming from DORA, it is necessary to unambiguously and consistently identify financial entities and ICT third-party providers both at national and international level. In contrast to national codes or company names, the concept of the legal entity identifier (LEI) allows for such unambiguous identification. The use of LEIs improves the quality and timeliness of aggregated data and is aimed at reducing the reporting burden for reporting entities. Given the objectives as outlined above and considering the limited annual cost for procuring a valid LEI, it seems appropriate to the ICT third-party service providers that are legal persons to procure for themselves a valid LEI. However, considering both the principle of proportionality and that individuals acting in a business capacity are unlikely to be designated as CTPPs, there is no need for them to procure for themselves an LEI.
Preferred option
Option B has been retained.
POLICY ISSUE 7: DETAIL OF INFORMATION REQUIRED IN THE REGISTER OF INFORMATION
Options considered
Option A: request FEs to include in the register of information the results of their risk assessment and due diligence for all ICT third-party services providers regardless if the ICT service supports a critical or important function or not.
Option B: request FEs to include in the register of information the results of their risk assessment and due diligence for all ICT third-party services providers regardless only if the ICT service supports a critical or important function.
Cost-benefit analysis
Regulation (EU) 2022/2554 requires FEs to include information on all ICT services provided by third-party service providers in the register of information. The register of information is designed to serve three different policy objectives, as described in paragraph 4. For a large number of FEs and CAs, Option B reduces the effort required to include information on risk assessments for third-party providers supporting critical or important functions, while still maintaining a risk-based approach regarding ICT third-party risks. This option is proportionate as it considers the varying levels of dependency FEs have on ICT third-party service providers. FEs that depend on a significant number of ICT third-party service providers have more information to report in the register of information than FEs depending on a small number of ICT third-party service providers. Requiring FEs to include information on all ICT services provided by third-party service providers, regardless of whether they support critical or important functions, would not be proportionate and could be burdensome for FEs. Option B strikes a balance between both aspects, making it the most appropriate choice.
Preferred option
Option B has been retained.
POLICY ISSUE 8: ICT SERVICE SUPPLY CHAIN
Options considered
Option A: include all subcontractors in ICT service supply chains
Option B: include subcontractors that effectively provide ICT services supporting critical or important functions
Cost-benefit analysis
Article 30(2)(a) of Regulation (EU) 2022/2554 requires that the contractual arrangements on the use of ICT services includes a clear and complete description of all functions and ICT services to be provided by the ICT third-party service provider, indicating whether subcontracting of an ICT service supporting a critical or important function, or material parts thereof, is permitted and, when that is the case, the conditions applying to such subcontracting. In addition to be in line with the article above-mentioned, option B follows a risk-based approach and appears proportionate regarding the level of dependency of the critical or important functions to ICT TPPs. Therefore, option B seems the most appropriate option.
Preferred option
Option B has been retained.
POLICY ISSUE 9: TAXONOMY FOR FUNCTIONS
Options considered
Option A: define a taxonomy for each type of financial entity as defined in article 2 of Regulation (EU) 2022/2554
Option B: do not defined a taxonomy for each type of financial entity as defined in article 2 of Regulation (EU) 2022/2554 and let FEs to use their internal breakdown for functions
Cost-benefit analysis
Defining a taxonomy for functions at EU level would support Supervisory convergence, clarity and harmonisation. However, given the constraints of the scope of the register of information and considering certain regulations such as CRR, some FEs are already required to define their internal taxonomy for functions (for operational risk management purpose in the case of CRR). Considering this the ESAs decided to adopt option B. This decision might be reviewed following the first years of implementation of the register of information given the importance of harmonisation and convergence in this area.
Preferred option
Option B has been retained.
POLICY ISSUE 10: DATE OF APPLICATION
Options considered
Option A: Align with the date of application of Regulation EU 2022/2554 (DORA)
Option B: Taking into account the effort from the FEs to implement the register of information especially regarding the inclusion of all the existing contractual arrangements at the date of entrance into application
Cost-benefit analysis
Option B would avoid defining a specific timeline (i.e. presumption that the register of information is in place as of 17 Jaunary 2025 for all existing and new arrangements in place at that date).
FEs will need to implement the future requirements of the ITS both to new and pre-existing contractual arrangements. The ITS will need necessarily to clarify the timeline of this implementation for the FEs considering on:
-
the complexity for the FEs to populate the register (particularly with reference to the pre-existing arrangements) as the level of granularity and complexity of each contractual arrangement considering the type and number of ICT services provided, functions supported, stakeholders involved, etc. differs one from each other.
-
the implication that a delayed timeline will have on the effective entry into force of the DORA Oversight Framework (being the register of information the key data source for designation).
It appears proportionate to provide some room for manoeuvre for the FEs to include pre-existing contractual arrangements in the register of information.
While it is essential to weigh these factors, the ITS shall legally comply with the date of application of the level 1 text such as aligning with the date of application of Regulation EU 2022/2554 (DORA) – Option A.
Preferred option
Option A has been retained (legal compliance).
POLICY ISSUE 11: RECORDING OF TERMINATED CONTRACTUAL ARRANGEMENTS
Options considered
Option A: require financial entities to only keep information in relation to ongoing contractual arrangements on services that are actively provided at reporting time
Option B: require financial entities to keep information in relation to contractual arrangements that have been terminated since the last submission of the register of information
Option C: require financial entities to keep information in relation to contractual arrangements that have been terminated for 3 years
Option D: require financial entities to keep information in relation to contractual arrangements that have been terminated for 5 years
Cost-benefit analysis
As key part of their internal audit trail, financial entities should keep track of the terminated contractual arrangements. This information on the past contracts would also enable the CAs to monitor financial entities’ contractual policy with third-party, management of third-party risks over time and outsourcing strategy.
Preferred option
Option D has been retained.
OVERALL COST-BENEFIT ANALYSIS
Overall, the ITS on the register of information will bring the financial entities, CAs and ESAs/OF both costs in terms of implementation and benefits in terms of better awareness and understanding of ICT third-party dependencies of financial entities and ICT third-party risks, and ultimately ensuring financial stability of the system.
The costs and benefits are listed in Table 3 below
Table 3: Cost and benefits of the ITS on register of information
| Stakeholder groups affected | Costs | Benefits |
|---|---|---|
| Financial entities | Costs related to the changes in processes and infrastructure to implement, maintain and update the register of information. In relation to the first implementation, it is noted that certain type of financial entities may experience costs to populate the register with information on existing contractual arrangements at the date of entrance into application. | Awareness and monitoring of risks stemming from ICT third-party arrangements including those relating to ICT service supply chains. Benefitting from harmonised templates at EU level, which aims at simplifying the supervisory dialogue cross-border and cross-sector. |
| Competent authorities | Costs related to the processing of additional flow of information related to the register of information. Review of the supervisory processes on outsourcing to include the specifications relating to DORA. | Harmonised information across MSs and across sectors, that will facilitate the analysis and discussions of the relevant risks (including concentration risks). Enhanced supervisory awareness of ICT third-party dependencies. |
| European Supervisory Authorities Oversight Forum | Costs related to the processing of additional flow of information related to the register of information. | Improved EU-wide awareness and management of ICT third-party risk management risks. Access to a harmonised dataset of information to enable analysis at EU level including relating to the designation of the CTPPs in scope of DORA oversight. |
Overall, benefits of the ITS are assessed as being significantly higher and relevant for all the stakeholders involved, compared to the costs.
6. Feedback on the public consultation
6.1 INTRODUCTION
According to Article 28(9) Regulation 2022/2554, the ESAs are mandated, through the Joint Committee, to develop draft implementing technical standards to establish the standard templates for the purposes of the register of information referred to in paragraph 3, including information that is common to all contractual arrangements on the use of ICT services. The ESAs shall submit those draft implementing technical standards to the Commission by 17 January 2024.
The ESAs carried out a public consultation on the draft Implementing Technical Standards (ITS) on the register of information from 19th June to 11th September 2023. This feedback statement sets out a high-level summary of the consultation comments received from 94 respondents. The full list of all the non-confidential comments can be found on the ESAs’ websites.
In the light of the comments received, the ESAs agreed with some of the proposals and their underlying arguments and have introduced changes to the final draft ITS. These challenges are mentioned throughout the ESA’s assessment of feedback received.
As part of the consultation the ESAs held a public hearing on 13th July 2023 with stakeholders to discuss the draft five policy products consulted.
6.2 SUMMARY OF RESPONSES
Below is a summary of the feedback received during the public consultation and the ESAs’ analysis per topic.
| Topic | Summary of the comments received | ESAs’ analysis |
|---|---|---|
| LEI for ICT service providers | Many respondents considered the use of the LEI should be optional since ICT service providers, especially non-EU ICT TPP, may not have an LEI. Some short-term alternative proposals | One of the objectives of Regulation (EU) 2022/2554 is to ensure a sound monitoring of ICT third-party risk in the financial sector, including assessment of ICT concentration |
| were made such as the use of corporate registration number, VAT-number or national activity code, alternative data points to identify these entities. Several respondents highlighted this requirement would be burdensome for the industry and ICT service providers, and it goes beyond the current industry requirements. Several respondents noted potential challenges of procuring LEI, particularly across an extensive supply chain. The proposal was to request it only for material subcontractors supporting a critical or important function. Many respondents suggested deleting the requirements of Article 4 (8) “maintaining the LEI updated” and stated it cannot be the responsibility of financial entities to ensure ICT providers and subcontractors to have a valid and an active LEI over time. Few respondents pointed out it may be complicated to identify and provide the LEI for all ICT service providers providing bundled services involving multiple external/internal service providers. | risk at entity level, and in order to enable this, the LEI is a crucial instrument. To ensure a sound monitoring of ICT third-party risk, LEI identifies unambiguously and consistently the ICT third-party service providers. LEI is used worldwide to help identifying all legal entities on a globally accessible database. There are several LEI issuers around the world that issue and maintain the identifiers and act as primary interfaces to the global directory. Therefore, the non-EU ICT TPP can also obtain an LEI. Taking a risk-based and proportionate approach, FEs are requested to ensure that all their direct ICT third-party service providers and all the subcontractors that effectively underpinning ICT services supporting critical or important functions that are legal person procure and maintain valid an LEI. This requirement should be explicitly included in all the contractual arrangements for the use of ICT services provided. In case an ICT service is offered by multiple direct ICT third-party service providers through a same contractual arrangement, | |
| all the direct ICT third-party service providers that are legal persons should procure and maintain valid an LEI. In case of the ICT third-party service providers is a joint-venture, the joint venture is required to procure and maintain valid an LEI. | ||
| Obstacles for keeping information on contractual arrangements terminated for five years | Some respondents requested that the contracts terminated before the date of application of DORA should not be considered in the register of information. Other respondents noted a possible overlapping with sector-specific record-keeping requirements (for instance the General Data Protection Regulation (GDPR)). Few respondents requested clarification whether the five-year threshold also applies to expired or cancelled contracts in opposition to terminated contracts. Some respondents highlighted concerns since: | The ESAs considered the feedback received from the respondents on this topic and have amended accordingly the final draft ITS by clarifying in Article 4(5) that this requirement is applicable to those contractual arrangements in force since the date of application of the DORA Regulation (EU) 2022/2554. DORA’s scope is different from GDPR’s one. Therefore, the ESAs disagreed, also considering other sectorial regulations such as MiFiD and EMIR that foresee a 5 years period for keeping record. Therefore, this requirement is also required in other EU regulations. This requirement applies to terminated contractual arrangements for which the ICT service has been effectively provided. If the contract has |
Topic Summary of the comments received
ESAs’ analysis
There is not any justification to require keeping information on contractual arrangements terminated for five years and it does not reduce the ICT risk management.
These requirements request important human and/or technical resources to manage those contracts resulting in an increased of costs.
Others highlighted some difficulties may rise when collecting missing data from their service providers in order to update terminated contracts.
The principle of proportionality is not ensured and should be considered a proportionate and risk-based approach to this reporting requirement and recommend that a one- year period for keeping and reporting information on terminated arrangements is sufficient. Few respondents considered the ITS should stipulate that, until 2030, financial entities should indicate, each year, which contracts are being terminated. By 2030, the register would then been cancelled before its start date, there is no need to consider it. The template RT.02.02 includes a column in relation to the end date of each contractual arrangement and another one including the reason for the termination, therefore, there is no additional burden to report terminated contractual arrangement.
Topic Summary of the comments received
ESAs’ analysis contain a five-year history of terminated contracts, without imposing a disproportionate operational burden on financial entities.
Very few respondents proposed to maintain a dedicated register for terminated contracts in addition to the register requested by the Regulation.
Assignment of responsibilities for maintaining and updating the register of information at sub-consolidated and consolidated level Some respondents suggested changing the term “responsibility” to “accountability”. Some respondents suggested to extend the date of the implementation date given the complexity of the task. Many respondents considered
Article 6. 3 of ITS is unclear for
the following reasons:
It is not clear how the international group structures should fill in the register: whether each subsidiary has to report from entity level; ii. whether subsidiaries outside the EU need to report as a separate entity; iii. whether the holding company and provider of the intragroup services have to report as an The ESAs, considering the need to enable effective supervision of FEs’ ICT third-party, and with a view to further supporting the work in the context of the Oversight Framework established by the DORA, have decided to redraft Article 6 of the draft ITS based on the feedback received from the respondents to the public consultation on this topic. The ESA’s aim is to clarify and avoid unnecessary costs and burdensome reprocessing of data for reporting purposes. To that end, the draft ITS clarifies in recital 3 that “groups may develop a single register of information at entity, sub- consolidated and consolidated levels in relation to all contractual arrangements on the use of ICT services provided
Topic Summary of the comments received
ESAs’ analysis entity and, if so, whether the subsidiaries shall be included or not in the consolidated view (both inside and outside of the EU). A register per entity would multiply the information, create risk of desynchronisation and inconsistencies. It is not clear how fill in the register in the context of an Intra-Group service contracts providing critical or important functions, it should be clarified whether the parent, the subsidiaries and the branches should all fill in the register of information, which would lead to a duplication of effort. Some respondents shared their concerns that:
subsidiaries should not be responsible for the group consolidation unless the parent undertaking or the respective entities designat it in accordance with the sector-specific regulations. Nonetheless, the subsidiaries could assist the parent company to obtain by ICT third -party service providers to all the financial entities, which are part of the group. In such cases, the single register of information should allow each financial entity to fulfil its obligation to maintain and update the register of information at entity and sub- consolidated level, when applicable, including its reporting to its competent authority”. The ESAs have amended the requirement for maintaining and updating the register of information when FEs belong to a group. When it comes to groups, Article 3 of DORA refers to the Accounting Directive (Directive 2013/34/EU) to define the meaning of a ‘group’, a ‘parent undertaking’ and a ‘subsidiary’. The ESAs acknowledge that further clarity is needed to define the perimeter of consolidation. For that, article 6(1) of the draft ITS has been redrafted to define the scope of consolidation as follows: “ In the case of groups, the parent undertakings shall take into account the relevant financial services regulations when identifying the scope of entities
Topic Summary of the comments received
ESAs’ analysis the information on a consolidated basis.
the term “entities” and
“ultimate parent entity” should be clearly defined in DORA Regulation: whether it is all the entities located in the EU, or whether it is all the entities of the Group, regardless the geographical location. FEs are responsible for the accuracy of the register but relies on the information provided by ICT TPPs. there is an issue about the applicability of the ITS when the parent entity is not within the scope DORA. few respondents suggested FEs could contractually delegate the responsibility direct ICT TPPs. to be included in the register of information”. Though the title of Article 6 has been changed and the term of responsibility is not included in the final report, the issue is no longer valid. However, the term responsibility is in line with the text of DORA Regulation (e.g.,
Article 5, Article 6 and Article
26).
The extension of the timeline for the implementation goes beyond the ESAs’ mandate set out in Article 28(9) that reads “to develop draft implementing technical standards to establish the standard templates for the purposes of the register of information, including information that is common to all contractual arrangements on the use of ICT services”. The responsibility for maintaining information on ICT service supply chains remains to the FEs. Therefore, FEs should take the necessary measures through their policy on the use of ICT services and the contractual arrangement clauses with their ICT third-party service providers to enable the collection of the necessary information to report in the
Topic Summary of the comments received
ESAs’ analysis
| Topic | Summary of the comments received | ESAs’ analysis |
|---|---|---|
| register of information in order to comply with this ITS. With regard to some of the specific remarks made by the respondents, the ESAs considered that FEs cannot outsource contractually the responsibility for maintaining and updating the register of information to a third-party as it goes against the DORA Regulation that sets out in Recital 21 “those financial entities outsourcing a significant part of their core business to service provider are responsible for addressing serious risks associated with the ICT risk management”. Also, recital 45 sets out “The ultimate responsibility of the management body in managing a financial entity’s ICT risk should be an overarching principle of that comprehensive approach, further translated into the continuous engagement of the management body in the control of the monitoring of the ICT risk management”. To foresee the case of outsourcing of any activity or function to a service provider, the ESAS have included in Recital 7in this ITS that sets out “ In case a financial entity outsources a |
Topic Summary of the comments received
ESAs’ analysis function or activity to a service provider, and this service provider makes use of ICT services to support this function or activity, the responsibility for ensuring the operational resilience of that function or activity remains with the financial entity. Therefore, for the purpose of the register of information, the service provider should be treated as a direct ICT third-party service provider”. In case a parent undertaking of a sub-group or group, that include subsidiaries that are FEs, is not within the scope of DORA. This ITS does not apply to this parent undertaking but apply to the FEs of this sub-group or group. Annual expense or estimated cost of the contractual arrangement for the past year and Budget of the contractual arrangement for the upcoming year A minority of respondents agreed with the inclusion of the data fields but suggested including thresholds (e.g., <1million, 1-5million, >5million) in order to dispel any concerns about confidentiality/commercially sensitive data. Some respondents were in moderate disagreement since:
These data are not relevance the context of materiality, From a supervisory and risk management perspective, the annual cost of the contractual arrangements for the past year represents a fundamental source of information to assess and compare the type of outsourced services and their criticality. It allows both FEs and supervisory authorities to reach a deeper understanding of the third-party risk exposures, being therefore a key component for
Topic Summary of the comments received
ESAs’ analysis concentration risk and resilience.
There is a duplication of reporting (e.g., FINREP reporting) It is difficult to estimate RT.02.01.0042 (budget) especially when there is a multiservice agreement that includes provision of IT services. Several respondents suggested different approaches:
Excluding information on intragroup arrangements from the scope.
Using “% of IT budget” as opposed to actual € amount.
Using of range of values as opposed to actual € value.
Allowing FEs more flexibility in relation to the data point.
Half of the respondents had strong disagreement since these fields create additional effort, complexity, and duplication of information. improving the operational resilience of each FE and the system as a whole. From a prudential and risk management point of view, it is important to understand the “size” of the different services provided by each provider in order to evaluate operational and concentration risks. The register is also a supervisory tool and should contain the information required to understand the third-party dependencies and not only the necessary information to identify CTPP. Therefore, the ESAs disagreed with removing it from the template. A new field has been added RT.05.01.0070 Total annual expense or estimated cost of the ICT third-party service provider that is mandatory if the ICT third-party service provider is a direct ICT third-party service provider. The ESAs considering the feedback received have deleted the field Budget of the contractual arrangement for the upcoming year.
Topic Summary of the comments received
ESAs’ analysis
Instructions provided in Annex
V on how to report the total value of assets and the value of other financial indicator for each type of financial entity Half of the respondents replied to this question. Among the responses:
Around one third of the respondents have supported the proposed instructions.
Two third of the respondents raised concerns either because they did not understand why the ESAs propose to include this information in the register that do not have a direct linkage with contractual arrangements, or because CAs already collect such information through existing sectoral regulation for few types of financial entities. Few of them have also highlighted the complexity to fill in the proposed register. Many of them highlighted the complexity when financial entities, and group in particular, have multiple activities.They invited the ESAs to create a more generic definition of financial entities The ESAs have considered the comments provided by respondents and decided to streamline the Annex IV (former
Annex V) by requesting total
value of assets and removing the value of other financial indicators (addressing de facto comments on these alternatives metrics). The ESAs highlight that such information will be used for the CTPPs designation process and the appointment of the Lead Overseer as per article 31(1)(b) of the DORA. Furthermore, the ESAs acknowledge the total value of assets is already available in few existing sectoral reporting However, the information is not directly available to the ESAs for all financial entities subject to DORA. Given that without such data in the register of information, the designation and the appointment processes may be exposed to significant data quality issues, the ESAs are of the view to maintain the requirement to provide the total value of assets. With regard to the comments made by the pension industry, IORPs already have at disposal
Topic Summary of the comments received
ESAs’ analysis providing multiple services to address such situation.
A couple of respondents requested more clarity in some of the value of other financial indicators (e.g. for CRAs or for assets managers).
few respondents explained that the reference to 2021 ECB guideline for the IORPs is not adapted and suggested to use existing statutory balance sheets instead. and report the total value of assets following the ECB guidelines. Therefore, to facilitate the registration of the relevant information, the Annex is referring to the same approach. The total value of asset is an information asked only at entity level. The register of information at sub-consolidated and consolidated level is the “concatenation” of register of information at entity level. The level of granularity of the information is the same. Therefore, there is no need to create a more generic definition of financial entities providing multiple services. Impact assessment Half of the respondents replied to this question. Among the responses provided:
some respondents agreed with the impact assessment and the main conclusions stemming from it and others, though agreed, outlined the challenges to assess the templates without having used them yet. Other respondents consider the volume of information Having assessed the feedback from the public consultation, the ESAs concluded that:
In order to include other costs that could overlooked, the stakeholders should be more precise to detail which one since they do not provide what costs are missed.
The price of getting an LEI is around 40€/year, therefore, it is an affordable to bear this annual cost.
Topic Summary of the comments received
ESAs’ analysis required appears to exceed what is necessary to DORA.
Others asked for additional clarification on the intended usage of the data in each column.
Among the reasons provided for those respondents that disagreed with the impact assessment are the following:
The benefits are lower than the costs and the costs are not sufficiently considered.
The need for proportionality is not sufficiently considered.
The costs incurred by financial entities when requiring all the third-party ICT-service providers and the providers included in the supply chain to obtain an LEI is not sufficiently considered. It is not considered the specific impacts on asset managers and investment firms. The costs derived from the ITS would be lessened by merging register’s templates and submission channels with the ones used in the context of the outsourcing data collection under the 2019 EBA guidelines. ICT third -party service providers that are legal persons should procure for themselves a valid LEI and provide it to FE as part of the contractual arrangement’s information. The impact assessment covers the cost and benefit analysis across sectors and entities, while considering sector specificities. Finally, to ensure proportionality and address the concerns raised by the respondents, the ESAs have embedded proportionality alongside the draft ITS by streamlining the fields required that deemed necessary to enable the effective supervision while alleviating FE’s reporting burdens (e.g. subcontractors that effectively provide ICT services supporting critical or important functions, including all the subcontractors providing ICT services whose disruption would impair the security or the continuity of the service provision)
Topic Summary of the comments received
ESAs’ analysis
The costs of the ITS would be reduced by providing to the financial entities ready-to- use templates and reporting software. The material addressed to the entities should not be limited to reporting instructions. Few respondents indicated that the costs of the ITS would be reduced by preferring option B of Policy Issue 1 (scope of the register), i.e. by limiting the register to those ICT TPP supporting critical or important functions. Very few respondents responded that the definition of critical or important functions would need to be further clarifying before setting conclusions on the impact of the ITS. Proportionality Many respondents highlighted concerns that the maintaining and updating the register of information is burdensome, disproportionate without considering a risk-based approach. Few respondents highlighted the risk of overboarding information in the register of information with highly redundant information that would need to be reported in case of multi- The ESAs took into account the feedback received from the respondents to the public consultation on this topic and also holistically across all different questions from the public consultation and have amended the approach to embed a more proportionate and risk-based approach in the requirements to fill in the register of information templates.
Topic
Summary of the comments received
ESAs’ analysis
service ICT TPPs providing services to multiple FEs within a same group (which could be demultiplied by the number of subcontractors).
Many respondents stressed that getting information on subcontractors with a rank higher than rank 2/3 would be very difficult for the FEs without an extremely high and costly effort and suggest to set a limit in the rank in the ICT service supply chain. Many stakeholders would add further proportionality to the ITS by taking into account an evaluation of the materiality of the ICT service itself. Several respondents suggested to simplify and reduce the scope of the register of information to focus only on critical or important functions. Other respondents suggested the creation of a dedicated register for non-critical ICT services with less information, limited to essential details. A few respondents noted that the draft ITS allows financial entities to complement the information reported in the templates by tailoring them to To ensure proportionality and address the concerns raised by the respondents, the ESAs have embedded proportionality alongside the ITS by streamlining the fields required that deemed necessary to enable the effective supervision without being burdensome. The simplification of the register of information templates includes:
Merging the initial two set of register of information templates into one set; Modification of Article 6 the to allow groups to maintain and update a single Register of Information at the most consolidated level which shall allow a breakdown per each entity and sub-groups, where applicable. Solo entities, however, remain responsible for the data on their level, and competent authorities can require upon request the register of information at the relevant level (entity, sub- consolidated or consolidated) to the relevant FEs under its remit. However, the reporting
Topic Summary of the comments received
ESAs’ analysis their internal risk management purposes. The ITS is however silent on whether additional fields could be added by competent authorities beyond the ultimate harmonized template. In order to avoid significant operational issues in maintaining the register and data consolidation in the case of a Group, the respondents proposed that the ESAs explicitly restrict any additions to the template by competent authorities. A few stakeholders noted that it would be helpful if the ESAs or the NCAs could provide clear guidelines and a first phase support to financial entities to help with the implementation of the Register effectively and efficiently. process is not covered in this ITS. Deletion of the requirement to have an audit trail functionality included in the second part of the former
Article 4 (5).
Change of the requirement to update the register from “ongoing” to a “regular basis” in Article 3 (2): “To this end, financial entities shall review the information contained in register of information on a regular basis” Deletion of templates former templates RT.05.03 to identify alternative ICT TPPs and RT.07.01 on additional type of ICT services Deletion of some columns in most of the templates. The data reporting process is out of scope for this ITS however considering the willingness from ESAs to reduce the reporting burden the structure of the register of information templates has been streamlined from a a data management
Topic
Summary of the comments received
ESAs’ analysis
perspective to facilitate the transmission of the register of information from FEs to CAs avoiding or minimizing the necessity to reprocess the data for reporting purpose Approach on the subcontractors Many respondents indicated that “material subcontractors” is not defined and further guidance is needed to ensure a uniform understanding and application of the term. They suggested the following definition for a material subcontractor: “a subcontractor providing a material part of an ICT service provided by a direct ICT third-party service provider supporting a critical or important function and whose disruption or failure could lead to a material impact to service provision.” Several respondents indicated that FEs will be highly dependent to the direct ICT TPPs to have visibility on the ICT service supply chain and highlighted that ICT TPPs frequently change subcontractors to adapt to evolving services or other commercial considerations. As a result, providing and The ESAs took into account the feedback received from respondents to the public consultation on this topic and have amended the draft ITS as follows:
Aligning with the L1 text instead of using: “material subcontractor”. Therefore, Recital 6 and Article 3 (1)(b) have been redrafted as it follows: “ the register of information includes information on all subcontractors that effectively underpin ICT services supporting critical or important functions or material part thereof ”. The ESAs disagreed with the respondents proposal to set a limit in the rank of the subcontractors in the ICT service supply chain to be reported in the register of information but take into consideration the call for a more proportionate and
| Topic | Summary of the comments received | ESAs’ analysis |
|---|---|---|
| maintaining detailed information on each and every subcontractor across multiple ranks becomes particularly cumbersome, especially when procuring various services from a single vendor. They suggested to put the ICT TPPs under supervision of the LO/ESAs to collect the information on the ICT service supply chain directly from the ICT TPPs to save effort from FEs. Many respondents stressed that the effort from the FEs to provide information on the ICT service supply chain via this template is not proportionate, cumbersome with a questionable benefit. Therefore, many stakeholders suggest to address this point by limiting the rank of subcontractors to be reported. (rank 2 or 3 maximum). Few respondents highlighted that Art 28(9) does not mention subcontractors, and is limited to “all contractual arrangements on the use of ICT services”. A literal interpretation thereof refers to the parties to a contract with the financial entities, and not the subcontractors. | risk-based approach by requiring only the subcontractors providing ICT services whose disruption would impair the security or the continuity of the service provision irrespective of the rank. |
Topic Summary of the comments received
ESAs’ analysis
Implementation of the Register of Information and reporting process Some respondents highlighted the complexity to deal with multiple reporting requirements and suggest to align with existing reporting such as the outsourcing register reporting (EBA, ECB SSM, etc.) to reduce the FEs administrative burden and cost. also other reporting could extract info from the register of info… Many respondents highlighted that financial entities are likely to face an over-proportional burden when implementing the register of information for the first time and that implementing such a register by January 2025 as required is not feasible. They requested that the implementation date should be adjusted or that the ESAs should grant respective grace implementation periods. Some stakeholders recommended setting the deadline for the first submission between 18 to 24 months from the estimated finalization and adoption of the ITS by the European Commission. Another alternative, as proposed by a number of With regard to some of the specific remarks made by the respondents the ESAs discarded them because:
The reporting process and the extension of timeline for implementing the register of information are going beyond the scope of the ITS.
Topic Summary of the comments received
ESAs’ analysis respondents, would be to authorize a phased submission.
Audit trail functionality Some respondents noted that the audit trail functionality implies that a software system needs to be designed, developed and built to accommodate all of the templates and track the requested changes. Cost for this development will be high with little added value in terms of risk management. The ESAs took into account the feedback received from respondents to the public consultation on this topic and have amended the draft ITS by deleting from the former Article 4 (5) the requirement to maintain an audit trail functionality. Taxonomy of ICT services Some respondents raised some points related to the proposed taxonomy of ICT services. In particular:
• There were a number of
responses seeking to reduce and simplify the number of elements included.
• There were several
responses that seek more clarity in the definition of each of the elements included in the taxonomy. The possible overlaps and how to treat, the maintenance aspects and how to use the Service “other” were the most common questions.
• A number of
stakeholders request that the taxonomy should be clarified Following feedback received, the ESAs considered that the proposed taxonomy should be modified to fundamentally provide more clarity, reduce complexity in its use and avoid possible overlaps in the ICT services identified. The current proposal eliminates some elements previously identified and simplifies the taxonomy. The ICT services identified are not mutually exclusive and FEs can include several ICT services in the taxonomy for the cases where the contractual
Topic Summary of the comments received
ESAs’ analysis
and aligned / harmonised with existing standards.
• Some respondents
expressed doubts about the difference between "provision" and “rental".
• Some doubts were
posed on how to use template
RT.07.01, on the number of services that can be included using this template and also if the inclusion of this template will add extra complexity to the taxonomy. Similar concerns were raised regarding the item “other”.
• There were some
comments about the perception that the scope of services is not covered by the definition of ICT services in DORA, or whether it is an expansion of it and/or whether is unlikely to present material risks to some financial entities (FEs). arrangement includes multiple ICT services. Regarding S12, "Hardware and physical devices" should cover the provision of hardware and physical devices in the form of service. Some categories of definitions have been modified to clarify the doubts raised in the consultation process. In this regard, it is necessary to highlight that the taxonomy cannot cover each of the respondent’s specificities and ICT TPPs. The use of the term “Rental” is modified in several elements of the taxonomy. The category "other" and the former table RT.07.01 have been removed. For ease of use and to reduce the associated burden, it has been considered to eliminate both aspects, considering that the list of types of ICT services is
Topic Summary of the comments received
ESAs’ analysis sufficiently representative to include all the types of ICT services identified. In this way, the FEs will not have to define additional ICT services using this template.
Regarding the use of standards, ESAs have already considered the different standards available, including those mentioned by some respondents. These standards cannot be considered to fit properly for the purpose of this draft ITS and the taxonomy, although considered and used as much as possible to prepare the taxonomy.
7. Feedback from the Stakeholder Groups
7.1 GENERAL OBSERVATIONS
The Stakeholder Groups (SGs) welcome the opportunity to comment on the ITS and consider and agree the proposed standard templates can be used for the establishment of harmonized registers for
information on the use of ICT services provided by ICT third-party service providers (ICT TPPs) in order to support the sound monitoring of ICT third-party risk in the financial sector. The SGs overall advocate the requirements of the ITS should not lead to double reporting and overlaps.
The SGs also arise concerns with the level of information in the register since requires an overwhelming effort and with the approach undertaken being different than the one of the EBA/SSM register on outsourcing when looking at the higher number of data points required in the templates.
ESAs response
The ESA welcome and take note of the feedback received from the ESA’s SG. ESAs note the strong pushback from the public consultation and agree with some of the proposals to reduce or clarify some provisions of this ITS to ease the reporting for financial entities, while recognising the data is fundamental for the oversight framework.
7.2 DETAILED COMMENTS
1. Can you identify any significant operational obstacles to providing a Legal Entity Identifier (LEI) for third-party ICT service providers that are legal entities, excluding individuals acting in a business capacity?
The SG note the requirement to provide an LEI for all relevant legal entities goes beyond current industry practices and fails to consider the practical challenges of procuring LEIs across extensive supply chains which often comprise multiple material subcontractors.
Requiring financial entities to ensure that material subcontractors procure LEI for themselves as indicated by Art. 4 (8) appears challenging given the indirect nature of the relationship with the subcontractor and contractual arrangements with the direct ICT TPP.
The SG considered the ITS may clarify that for legal entities, where LEI are not available, like for natural persons, the ESAs may be able to accept other means of identification, such as legal names or NACE codes at least for a transitional period. Also it might be difficult for financial entities to ensure that ICT service providers and material subcontractors "shall procure and maintain a valid LEI" as Art. 4(8) sets out.
ESAs response
One of the objectives of DORA is to ensure a sound monitoring of ICT third-party risks in the financial sector and to enable this the LEI is a crucial information.
In order to ensure a sound monitoring of ICT third-party risks, LEI identifies unambiguously and consistently the ICT third-party service providers. LEI is used worldwide to help identifying all financial legal entities on a globally accessible database. There are several LEI issuers around the world that issue and maintain the identifiers and act as primary interfaces to the global directory. Therefore, the non-EU ICT TPP can also obtain an LEI. As a proportionate approach that is under ESA’s consideration is a transitional period for those ICT TPP without LEI that are not critical to provide other alternative solutions.
Furthermore, as a risk-based proportionate approach, LEI will apply only to subcontractors that effectively underpin an ICT service supporting a critical or important function or material part thereof.
2. Do you agree with Article 4(1)(b) that reads ‘the Register of Information includes information on all the material subcontractors when an ICT service provided by a direct ICT third-party service provider that is supporting a critical or important function of the financial entities.’? If not, could you please explain why you disagree and possible solutions, if available?
The SGs overall support the Article 4(1)(b) but arise issues regarding international ICT TPP that might be so large or complex and burdensome to identify all subcontractors alongside the ICT supply chain supporting FE’s functions. A requirement for those ICT TPP under supervision by the ESAs to report on their subcontractors and make available that information on the ESAs webpage could be an alternative.
Regarding the definition of ‘material subcontractors’ the SGs suggest that the scope should be limited to subcontractors providing a material part of the ICT service supporting a critical/important function, whose disruption or failure could lead to material impact to service provision.
ESAs response
The ESAs acknowledge the concern raised regarding the definition of ‘material subcontractors’ and have amended it in the current recital 6 and Article 3 (1)(b).
3. When implementing the Register of Information for the first time:
-
What would be the concrete necessary tasks and processes for the financial entities?
-
Are there any significant operational issues to consider?
Please elaborate.
The SGs consider the register of information should ideally leverage on existing information kept in similar registers to reduce unnecessary burden for the reporting entity. However, the identification and sourcing of the information required in accordance with Article 4(4) of the ITS may take substantial time and efforts, particularly at consolidated level or more complex institutions.
Since a 1-year implementation period may be challenging for entities that use the services of a large amount of ICT TPP, the SGs advocate for two-year transition period.
The ITS should also clarify to what extent this register of information may replace or complement information requirements of the EBA GL on outsourcing arrangements and existing requirements from competent authorities (CA), such as the SSM. The SGs are of the opinion, that the register of information should serve both requirements, since ICT and outsourcing services are very similar in many aspects.
The challenge would also be how to align with EBA Outsourcing Register, when the scope is different. Also, firms have already invested in developing the EBA Outsourcing Register and cannot leverage this effort if now firms need to follow specific templates. The proposed solution might be to leave existing financial entities subject to the EBA GL to add to their existing Registers a second layer identifying ICT service providers included in the supply chain of functions falling in scope of outsourcing.
ESAs response
The extension of the timeline for the implementation go beyond the ESAs’ mandate sets out in Article 28(9) of DORA that only refers “to develop draft implementing technical standards to establish the standard templates for the purposes of the register of information, including information that is common to all contractual arrangements on the use of ICT services”.
With regard to the point on the ECB SSM outsourcing register, the ESAs acknowledge the necessity to avoid double-reporting and take note of this point. The ESAs will consider this comment for upcoming discussions.
4. Have you identified any significant operational obstacles for keeping information regarding contractual arrangements that have been terminated for five years in the Register of Information?
No comment.
5. Is Article 6 sufficiently clear regarding the assignment of responsibilities for maintaining and updating the register of information at sub-consolidated and consolidated level?
The SGs point out Article 6 lacks sufficiently clarity as regards the assignment of responsibilities for maintaining and updating the register of information at sub-consolidated levels. Furthermore, it vaguely refers to "all financial entities part of the group", and thinking about certain entities based outside of the European Union, it seems difficult that the "ultimate parent company undertaking" takes the lead on defining the scope of consolidation and sub-consolidation for the purposes of this EU Regulation.
ESAs response
The ESAs welcome the comments received. The ESA’s aim to provide clarify and avoid unnecessary costs and burdensome reprocessing of data for reporting purposes. To that end, the ITS clarifies in Recital 3 that groups may develop a single register of information at entity, sub-consolidated and consolidated levels in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers to all the financial entities, which are part of the group. In such cases, the single register of information should allow each financial entity to fulfil its obligation to maintain and update the register of information at entity and sub-consolidated level, when applicable, including its reporting to its competent authority”.
The ESAs acknowledge that further clarity is needed to define the perimeter of consolidation. For that, Article 6 (1) of ITS has been redrafted to define the scope of consolidation as follows: “In the case of groups, the parent undertakings shall take into account the relevant financial services regulations when identifying the scope of entities to be included in the register of information”.
6. Do you see significant operational issues to consider when each financial entity shall maintain and update the registers of information at sub-consolidated and consolidated level in addition to the register of information at entity level?
The SGs acknowledge that not all groups may operate central systems but if it is the case, timely alignment and updating of registers kept at different entity levels may lead to operational issues.
Article 4 (3) requires financial entities to update the information contained in the register of information on an “on-going” basis. Financial entities shall, based on the risk profile of their ICT third-party providers, define in which intervals the documentation shall be updated.
The SGs highlight that the ITS establishes uniform templates for the register of information. Thus, it opposes the provision in Article 9 that competent authorities shall – in addition to these uniform templates - set out appropriate formats for reporting purposes. The SGs advocate that the format as set forth in the ITS shall be used to forward information to the competent authorities.
Furthermore, the SGs consider complex to apply in multinational groups with entities based outside of the European Union and with multiple legal entities operating different business lines. In addition, based on our experience with the EBA Register, it is operationally complex to identify a "contractual reference number" that allows to establish the linkages with other entities within the same group and external service providers.
ESAs response
The ESAs welcome the comments and agree with changing the drafting of the current Article 3 (2) to update the register from “ongoing” to a “regular basis”.
As it was explained in the above question, the ESAs have modified Article 6 of the ITS to allow groups to maintain and update a single Register of Information at the most consolidated level which shall allow a breakdown per each entity and sub-groups, where applicable.
7. Do you agree with the inclusion of columns RT.02.01.0041 (Annual expense or estimated cost of the contractual arrangement for the past year) and RT.02.01.0042 (Budget of the contractual arrangement for the upcoming year) in the template RT.02.01 on general information on the contractual arrangements? If not, could you please provide a clear rationale and suggest any alternatives if available?
The SGs do not agree with the inclusion of these data points for the purposes of monitoring and supervising activities as regards digital operational resilience and consider there is not a linkage between both for the assessment of criticality of the services provided by ICT TPPs. In case of intragroup outsourcing services, budgeting of such expenses is typically fully embedded in the annual process at the legal entity level and cannot necessarily be compared to the costs of using an external ICT TPP. The SGs suggest to consider one of them and not both.
ESAs response
From a supervisory and risk management perspective, the annual cost of the contractual arrangements for the past year represents a fundamental source of information to assess and compare the type of outsourced services and their criticality.
It allows both FEs and supervisory authorities to reach a deeper understanding of the third-party risk exposures, being therefore a key component for improving the operational resilience of each FE and the system as a whole. From a prudential and risk management point of view, it is important to understand the “size” of the different services provided by each provider in order to evaluate operational and concentration risks. The register is also a supervisory tool and should contain the information required to understand the third-party dependencies and not only the necessary information to identify CTPP.
Therefore, the ESAs disagreed with removing it from the template.
A new field has been added RT.05.01.0060 Total annual expense or estimated cost of the ICT third-party service provider that is mandatory if the ICT third-party service provider is a direct ICT third-party service provider.
Furthermore, budget of the contractual arrangement for the upcoming year data point has been removed from the template.
8. Do you agree that template RT.05.02 on ICT service supply chain enables financial entities and supervisors to properly capture the full (material) ICT value chain? If not, which aspects are missing?
The SG consider it is unclear to what extent the ranking of subcontractors provides meaningful information. The SGs are of the view it is important that the register differentiates between (i) direct third parties and (ii) material subcontractors for the purposes of supporting effective risk management and oversight. This answer is connected to Q2 regarding material subcontractors.
ESAs response
The ESAs, considering the comments received, have drafted a new Recital 6 to clarify the following: The provision of ICT services to financial entities may rely on potentially long or complex chains of subcontracting which should be monitored by the financial entities. Financial entities should assess the associated risks, including ICT third-party concentration risk with regard to the ICT third-party service providers supporting a critical or important function or material part thereof, considering a risk-based approach and the principle of proportionality. To enable this assessment, financial entities should be required to document within the register of information only those subcontractors that effectively underpin ICT services supporting critical or important functions or material part thereof, including all the subcontractors providing ICT services whose disruption would impair the security or the continuity of the service provision. In identifying those subcontractors, financial entities should consider business and ICT service continuity and ICT security aspects”
9. Do you support the proposed taxonomy for ICT services in Annex IV? If not, please explain and provide alternative suggestions, if available?
The SGs note that though Annex IV captures several ICT services that are unlikely to present material or systemic risks to some financial entities, most data points still apply which may result in overly broad reporting requirements and scope. The SGs, therefore, advocate a more proportionate and risk-based approach to the reporting requirements based on the level of risk the service, without introducing a standardized classification of risk that would impact a financial entity’s risk assessment.
In addition, The SGs consider the proposed taxonomy includes several categories which should not be classified as ICT services and are, therefore, inconsistent with the definition of ICT services in the Level 1 text.
The SGs suggest following the approach of art. 3 (21) of DORA, specifying the scoping criteria rather than including a closed list.
ESAs response
The ESAs welcome the feedback received on the taxonomy and have streamlined accordingly the type of ICT services in Annex III (former Annex IV) on Type of ICT services.
10. Do you agree with the instructions provided in Annex V on how to report the total value of assets and the value of other financial indicator for each type of financial entity? If not, please explain and provide alternative suggestions?
The SG do not agree with the instructions provided in Annex IV since it is not clear the relevance of this information for the purposes of the register of information.
ESAs response
The ESAs are of the view the total value of assets is an important data point to perform:
-
The designation of critical ICT third-party service providers, through relevant criticality indicators, as indicated in their Technical Advice to the European Commission’s Call for Advice of December 2022 on two delegated acts specifying further criteria for critical ICT third-party service providers (CTPPs) and determining oversight fees levied on such providers, under Articles 31 and 43 of DORA13;
-
The appointment of the Lead Overseer once the CTPPs are designated.
[13] 13Joint-ESAs__response_to_the_Call_for_advice_on_the_designation_criteria_and_fees_for_the_DORA_oversight_framework_fin al.pdf (europa.eu)
However, the ESAs agree to delete the value of other financial indicators from the ITS. For reference, it is Annex IV in the final report.
11. Is the structure of the Register of Information clear? If not, please explain what aspects are unclear and suggest any alternatives, if available?
The SGs note the requirement included in Article 3(1)(b): “... If more than one value is valid for a specific data point, the financial entity shall add an additional row in the corresponding template for each valid value” may increase the number of rows exponentially and make it difficult for FEs to fill in and review the report. The SGs recommend amending the structure of the templates to allow FEs to separate multiple values with a semi-colon in order to minimise the number of rows.
ESAs response
The templates established by this Regulation are designed in a technology-neutral manner building up on open tables (i.e. tables with a predefined number of column but an indefinite number of rows). The templates are linked to one another by using different specific keys to form a relational structure between them. Hence, allowing multiple values reported in a single data point would lead to potential data quality issues when processing the data reported in the register of information. For reference, the article is 4(1)(b) in the final report.
12. Do you agree with the level of information requested in the Register of Information templates? Do you think that the minimum level of information requested is sufficient to fulfil the three purposes of the Register of Information, while also considering the varying levels of granularity and maturity among different financial entities?
The SGs note it appears not immediately obvious why certain information is needed for the purposes of monitoring and supervising activities as regards digital operational resilience. To the contrary, it seems that important information for the risk assessment of ICT third-party risk by the financial entities, is not requested, such as the number of incidents that happened at the ICT TTP, whether they conform to all regulatory provisions governing ICT risk or whether the (external) auditor had any findings on ICT risk management.
The SGs are of the opinion, that some references require a more thorough definition, such as:
• RT.02.02.0170: identification of level of sensitiveness of the data stored or processed by ICT
third-party providers. Rather than classifying sensitiveness as “high, medium, low”, it should be tied to existing concepts of sensitive data, such as the GDPR
• RT.08.01.: “easy, difficult, highly complex” reintegration of contracted ICT services
ESAs response
The register of information templates provide the minimum level of information to be reported in. Therefore, financial entities could complement the information reported in those templates by tailoring them to their internal and entity risk management purposes with additional relevant information for their own risk management purpose.
With regards to the 2 following specific remarks, the ESAs discarded them because:
-
RT.02.02.0170: The ESAs would like to clarify that DORA introduces requirements for digital operational resilience, which is different in scope and objectives to GDPR. GDPR focuses on personal data while DORA has a larger scope. The ESAs would like to highlight that the template RT.99.01 allows the FEs to provide their entity-internal explanations, meanings and definitions of the closed set of indicators used in the register of information.
-
RT.08.01 (now RT.07.01): The ESAs would like to highlight that the template RT.99.01 allows the FEs to provide their entity-internal explanations, meanings and definitions of the closed set of indicators used in the register of information.
13. Do you agree with the principle of used to draft the ITS? If not, please explain why you disagree and which alternative approach you would suggest.
The SGs consider it is unclear what the question refers to.
14. Do you agree with the impact assessment and the main conclusions stemming from it?
The SGs did not reply to this question
Note from RegAlert. AI assistants can read this document in full, and search 70,000+ more, through the RegAlert MCP connector (https://mcp.regalert.today/mcp). Free with an account. How to connect ChatGPT, Claude or Cursor.
- Obligation 147
- Permission 14
- Definition / condition 281
- Reporting template 210
- background, boilerplate
Lineage
The documents this one cites, and the documents that cite it.
The links and the sentences they come from (1)
- Issued under
“Article 28(9) of DORA mandates the European Supervisory Authorities (ESAs) to develop draft implementing technical standards to establish the standard templates for the purposes of the register of information”
Mentions (2): 2 documents this one mentions without changing them
- Refers to
“Article 3 of DORA makes reference to Directive 2013/34/EU (the Accounting Directive) to define the meaning of a ‘group’, a ‘parent undertaking’ and a ‘subsidiary’.”
“relevant regulations referred to in Article 3 points (31) to (59) and Article 46 of DORA, which include also Directive 2002/87/EC “financial conglomerates directive”.”
Similar documents from other regulators
EBAFinal Report on Draft Implementing Technical Standards for Register of Information on ICT ServicesEuropean Union · 2024-01-17
ECCommission Implementing Regulation (EU) 2024/2956 laying down implementing technical standards for standard templates for the register of informationEuropean Union · 2024-12-02
More like this from ESMA
ESMA published 9 documents in the last 30 days. We email you each new one the day it's published.
Source: European Securities and Markets Authority — original document · Summary generated with machine assistance and reviewed before publication; the authoritative text is the regulator's original document. How RegAlert works
In RegAlert: added