DORA Red Flags: Is IT a Critical or Important Function?

The answer to this question will help illustrate the complexity of DORA.

It will also help to highlight several red flags for any Financial Entity that wants to comply with the Implementing Technical Standard (ITS) on the Register of Information (ROI) [EU 2024/2856].

Starting this month, Compliance By Design will publish a series blogs highlighting DORA Red Flags to help create awareness of future issues, develop knowledge and skills and promote best practice design when implementing Regulatory requirements.

It is important to keep in mind, that this is a journey for Regulators too. Digital Compliance, a collection of new Regulatory Themes, is in its infancy and changes will be made as more experience is gained.

Red Flags

Many of the DORA Red Flags are not about the work to create and upload the ROI, which on its own, is a significant challenge that every Financial Entity is struggling with at present. They relate to the approach taken when creating the upload and the data maintenance issues that will arise after a Financial Entity has completed its first submission.

The good news is that there is still time, through the application of established system design best practices, to identify these issues and future proof against inevitable regulatory changes (what is already referred to as DORA 2.0).

By identifying these issues now, and taking corrective action, you can avoid a DORA Data Disaster in the second half of 2025.

So, should you include your IT function in the assessment of a CIF?

Article 3 (22) of the Digital Operational Resilience Act (DORA) [EU 2022/2554] establishes four standards when assessing a CIF, anyone of which will result the function being designated as a CIF. It is probable, that the IT function, in every Financial Entity will satisfy all four standards.

‘critical or important function’ means a function, the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law;

There is no need to assess any other function, if your IT department is a CIF. By implication, every system used by the Financial Entity, will support a CIF.

The definition of a CIF in DORA does not differentiate between Business and IT functions, an important distinct when modelling interdependencies. Perhaps something that might be considered for DORA 2.0.

Business functions are responsible for your Operating Model, IT functions are responsible for your IT Services Model, that supports your Operating Model. “It starts with requirements; systems automate business processes” is a fundamental principle that is universally accepted.

Origin of DORA

The definition of a CIF needs to be interpreted by reference to Recital (4) of DORA and specifically the work of the Basel Committee on Bank Supervisory (BCBS) and the Financial Stability Institute (FSI). The work of BCBS, the Central Bank of Central Banks and FSI, is overarching, setting the global scope for the development of all Operational Resilience Regulatory Requirements.

I would highlight the FSI Connects Principles for Operational Resilience (POR) – Executive Summary which establishes 7 principles. It is a must read for anyone who wants to understand the objectives of DORA (link: FSI 7 PORs). You will learn more about the objectives of DORA in the 3 pages of the FSI Connects Executive Summary than in 3 months of trying to figure out the legal text.

Interconnections and interdependencies

The 4th POR - Mapping interconnections and interdependencies provides clarity on the separation required between Business and IT functions.

“Once a bank has identified its critical operations, the bank should map the internal and external interconnections and interdependencies that are necessary for the delivery of critical operations consistent with its approach to operational resilience.”

Identifying critical operations in your Business Operating Model is a pre-requisite to mapping interconnections and interdependencies to your IT Services Model. Separation of these two models is key to the identification of interdependencies and interconnections (which is given legal effect in Article 8 of DORA). The Business Operating Model and IT Services Model are like oil and water. Including your IT function in a CIF assessment compromises a fundamental principle required to identify interconnections and interdependencies.

The 4th POR provides 3 points of guidance to help you with the objective. The first point establishes the link to third parties which is further developed in the 5th POR – Third-party dependency management.

“Mapping implies identifying and documenting people, technology, processes, information and facilities relevant for critical operations, including those operations that depend on third parties.”

DORA’s ROI is designed to help you identify dependencies on third-parties (and to help Regulators to assess the criticality of third-parties in supporting the EU’s financial system). A later blog will go into more detail on the objectives and guidance provided in the 4th and 5th POR.

Dry Run - Register of Information

The IT function is responsible for IT Service delivery (as well as the System Development Lifecycle / IT Service Delivery Model). The critically of the IT Services is derived from the CIF assessment of the Business Functions they support. That appears to be the intent.

During the summer of 2024, the ESAs facilitated an exercise to allow Financial Entities conduct a dry run to gain experience of the data upload based on the Standard Templates specified in the draft ITS submitted to the EU Commission on 17th January 2024.

There was significant participation by Financial Entities in the Dry Run based on the key findings presented on 17th December 2024.

The Dry Run included a number of resources to help Financial Entities participate – a web page, a Q&A with 127 entries, a entity relationship diagram with key fields, two examples of a completed ROI with data for each of the 15 standard templates (Example A and B) etc. These are invaluable resources as they deal with a level of precision that is meaningful and allows a two-way conversation between Regulators and Professionals working at Financial Entities.

In the presentation of the key findings, a 2.5 hour long webinar, many of the questions asked by participants, could not be dealt in the time allowed. The message to the ESAs is clear, the DORA Dry Run engagement is a step in the right direction as it is meaningful to those whose job involves the real world of operations (for all Regulatory Themes). Technology is available that can help bring this type of wide engagement to a new level.

Business or IT Function?

The first step in completing a CIF assessment, involves deciding if it is a Business or IT function. You then assess Business Functions and identify the interdependencies and interconnections “that are necessary for the delivery of critical operations” (the IT Services supported by the IT function).

The first record in example A of the Dry Run, template B_06.01 – Functions Identification, is identified as function F1 – Support Data Analysis. The name suggests it is an IT Function, but it could also be a decision support Business Function that uses an Analytics system. The nature of the work will determine if a function is a Business or IT Function. In the example, more information is required to complete that assessment.

An evaluation that can helpful, is to consider how the function would behave if you were to remove all the systems. If it is a Business function, it will adopt manual procedures to ensure that services continue to be delivered to customers. It is worth remembering that IT functions are relatively new in the context of Financial Services - Banks, Funds, Insurance businesses have operated for 100's of years without technology.

Conclusion

Accountants use a system of double-entry bookkeeping, for every debit there must be a corresponding credit. When modelling interdependencies and interconnections between Business and IT, think of the Operating Model as a debit and the IT Services Model as a credit. If the IT Function is also a debit, the model gets very complicated as you scale.