Understanding DORA: an overview of the requirements in the new final draft RTS on the ICT risk management framework for financial entities

Home
Knowledge
Understanding DORA: an overview of the requirements in the new final draft RTS on the ICT risk management framework for financial entities

Understanding DORA: an overview of the requirements in the new final draft RTS on the ICT risk management framework for financial entities

{3C7EA529-5767-4F87-BAC7-171AD63D99FA}

March 14, 2024

On the 17th of January 2024, the European Supervisory Authorities EBA, ESMA and EIOPA (the ESAs) published a set of four new final draft regulatory technical standards (RTS) on regulation (EU) 2022/2554; the Digital Operational Resilience Act (DORA). It concerns:

RTS on criteria for the classification of ICT-related incidents and threats;
RTS on ICT risk management framework and on simplified ICT risk management framework;
RTS to specify the policy on ICT services supporting critical or important functions provided by ICT third-party service providers (TPPs); and
RTS to establish the templates for the register of information.

In this blog, we provide a key points summary of each draft RTS and we visualize the classification of a ‘major incident’ and a ‘significant cyber threat’.

1. RTS on classification as a ‘major incident’ and ‘significant cyber threat’

DORA distinguishes ‘major ICT-related incidents’ and ‘major operational or security payment-related incidents’ (major incidents). According to Article 3 (definitions) DORA, a ‘major ICT-related incident’ is an ICT-related incident that has a high adverse impact on the network and information systems that support critical or important functions of the financial entity, and a‘major operational or security payment-related incident’ is an operational or security payment-related incident that has a high adverse impact on the payment-related services provided.

According to Article 19 (1) of DORA, a financial entity must report so called ‘major ICT-related incidents’ to the national competent authorities. Articles 18 and 19 of DORA also cover the reporting of major operational or security payment-related incidents.

The RTS on classification as a ‘major incident’ and ‘significant cyber threat’ contains among other things the requirements to determine the criticality of an incident.

Below, the steps to determine if an incident qualifies as ‘major’ according to the new RTS are visualized.

Figure 1

As for Step 2, to determine whether the incident is affecting ‘critical services’ it is important to assess whether the incident:

affects ICT services or Network and information systems that support ‘critical or important functions’¹ of the financial entity; or
affects financial services that require authorisation, registration or are otherwise supervised by competent authorities; or
represents a successful, malicious and unauthorised access to the network and information systems of the financial entity.

As for Step 3, Data Loss is triggered as soon as there is a successful unauthorised and malicious access, irrespective of whether the data has been exploited or not. If there has not been a successful unauthorised and malicious access, the financial entity should look at the other Data Loss criteria from Step 4.

As for Step 4, to determine if at least two ‘Other Criteria’ are met, the following thresholds or criteria per category are relevant:


Category	Thresholds or criteria
Client, financial counterparts and transactions	>10% of all clients using the affected service (unable to make use of the service or adversely impacted by incident); >100 000 clients using the affected service (unable to make use of the service or adversely impacted by incident); >30% of all financial counterparts (financial counterparts with contractual arrangements with the FE) used by the FE; >10% of the daily average number of transactions; >10% of the daily average amount of transactions; any identified impact on clients or financial counterpart identified by the FE as relevant.
Reputational impact	incident reflected in the media; or received repetitive complaints; or inability to meet regulatory requirements; or likely loss of clients or financial counterparts with a material impact on FE’s business.
Duration and service downtime	incident duration is longer than 24 hours (measured from the moment an incident occurs or is detected, until it is resolved (estimate if not yet known) or; service downtime is longer than 2 hours for ICT services that support critical or important functions (measured from the moment service fully/ partially unavailable/ delayed to clients, financial counterparts or other internal or external users, until activities are restored to the same level before the incident).
Geographical spread	Any impact of the incident identified in the territories of at least two Member States Assess significant impact of the incident in other EU Member States on: clients or financial counterparts; branches of the FE or other group financial entities; financial market infrastructures or third-party providers that may affect other FEs.
Data losses	availability of data: data on demand rendered temporarily or permanently inaccessible or unusable; authenticity of data: compromised trustworthiness of the source of data; integrity of data: data inaccurate or incomplete due to unauthorised modification; confidentiality of data: data being accessed by or disclosed to unauthorised party or system. any successful, malicious and unauthorised access occurs to network and information systems not covered by the above items a - d, which may result to data losses.
Economic impact	Costs and losses incurred by the FE exceed or are likely to exceed €100 thousand (based on available data at time of reporting); Types of direct and indirect incurred costs; expropriated funds or financial assets liability, including theft; replacement or relocation costs; staff costs; contract non-compliance fees; customer redress and compensation costs; forgone revenues; communication costs; advisory costs.

In conclusion, if the incident affects critical or important services and (i) the incident constitutes any malicious unauthorised access to network and security systems or (ii) at least two of the ‘Other Criteria’ are met, the incident classifies as ‘major’ and the financial entity should report accordingly to the competent authorities.

Furthermore, according to Article 19 (2) DORA a financial entity may, on a voluntary basis, notify a significant cyber security threat. According to the draft RTS, the following steps are relevant to classify a cyber threat as ‘significant’.

Figure 2

As for Step 3, the financial entities should take the following criteria into account when determining the probability of materialisation of the risk:

applicable risks related to the cyber threat, including potential vulnerabilities of the systems of the financial entity that can be exploited;
the capabilities and intent of threat actors to the extent known by the financial entity; and
the persistence of the threat and any accrued knowledge about incidents that have impacted the financial entity or its third-party provider, clients or financial counterparts.

As for Step 4, in contrast to the qualification of a ‘major incident’ from Figure 1, it is sufficient if the threat has met one of the ‘Other Criteria’.

2. RTS on ICT risk management framework and on simplified ICT risk management framework

The final draft RTS on ICT risk management framework and on simplified ICT risk management framework identifies elements related to ICT risk management and harmonizes ICT risk management tools, methods, processes and policies for different types of financial entities. ICT risk management encompasses the detection and managing of risks related to the usage of ICT. Because of the diverse operational structures and existing risk management frameworks, financial entities benefit from a certain proportionality in the way they should draft policies and reports according to DORA.

Accordingly, the first title of the RTS provides the general principle that when defining and implementing the requirements from DORA, financial entities should apply the requirements defined in DORA and the RTS in a proportionate manner in relation to the increased or reduced elements of complexity or the overall risk profile.

The second title of the RTS provides requirements for ICT risk management tools, methods and processes and policies as a specification of Article 15 DORA. This includes requirements on ICT risk and assets management policies, encryption and security policies, policies on management of incidents, logging and performance and policies on human resources and business continuity management.

According to Article 16 DORA, a simplified DORA regime may apply on small and non-interconnected investment firms, payment institutions that are exempted from PSD2, certain institutions that are exempted from CRD, electronic money institutions that are exempted from EMD2 and small institutions for occupational retirement provision.

The third title of the RTS provides the requirements applicable to this simplified ICT risk management framework as mentioned in Article 16 DORA, which includes (i) the governance requirements and the overall responsibility of the management body for ICT risk management, (ii) the implementation of information security policy and measures, (iii) specific elements relating to the ICT risk management framework, (iv) security and access safeguards, (v) ICT business continuity management and (vi) requirements on the review report.

3. RTS on ICT Third-Party Risk Management

The RTS on ICT Third-Party Risk Management emphasizes a structured approach with managing ICT risks when the financial entity is using third-party service providers that support critical or important functions: Critical ICT Third-Party Providers (CTTPs).

In line with Article 28(2) DORA, financial entities should draft a policy on the use of ICT services supporting critical or important functions provided by third-party service providers. The requirements on the policy for CTTPs may overlap with existing ‘outsourcing’ requirements under the Dutch Financial Supervision Act.

Financial entities must adopt a written policy on utilizing ICT services that support critical or important functions. Some of these aspects in the policies or contractual arrangement are already required due to existing outsourcing legislation, other requirements are new and specified to ICT-services. According to DORA and the RTS, an ICT-policy should entail the following aspects:

Aspects	Descriptions	Examples of requirements
Governance	Assignment of responsibilities for managing and the overall responsibility of the management body.	Document on contractual arrangements Define role of senior management Annual review of ICT policy by management body Consistency with internal risk management framework
Life management	Processes for each lifecycle phase, from planning to exit strategies.	Management should be involved in ICT policy decision-making throughout lifecycle.
Risk assessment	Risk assessment before entering contractual arrangements.	Assess operational, ICT, legal and reputational risks.
Due diligence	Assessment of prospective ICT service providers.	Assess providers' reputation, resources, information security, and ethical practices.
Conflict of interests	Addressing potential conflicts of interest with ICT service providers.	Outline methods for dealing with potential conflicts of interest.
Contractual clauses	Inclusion of specific clauses in contracts with ICT service providers.	Include clauses for access, inspection, audit, and testing rights.
Monitoring	Ensuring performance and quality standards of ICT service providers align with policies.	Monitor the performance and quality standards of ICT service providers to ensure alignment with the financial entity's policies.

4. RTS on Register of information

In addition to policy and operational requirements as set-out above, Article 28(3) of DORA requires financial entities, as part of their ICT risk management framework, to register information in relation to contractual arrangements related to the use of ICT services provided by third parties. This register could be (partly) requested by the competent authorities.

The RTS on Register of information provides a description of the templates and template-specific instructions for this register, aiming to guide financial entities in capturing the essential information on contractual arrangements and ICT service supply chains.

As for some of the above policy aspects, the registering of contractual arrangements related to outsourcing is a familiar concept for some of the financial entities, i.e. banks and insurers. The ESAs have acknowledged the necessity to avoid double-reporting and will further discuss this point. It has to be noted that these existing register requirements do not match completely with the requirements from DORA.

To reduce some of the administrative burden, financial entities could make a register on consolidated or sub-consolidated level.

If you have questions about DORA, please feel free to reach out to our team!

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