With the Digital Operational Resilience Act (DORA), a number of new obligations will become applicable to most financial institutions. In this update we will highlight the rules proposed by the ESAs in the draft RTS with regard to the criteria for classifying ICT-related incidents and the materiality thresholds to determining major ICT-related incident that should be reported to the competent authority.

Although DORA will apply from 17 January 2025, financial institutions are advised to already take measures to ensure timely compliance. Amongst others, establishing a process for detecting and handling ICT-related incidents, aligned with the criteria and materiality thresholds outlined by the ESAs, is of importance for timely compliance.

In our earlier blog about DORA we set out the new obligations for financial entities (FEs) as defined under DORA. As detailed in this previous blog, amongst others FEs will be required to define, establish and implement an ICT-related incident management process to detect, manage and notify such incidents.

DORA defines an ICT-related incident as a single event or series of linked events unplanned by the FE that compromises the security of network and information systems, and has an adverse impact on the availability, authenticity, integrity, or confidentiality of data, or on the services provided by the FE. If such an ICT-related incident occurs, DORA requires that the FE involved must have procedures which ensure that root causes are identified, documented, and addressed to prevent re-occurrence. In addition, FE's must classify and determine the impact of ICT-related incidents and, if classified as a major incident, report the incident to the relevant competent authority.

In order to be complete. Currently, certain financial institutions are already subject to incident reporting obligations under the Dutch Act of Financial Supervision (AFS) and/or the General Data Protection Regulation (GDPR) or national GDPR Implementation Laws that may require reporting of ICT-related incidents to a certain authority, or provide exemptions to certain (conflicting) reporting requirements. While DORA stipulates that it is essential to harmonise the ICT-related incident reporting regime, it has not yet been determined by the Dutch regulator and/or supervisors how to deal with multiple reporting obligations that may arise if DORA becomes applicable, potentially resulting in multiple reporting obligations that apply to the same major ICT-related incident. However, the explanatory notes to the Draft bill to implement the Amending Directive as regards Digital Operational Resilience for the financial sector suggest that the Dutch legislator intends to make changes to the current incident reporting obligations for certain payment service providers.

The draft RTS, recently published by the three European Supervisory Authorities (EBA, EIOPA, and ESMA, the ESAs), further specifies the criteria for classifying ICT-related incidents, including materiality thresholds that trigger reporting obligations. In addition, the Dutch Authority of Financial Markets (AFM) and the Dutch Central Bank (DNB) both have recently pointed out the importance for FEs to start as early as possible with preparing for DORA (link to AFM and link to DNB). When the last package of RTS and ITS is released (expected in the summer of 2024), financial institutions will have less than six months to fully implement all DORA requirements. Therefore, early preparation is vital for financial institutions to ensure compliance with DORA and its Level 2 and Level 3 legislation. Q&As and good practice guidelines published by both national and European supervisory authorities can aid financial institutions in their compliance with DORA.

Amongst others, the AFM recommends FEs to start preparing their process for detecting and handling ICT-related incidents and maintaining a record of past ICT-related incidents. Integrating the criteria and materiality thresholds as proposed in the (draft) RTS will be essential to align with these requirements effectively.

We will discuss the specification of the different criteria, including their materiality threshold(s), below.

Classification on major incidents

The ESAs have categorized the different criteria into primary and secondary ones, based on the fact that the primary criteria have more dependencies with other criteria. According to the ESAs, an incident should be classified as major if either:

  • the classification thresholds of two primary criteria have been met; or
  • the classification thresholds of three or more criteria (primary and secondary) specified have been met, including at least one primary criterion.

The ESAs propose that there are three primary criteria (namely, 'Clients, financial counterparts and transactions affected', 'Data losses' and 'Critical services affected') and four secondary criteria (namely, 'Reputational impact', 'Duration and service downtime', 'Geographical spread', and 'Economic impact'). Their specifications and materiality thresholds as proposed by the ESAs are set out below.

Recurring incidents

The ESAs propose that multiple non-major incidents, that are connected in terms of root cause, nature, impact, and service concerned, could qualify as a major ICT-related incident if in aggregate they meet the classification criteria and materiality thresholds in the preceding three months.

FEs are therefore well advised to not merely focus on incidents that individually meet the thresholds for a major incident. They should also focus on those incidents that are less significant individually, but in connection with other incidents that occur in a similar manner with similar root cause and nature meet the threshold for a major incident. Needless to say, such monitoring should be part of every FE's information and cyber security hygiene.

This means that for FEs the registration of both significant and less significant incidents will become of importance, whereby the various incidents must also be compared and related to each other. In this regard, it is also highly encouraged by the AFM to provide opportunities for root cause analyses and potential evaluation of processes. Especially with 'Software-as-a-Service' (SaaS), the FE is already dependent on the supplier to perform the root cause analysis and provide the relevant information relating to a security breach that impacts personal data. Under DORA the importance and necessity of such collaboration will greatly increase as the scope for the FE to report will broaden further. Consequently, contractual arrangements on the use of ICT services provided by third parties should thus be adjusted and strengthened accordingly to allow the FE to remain fully in control.

Primary criteria

Impact on clients, financial counterparts and transactions

The ESAs propose to treat the 'number of clients', 'number of financial counterparts', 'relevance of clients or financial counterparts' and 'amount or number of transactions' as alternative triggers for incident reporting. Therefore, the materiality threshold of this criteria is met if one of the following applies:

  • 10% of all clients or 50,000 clients are affected by the incident.
  • 10% of all financial counterparts are affected by the incident.
  • 10% volume of all transactions, or a minimum value of €15,000,000 of transactions are affected by the incident.
  • The FE decides that relevant clients and/or financial counterpart have been affected by the incident.

The ESAs specified that the 'number of clients affected' captures all affected clients (natural persons or legal persons) that make use of the services provided by the FE, where the ESAs consider the client to be the ultimate beneficiaries of the service. The term 'number of financial counterparts affected' captures all affected financial counterparts that have concluded a contractual arrangement with the FE. For the 'number of transactions affected' the FE should consider all transactions containing a monetary amount, where at least one part of the transaction was carried out within the EU. For the relevance of a client or financial counterpart the FE shall take into account the extent to which the impact on the client and/or financial counterpart will affect the implementation of the business objectives of the FE, as well as the potential impact of the incident on market efficiency overall. The ESAs further specified that if the actual numbers of clients, financial counterparts and/or transactions affected cannot be determined (since this may be challenging at times) FEs shall use estimates based on available data from comparable reference periods.

Impact on data losses

According to DORA, FEs have to assess the impact of an ICT-related incident on data losses in relation to availability-, authenticity-, integrity- and confidentiality on data. The ESAs propose a description related to all these properties based on terms used by the European Union Agency for Cybersecurity (ENISA) and available international standards. Therefore, to determine the data losses of the incident, FEs shall consider whether the incident:

  • has rendered the data on demand by the FE, its clients or its counterparts inaccessible or unusable (in relation to availability of data);
  • has compromised the trustworthiness and reliability of data or their source (in relation to authenticity of data);
  • has resulted in non-authorised modification of data that has rendered it inaccurate or incomplete (in relation to integrity of data); or
  • has resulted in data having been accessed by or disclosed to unauthorized parties or systems (in relation to the confidentiality of data).

The ESAs propose the materiality threshold for this criterion to be met if the incident has entailed (i) any loss of critical data related to availability, authenticity, integrity or confidentiality determined based on the beforementioned description as stated in the (draft) RTS which (ii) would have an adverse impact on the implementation of the business objectives of the FE or the meeting of regulatory obligations in order to meet the materiality threshold.

Critical services affected

The ESAs suggest that FEs should determine that an ICT-related incident has affected critical services if the incident has affected either services or activities that require authorisation, or ICT services that support critical or important functions of the FE. To avoid significant overreporting and to ensure that only incidents with high adverse impact are categorized as major, the ESAs in addition consider the materiality threshold only to be met if the incident has been escalated by the FE to its senior management or management body.

Secondary criteria

Reputational impact

The ESAs arrive at the view that FEs should take into account the level of visibility the incident has gained as an indicator of potential reputational impact. The draft RTS specifies that the threshold for reputational impact is considered to be met if either the incident has attracted media attention, the FE has received complaints from different clients or financial counterparts, the FE will not be able to or is likely not to be able to meet regulatory requirements or the FE is likely to lose clients or financial counterparts with an impact on its business as a result of the incident.

Duration and service downtime

The ESAs describe that both the duration of an incident and the service downtime should be able to trigger this classification criterion. Therefore, they propose that the threshold for this criterion is met if either the duration of the incident is longer than 24 hours or the service downtime is longer than 2 hours for ICT services supporting critical functions. If the FE does not know when the incident has occurred or when the service downtime has started, the FE should calculate the occurrence of the incident or the start of the service downtime from the earlier between the moment it was detected and the moment when it has been recorded at a network/system level.

Economic impact

The ESAs propose that this materiality threshold is met if the sum of the gross direct and indirect costs and losses incurred as a result of the incident exceeded or are likely to exceed EUR 100,000. The ESAs noted that this identical criterion under the Guidelines on major incident reporting under PSD2 was generally perceived by the industry as too complex. Therefore, the ESAs prescribed in the draft RTS in more detail the types of direct and indirect gross costs and losses incurred because of the incident that the FE should and should not take into account for the purpose of determining the economic impact.

Geographical spread

The ESAs are of the view that due to the different size of Member States, the potential complexity for FEs having to carry out the required assessment and that it may add a disproportionate reporting burden, the criterion does not include an assessment of the geographical spread within a single Member State. Instead, the materiality threshold will be met if the incident has had a material impact in two or more Member States. Whether the incident has had a material impact in a Member State, should be determined by the FEs own assessment of the significance of the impact of the incident in the concerned Member State's territory, including on the affected clients and financial counterparts, branches or subsidiaries within a group, and financial market infrastructures or third party providers that may be shared with other FEs.

Conclusion

As described, one of the consequences of DORA is that FEs should establish procedures to identify, track, log, categorise and classify ICT-related incidents in accordance with the abovementioned criteria. Besides, FEs should have procedures in place to notify the competent authorities about major incidents, which should be determined based on the beforementioned thresholds. FEs should embed these procedures in their standing practice, either in their existing or newly DORA dedicated compliance framework. The fact that recurring incidents could also lead to a major incident further points out and emphasizes the importance of the procedures that FEs should establish to log and review ICT-related incidents and implement root cause analyses. Contractual arrangements on the use of ICT services provided by third parties should be reviewed and amended to ensure that the scope of the suppliers cooperation obligation is expanded ensuring that required root cause analysis is performed and that FEs are provided with the relevant information and cooperation required to comply with DORA, or any other regulatory requirements, in this regard.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.