Understanding DORA Core Concepts: Spotlight on 'Critical or Important Functions'

17.10.2024 DORA

Aiming to establish a high level of digital operational resilience, DORA provides a comprehensive framework for managing ICT risks effectively.

DORA is a comprehensive ICT risk management framework with the objective to establish a high level of digital operational resilience. It revolves on several key concepts, such as the "principle of proportionality," or the "ICT services, systems, and applications supporting critical or important functions."

In this Article, we focus on the latter, examining the importance of assessing and identifying ICT assets and services that support critical or important functions. We will also explore how this assessment forms the foundation for subsequent steps in achieving DORA compliance.

The context

Aiming to establish a high level of digital operational resilience, DORA provides a comprehensive framework for managing ICT risks effectively. This goal is supported by five key pillars. The characteristic of DORA is that it interlinks everything, every pillar is connected to the other ones. There are cross-references throughout the law and to the associated Technical Regulatory Standards (RTS), Technical Implementation Standards (ITS) and Guidelines. As of today, there DORA Framework consists of 12 supplementary legal acts.

As a result, DORA pursues financial organisations to solve the security of networks and information systems holistically. This means that all departments, all areas must cooperate with each other. The financial organisation's management body remains responsible for implementation.

In this context, also the subject matter “critical or important functions” finds materiality throughout DORA key pillars:

Pillar I	ICT Risk Management Framework (Chapter II)	General provisions for strategies, policies, procedures, ICT protocols and tools that are necessary to protect all ICT assets, particularly those supporting critical or important functions.
Pillar II	ICT-related incident management, classification and reporting (Chapter III)	Major ICT-related incidents, i.e. incidents that have a high adverse impact on the network and information systems that support critical or important functions of the financial entity, are subject to mandatory reporting.
Pillar III	Digital operational resilience testing (Chapter IV)	a) Applications and systems, which support critical or important functions, must be tested once in a year. b) If TLPT must be conducted, several or all critical or important functions fall within the scope.
Pillar IV	Managing of ICT third-party risk (Chapter V)	ICT third-party services that support critical or important functions are subject to more extensive contractual agreements. The financial institutes also must adapt a strategy on ICT third-party risk.
Pillar V	Information sharing arrangements (Chapter VI)	Voluntary exchange of cyber threat information and intelligence with a view to enhancing the capabilities to adequately assess, monitor, defend against, and respond to cyber threats. It includes all kinds of information.

Asset management

The first step is to carry out an inventory, an assessment of your own ICT network.

The responsibility to identify which applications and functions support critical or important functions, lies with the financial institution itself. A helpful guideline to conduct this assessment is given in the definition in DORA:

Definition:

Under DORA, a function is considered "critical or important" if its disruption could significantly impact a financial institution's financial performance, stability, or the continuity of its services and operations. Likewise, if any disruption, malfunction, or interruption of that function would substantially affect the institution's compliance with its authorization conditions and other regulatory obligations under applicable financial services laws (Art 3(22) DORA).

The other helpful guideline is to follow the principle of proportionality (Art 4 DORA). Financial institutions should consider their size and overall risk profile, as well as the nature, scope and complexity of their services, activities and operations. It's evident that the risk profile and complexity of services vary greatly between microenterprises and international banks.

As a result, the evaluation can lead to different results from one financial institution to another.

Pillar I - ICT risk management framework

The Chapter II lays down the core requirements for DORA compliance – the ICT risk management framework.

Within this framework, in relation to critical or important functions, financial institutions are required, inter alia, to:

Identify all information and ICT assets, and map those considered critical, including remote sites, network resources, and hardware, along with their configurations, links and interdependencies (Art 8(4) DORA).
Document processes which are dependent on ICT third-party service providers, and identify interconnections with those supporting critical or important functions (Art 8(5) DORA).
Develop and implement ICT security policies and tools to ensure the resilience, continuity, and availability of systems, especially those supporting critical functions, while maintaining high standards for data security (Art 9(2) DORA).
Apply the ICT business continuity policy through documented arrangements to ensure the continuity of critical or important functions and effectively respond to ICT-related incidents (Art 11(2) DORA).
Establish, maintain, andperiodically test ICT business continuity plans, particularly for critical or important functions outsourced to ICT third-party service providers (Art 11(4) DORA).

All contents of ICT risk management framework are necessary to effectively meet the requirements of the other pillars.

The more detailed requirements for ICT Risk Management Framework are regulated in the supplementary RTS on ICT risk management and the simplified ICT risk management framework (EU 2024/1505).

Classification of ICT-related incidents as „major“ (RTS (EU) 2024/1772)

Pillar II - Incident Management, Classification of Incidents and Reporting

Following the structure of DORA, the next milepost, where “ICT systems and applications supporting critical or important functions“are mentioned, is in the Chapter III, in the context of classification of ICT-related incident.

All incidents must be solved. But if the incident is classified as major, it must also be reported. The classification of incidents is based on a Delegated Regulation, a separate Technical Regulatory Standard: RTS on Classification of major incidents and significant cyber threats (EU 2024/1772).

The classification process is as followed:

1. After discovering the incident, the first step is to analyse the criticality of the affected services.

Criterion a) is used to assess whether the ICT services or network and information systems that support critical or important functions are affected.

Criterion b) assesses whether the financial services that require authorisation or registration, or are supervised by the competent authorities, are impaired.

Criterion c) assesses whether there has been successful, malicious and unauthorised access to the network and information systems that could lead to the loss of data.

2. If none of the criteria are met, the incident is not to be classified as major, and must this not be reported.

3. If criterion c) is affected, the incident is classified as major.

4. If criterion a) or criterion b) are affected, further criteria must be examined in relation to the respective materiality threshold. The further criteria are:

Clients, financial counterparts and transactions;
Reputational impact;
Duration and service downtime;
Geographical spread;
Data losses; and
Economic impact.

When the materiality threshold of two or more further criterions is met, the incident is classified as major.

There are two supplementary legal acts regulating incident reporting relatedissues:

Both documents were published on July 17, 2024 in the form of final reports of ESAs. In the next step, they will be adopted by the European Commission, reviewed by the European Parliament and the Council. And finally published in the Official Journal of the EU.

The reporting deadlines are very short. The initial report must be submitted as soon as possible, but no later than 4 hours after the incident is classified as major, and no later than 24 hours after the financial entity becomes aware of the incident. If an incident is classified as major at a later stage, the financial entity must submit the initial report within the 4 hours after the classification.

In the event of an ICT-related incident, it is important to react quickly and appropriately. That is why DORA puts a lot of emphasis on preparedness. One must have knowledge of its ICT-network and have measures in place for rapid incident detection and response.

It would take a lot of valuable time to start assessing which assets support critical and important functions when one is busy with resolving the incident. Asset analysis must be conducted earlier.

Test methodology and co-operation with authorities — Sources: BaFin and Final report on Regulatory Technical Standards specifying elements related to TLPT

Pillar III - Digital operational resilience testing programme

The Chapter IV of DORA regulates the requirements for digital operational resilience testing. DORA outlines two primary forms of assessments:

Digital Operational Testing Programme

In other words, security testing of all ICT systems and applications that support critical or important functions at least once in a year.

DORA narrows the scope of security testing to “ICT systems and applications supporting critical or important functions” (Art 24(6) DORA).

For the security testing, DORA provides an exemplary list of testing methods: vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing.

DORA requires these tests to be carried out once a year. This means that the financial institution should develop a test plan for one year. The analysis of which applications and systems fall within the scope must be renewed regularly, as the ICT-network changes over time. In other words, the test plan and scope may vary from year to year.

TLPT

Advanced testing of ICT tools, systems and processes based on threat-led penetration testing (TLPT) every three years.

TLPT will be mandatory for selected financial entities only. These will be informed by the respective competent authority.

The scope of TLPT encompasses several or all critical or important functions of a financial entity, and it shall be performed on live production systems supporting such function.

In its core, TLPT is based on the TIBER framework, but includes advanced requirements. Such as the mandatory purple team testing as part of the project. Also the organizational structure of participants is slightly different. As of today, TIBER is implemented in many EU member states with their own country-specific guidance. How much the existing requirements differ from TLPT, varies between the EU member states.

In general, the TLPT procedure is as follows:

The core requirements for TLPT are laid down in the Arts 26 and 27 of DORA. The more detailed provisions are regulated in a separate Regulatory Technical Standard (RTS). The ESA’s final report on the draft RTS was published on July 17, 2024: RTS on specifying elements related to TLPT (ESAs final report JC 2024 29).

Pillar IV – Managing the ICT third-party risk

Also, in the Chapter V one comes across with the subject matter of “critical or important functions”. For understanding this Chapter, it is important to highlight, that there are two levels of criticality in DORA:

Critical or important function - critical to the operations of a financial organisation
Critical third-party ICT service provider - systemic in nature for the stability of the European financial market.

ICT risk management of critical ICT third-party providers is regulated in Arts 31-44 DORA and in the RTS on specifying the criteria for the designation of ICT third-party service providers as critical for financial entities (EU 2024/1502) . Into this category fall Cloud providers such as Microsoft Azure, Google Cloud Project or AWS, due to their importance for the European financial market. These enterprises are audited by the European Union and are covered by the oversight framework for critical third-party ICT service providers.

Our article focuses on the first point – critical or important functions.

DORA places great emphasis on the management of ICT third party risks.

The main principle for managing ICT third party risk in relation to critical or important functions is set out in Chapter II, which governs the ICT risk management framework. DORA requires that financial entities must identify, and document all processes reliant on ICT third-party service providers, including detailing interconnections with those providers that deliver services supporting critical or important functions (Art 8(5) DORA).

The detailed provisions for managing ICT third-party risk are laid down in Arts 28-30 of DORA. In addition, the more specific provisions are covered in three supplementary acts:

Financial institutes are obliged to adopt a strategy on ICT third-party risk, which must include a policy on the use of ICT services supporting critical or important functions provided by ICT third-party service providers (Art 28(2) DORA).

DORA goes even further, also scrutinizing the subcontractors. Where ICT third-party service providers subcontract ICT services to other providers to support a critical or important function, financial institutions must evaluate the potential benefits and risks of such arrangements. With a focus on the risks associated with subcontractors based in third countries (Art 29(2) DORA).

Financial institutes also must inform the competent authority in a timely manner about any planned contractual arrangement on the use of ICT services supporting critical or important functions as well as when a function has become critical or important (Art 28(3) DORA).

And finally, Art 30 DORA prescribes the key contractual provisions. For services that support critical or important functions, more detailed and comprehensive information is required.

Summary

Identifying the services, applications, and systems, which support critical or important functions, is a core requirement in DORA. Once these assets are listed, it provides transparency for the financial institute itself and more effective compliance with DORA requirements.

In any case, it is a good exercise to examine which applications and systems are integrated into the ICT network. To understand which applications should stay, which should be uninstalled. And which ones have been forgotten over the years but are still running in the system and nobody is keeping an eye on their security. The latter is a significant security risk.

DORA places responsibility on the management of financial institutions, requiring them to play a central and active role in guiding and adapting the ICT risk management framework and overall digital operational resilience strategy (Recital 45 DORA).

DORA requirements are comprehensive and challenging in terms of information and IT-security. SEC Consult is one of the leading experts in all the areas mentioned in this Art and we feel confident of being able to support you in your journey towards DORA compliance.