DORA Red Flags: The missing key from the ITS Register of Information Standard Templates

The way a Financial Entity collects data to comply with ICT Third-party Service Provider requirements of the Digital Operational Resilience Act (DORA) [EU 2022/2554], is different, to the way you report it to your Competent Authority.

Data Integrity 101

Data collection requires uniqueness, achieved by using keys, to ensure it can be updated after it has been recorded. Together, key fields are designed to ensure referential integrity in a relational database. You are prevented from deleting a record with a key field that is referred to in another table in the database (known as a foreign key). Data recorded in this way is referred to as a normalised format.

Normalised data is used to record a transaction, it is optimised for speed of processing.

Once recorded, data can be used across multiple reports. Reporting data of this type is referred to as a de-normalised format. It is the type of data you work with in an analytics database.

De-normalised data is used to gain insights, it contains duplication and is optimised for speed of reporting.

This type of data is used to gain insights into customer behaviour over time. It looks across all transactions to build a profile of behaviour for an individual customer and compare it with the behaviour of different customer segments.

Data used in spreadsheet, such a Microsoft Excel, is usually in a de-normalised format, there is duplication across multiple sheets. If you update a value in one sheet, that you have previously copied to other sheets, you must find and update all the copied values to ensure data consistency. Lookup functions are often used to automate these updates however they rely on the skills of the individual with no built-in integrity checks.

The 4 Keys in the Register of Information

DORA’s Implementing Technical Standard (ITS) for the Register of Information (ROI) [EU 2024/2956], establishes how a Financial Entity reports contracts with ICT Third-party Service Providers to a Competent Authority. There are 15 Standard Templates with more than 100 fields of data. Recital (8) of the ITS ROI identifies 4 keys.

To allow transparency and comparability of contractual arrangements and the ongoing monitoring of those arrangements, the register of information should focus on the operational links between the financial entities and the ICT third-party service providers. To that end, the register of information should use four keys, which, among others, linking relevant data to each other across the templates of the register of information: (i) the reference number of the contractual arrangement between the financial entity signing that arrangement and the direct ICT third-party service provider, (ii) an appropriate identifier of financial entities and ICT third-party service providers, (iii) the function identifier, and (iv) the type of ICT services.

The identifiers for a Contract, a Legal Entity and a Function (within a Legal Entity) are easy to understand, as you can quickly relate them to the real world.

ANNEX I Part 2 of the ITS ROI specifies the data in each of the Standard Templates, here is what is included for each of these 3 keys:

Contract Key. Column Code B_02.01.0010 Contractual Arrangement Reference Number.

• 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.

Legal Entity Key. Column Code B_01.02.0010 LEI of the Financial Entity.

• Identify the financial entity reported in the register of information using the LEI, 20-character, alpha-numeric code based on the ISO 17442 standard

Function Key. Column Code B_06.01.0010 Function Identifier.

• The function identifier shall be composed by the letter F (capital letter) followed by a natural number (e.g. “F1” for the 1st function identifier and “Fn” for the nth function identifier with “n” being a natural number).

• Each combination between ‘LEI of the financial entity making use of the ICT service(s)’ (B_06.01.0040), ‘Function name’ (B_06.01.0030) and ‘Licenced activity’ (B_06.01.0020) shall have a unique function identifier.

The LEI of the Financial Entity is a unique key in a standard format managed by a global organisation based on ISO 17442.

There was much discussion and some delay in finalising the ITS ROI, relating to the legal identifier, which eventually resulted in a compromise with the introduction of EUiD, a free open-source identifier as an additional identifier. There was no discussion about the other keys.

It is important to note again, that the Standard Template specifications are in a de-normalised format where you can expect duplication. For example, the LEI of the Financial Entity appears in several different Standard Template specifications and the context in which it is used is different throughout. It is used to identify the head office, the entities within scope. the entity signing the contract, the entity using the service, etc.

Where is the ICT Services Key?

The 4th key in recital (8) is Type of ICT Service, what is that about?

How does that relate to the real world of ICT procurement, and how can a service be uniquely identified so that you can update it, after you complete your first submission to the Competent Authority?

Type is typically an attribute used for classification which is selected from a list of pre-defined values (which must also be unique). For example, a customer is uniquely identified and then attributes selected to build a profile of that customer. Data like country, gender, age, preferences for the products and services offered by a business etc.

An experienced data modeler, will want to know more about the real-world use of “the type of ICT Services”

The Standard Template specifications in ANNEX II Part 2, start on Page 10 and end on Page 36 of the ROI ITS. There are 47 references to ICT Services.

The only field that appears to be used as the key in Part B, is B_02.02.0060 Type of ICT Services with a set of 19 values in ANNEX 3 to pick from. The pick list values are generic descriptions such as ICT Project Management, Data Analysis, Network Infrastructure, ICT Consulting etc.

How does that relate to a contractual agreement with Microsoft for the apps most business users depend on each day - Windows, Outlook, Excel, Word, Powerpoint, Teams etc?

ICT Services are the backbone of the Register of Information, they connect ICT Third-party Service Providers to Legal Entities and Functions (and associated Regulatory Authorizations) that use the services. A Financial Entity’s dependency on Microsoft Outlook and Microsoft SQL Server is very different.

How are you going to risk assess the nature of each dependency by using a generic identifier that can apply to several different ICT Services in a contract?

How are you going to update these assessments over time without a unique identifier that clearly defines each ICT Service?

Maybe we missed something in our analysis, these are foundational questions that require a red flag until answered.

Nature of ICT Contracts

Procurement of ICT Services usually starts with a master agreement establishing terms and conditions that apply to all services with a separate schedule identifying the services. Additional services, with specific terms and conditions, may be added to the schedule of services. Addendums will be signed as new services are added over time, each subject to the agreement established by the master contract.

For every contract there is one or more services, what it known as a one-to-many relationship (Legal Entity to Functions is another one-to-many relationship). You need a key for a contract and a key for each service if you want to reflect the real world of IT procurement in a data model.

To use a real-world example, Microsoft updated its terms of use in on 30th September 2024. The final section, “Covered Services”, from the updated Microsoft Services Agreement contains 132 “…products, apps and services…” and includes entries such as Microsoft 365, Microsoft Teams, OneDrive and Outlook that are used extensively by businesses as well as Xbox, Bing and MSN that are more focused on consumers.

Microsoft also provides enterprise solutions for both Developer and Business use, such as SQL Server and Microsoft Dynamics, under separate contracts.

Dry Run Excel Examples

The ITS ROI in Article 4 (2) – Data format requirement, requires a Financial Entity to add an additional row “Where more then one value is valid for a specific data element…”

Keep in mind that this is how you report the data to the Competent Authority and that each of these additional rows must be maintained.

Collecting data using a “Just add an Additional Row” approach is an additional data maintenance Red Flag. The issues will arise after the first ROI submission to your Competent Authority.

If you plan to collect your data by re-using the Excel Examples from the Dry Run and add an additional row “Where more than one value is valid”, you should be prepared for a DORA Data Disaster in the second half of 2025, when you try to update your submission for changes.

This also applies if you plan to use a vendor solution (or develop your own solution), where data collection is based on the Standard Templates specifications. That is the same approach that excel uses, just with a user interface. A fit for purpose solution for ROI data collection, requires referential integrity based on a normalised data model, a solution that ideally integrates with your existing ICT Procurement process to ensure data is updated when new contracts and services are added.

In summer 2024, Compliance By Design, created the architectural diagrams based on the draft ITS ROI that was submitted to the EU Commission on 17th January 2024, for a normalised data model (an entity relationship diagram with referential integrity) and proved the model by building a prototype to recreate Example A and B from the Dry Run. The design effort, by an experienced data modeler, was 50 days. These architectural diagrams are available as part of the Digital COE Operational Resilience.

Sizing the ROI Submission

There are 15 Standard Templates to be completed to identify dependencies between a Financial Entity its ICT Third-party Service Providers.

The modelling of the dependences has to identify the relationship between the ICT Services in each contract and the Legal Entities that uses the service down to a Function, License and Branch level. It includes the dependencies within groups where there are intragroup ICT Third-party Service Providers.

In one medium sized business we are familiar with, there are 30 Legal Entities in the Group and more than 300 contracts. The operating model has 20 functions. That is 180,000 potential “add another row” dependencies before you consider branches, licenses and assumes that each contract has a single service. For Banks, it is 1,000’s of contracts.

The potential for a DORA Data Disaster if you take the wrong approach, with this level of data, won’t be about recovery, it will be about failure with a need to start over.

Blaming the Regulator won’t Work

The Regulators role is to set out the requirements, which it has done in the ITS ROI, gaps and all. Regulations are enacted at a point and Regulators will change their approach with experience, DORA 2.0 is already on their agenda. Each Financial Entity must deal with that reality and ensure the approach is both fit for purpose and future proofed.

There is still time to address these issues before a Financial Entity completes its first submission.