DORA Update 4: Managing, Classifying, and Reporting ICT-Related Incidents

SUPERVISION DORA UPDATE 4 Getting started with DORA: Management, classification and reporting of ICT-related incidents

In brief This is the fourth edition in a series of AFM publications on the Digital Operational Resilience Act (DORA). This series is intended for all undertakings that must comply with the European regulation from 2025. In this edition, we focus on ICT-related incidents. In this way, undertakings can analyze where they stand in this area and what steps they may still need to take to comply with the regulation.

1. ICT-related incidents in DORA 1 https://www.esma.europa.eu/sites/default/files/2023-06/CP_-_Draft_RTSs_ICT_risk_management_tools_methods_processes_and_policies.pdf 2 https://www.esma.europa.eu/sites/default/files/2024-01/JC_2023_83_-_Final_Report_on_draft_RTS_on_classification_of_major_incidents_and_significant_cyber_threats.pdf 3 For reference for investment firms and managers of investment institutions, see also https://www.afm.nl/nl-nl/sector/actueel/2023/mei/deep-dive-incidenten-bo

DORA aims for financial institutions to better manage ICT risks and thereby become more resilient against cyber threats and ICT disruptions. To this end, the regulation describes various requirements in the field of ICT, including for ICT-related incidents. Undertakings can already analyze whether they meet the DORA requirements on this point to then take action (if necessary). To comply with DORA by January 17, 2025, it is necessary to start implementation now.

To limit the effects of ICT-related incidents, it is important that they are adequately detected and handled. The requirements for the management of ICT incidents and cyber threats are described in the regulation in Article 17 (Chapter III). In addition, part of the requirements regarding the detection of incidents and the response thereto are elaborated in Chapter 3 (Articles 23 and 24) of the Regulatory Technical Standard (RTS) for ICT risk management1.

As part of the management process, undertakings must classify their ICT incidents in a consistent manner so that they can be carefully followed up and handled. The regulation (Article 18) describes how undertakings must classify ICT incidents and by what criteria they can determine the impact of the incident. These criteria are further explained in the RTS2. In addition, this technical standard explains when ICT incidents or cyber threats are classified as serious (major) or significant.

Undertakings must also ensure that all ICT incidents that have occurred are registered. This gives them the opportunity to evaluate incidents and perform analyses to determine the cause of the incident. DORA stipulates that major ICT incidents must be reported to the supervisor (this is currently already mandatory for incidents that pose a serious threat to sound business operations3). The regulation contains general requirements that these reports must meet. For example, Article 19 describes which reports must be shared with the supervisor and when customers of the financial entity must be informed of the incident. The RTS and Implementing Technical Standard (ITS)4 describe in detail what undertakings must include in the reports. This also includes a template that can be used for reporting major incidents. In this publication, we have based our information on the RTS/ITS published at the time of writing. Since the content of these RTS/ITS is not yet final, changes may still occur, although we often see that the content remains largely the same.

In the following sections, we will focus on the management and classification of ICT incidents and cyber threats and what organizations can already do to comply with DORA requirements. We will also briefly discuss how undertakings can report ICT incidents and cyber threats to the AFM.

4 JC_2023_70_-_CP_on_draft_RTS_and_ITS_on_major_incident_reporting_under_DORA.pdf (europa.eu)

Table 1

Additional elaborations	Subject	Completed
RTS for Article 15	Further harmonisation of ICT risk management tools, methods, processes and policies	Already sent to EC
RTS for Article 18(3)	Classification of ICT related incidents and cyber threats	Already sent to EC
RTS for Article 20(a)	Reporting content and templates	By July 17, 2024
ITS for Article 20(b)	ITS to establish the reporting details for major ICT related incidents	By July 17, 2024

2. Getting started with ICT incidents Management of ICT incidents Undertakings can already start with:

• Establishing and implementing a management process for ICT-related incidents.

Article 17 of the regulation describes the requirements for the ICT incident management process. The management process helps undertakings to adequately detect, report, and handle ICT incidents. To minimize the impact of these incidents, organizations must establish and implement appropriate policies and procedures. Chapter III (Articles 22 and 23) of the RTS for ICT risk management further explains what institutions must include in their ICT incident policy and what mechanisms they must implement to detect and respond to incidents.

The ICT incident policy must enable the undertaking to implement technical, organizational, and operational mechanisms that support the ICT incident management process, such as techniques needed to identify anomalous activities and behavior. In addition, undertakings must specify in the ICT incident policy which employees and (external) stakeholders are directly involved in the security of ICT systems. This includes individuals responsible for detecting and monitoring cyber threats, anomalous activities, and for vulnerability management. For significant or recurring ICT incidents, undertakings must establish processes and methods to analyze them.

The ICT incident management process ensures that all ICT incidents are registered and consistently monitored, handled, and followed up. This allows underlying causes to be identified, documented, and resolved. By setting this up correctly, organizations can minimize the chance of an incident recurring. Another goal of the management process is to draw up plans for communication with their own personnel, external stakeholders, and the media, in accordance with the communication policy (see also Article 14 of the regulation) and to ensure that serious ICT incidents are reported to the relevant senior management.

To effectively detect and respond to ICT incidents and anomalies, it is important that roles and responsibilities in this area are clearly defined and communicated within the organization. In addition, institutions must implement detection mechanisms that enable them to:

• collect, monitor, and analyze internal and external factors, including information from system logging;
• collect, monitor, and analyze potential internal and external cyber threats, including common scenarios;
• collect, monitor, and analyze information about ICT incidents from third parties;
• identify anomalous activities and behavior and implement tools for generating alerts for anomalies;
• record, analyze, and evaluate relevant information about all anomalous activities.

Since incident reports contain important (and often confidential) information, it is important that these and other relevant information about the incident are stored securely and cannot be modified without authorization. In addition, the most important information about the incident, such as the date and time of the anomaly and the type of incident, must be recorded in a log file. Finally, the ICT incident procedure must be initiated when there are indications of unauthorized activities on an ICT system or network or when there are indications that an ICT system or network is no longer secure. Other cases where the ICT incident procedure must be followed include data loss and when systems or networks are unavailable. The importance of the affected services must be taken into account here.

Classification of ICT incidents Undertakings can already start with:

• Establishing (and implementing) procedures describing how incidents are classified.

For an effective management process, it is important that ICT incidents and cyber threats are correctly classified. This helps undertakings in determining the resources needed to resolve the incident. It also helps to communicate the status and expectations to stakeholders within the organization. For classification, institutions can determine how they categorize incidents. However, a distinction must be made between serious (major) incidents, cyber threats, and all other incidents (low impact, medium impact, etc.).

For classifying ICT incidents, undertakings must use a number of criteria that help determine the impact of the incident on the organization and external stakeholders. These criteria are:

• The number and relevance of customers affected by the incident. This refers to customers who use the undertaking's services or financial counterparties with whom the undertaking has a contractual agreement. In addition, undertakings must determine the extent to which the impact of the incident affecting the customer also affects the objectives of their own undertaking. Finally, the relevance of the customer is determined by looking at the customer's effect on the institution's ability to achieve its objectives;
• The loss of data as a result of the incident. For this, undertakings must determine whether data is still accessible (availability), whether the data is incorrect or incomplete (integrity), and whether the data has been accessed or disclosed by unauthorized users (confidentiality);
• The extent to which the affected services can be considered crucial for the undertaking. This is the case when the incident has affected ICT services that support important or critical business functions;
• The reputational damage caused by the incident. To determine reputational damage, undertakings look at how much attention the incident has received in the market. This may include investigating whether the incident has been reported in the media, whether complaints have been received from customers, or whether the undertaking cannot comply with legal requirements as a result of the incident;
• The duration of the incident. To determine this, the undertaking measures the time between when the incident occurs and when it is resolved. If the start time cannot be determined, the undertaking can use the moment it was identified or when it was recorded in log files or other data sources. If the exact resolution time is unknown, institutions may make an estimate to determine the end of the incident;
• The geographical spread of the areas affected by the incident. To determine the geographical spread, institutions assess, among other things, the impact of the incident on customers, other offices, or institutions within the group in at least two EU Member States;
• The economic effects of the incident in absolute and relative terms. This concerns direct and indirect costs and losses as a result of the incident.

If one or more of the criteria cannot be determined with certainty, an estimate must be made using the available data.

To determine whether it is a serious (major) incident, the undertaking must look at the criteria on which the incident has had a material impact. The first step is to determine whether the critical services of the undertaking are affected. If this is not the case, there is no serious incident. If the critical services are affected, the incident must be classified as serious if there has been unauthorized access to network and information systems, which could lead to data loss. In addition, an incident must be classified as serious if it has had a material impact on two or more of the above criteria. The explanation of when the impact is material is further explained per criterion in the RTS5.

When ICT incidents recur more frequently but are not individually classified as serious, they can still be classified as serious if they occur more than twice in a three-month period, have the same cause, and a similar impact.

For cyber threats, they can be considered significant if the threat affects the critical or important business functions of the undertaking, other financial institutions, third parties, or customers. In addition, there must be a high probability that the cyber threat will actually materialize. Finally, the cyber threat must have a material impact on the criteria in the list above if the threat materializes. If the cyber threat meets all conditions, it must be classified as significant.

Table 2

Additional elaborations	Description	Completed
RTS for Article 18(3)	Classification of ICT related incidents and cyber threats	Already sent to EC

5 https://www.esma.europa.eu/sites/default/files/2024-01/JC_2023_83_-_Final_Report_on_draft_RTS_on_classification_of_major_incidents_and_significant_cyber_threats.pdf

Reporting of serious ICT incidents and significant cyber threats Undertakings can already start with:

• Making preparations to be able to report serious ICT incidents in a timely manner.

When an ICT incident is classified as serious (major), it must be reported to the supervisor. Based on the report, the supervisor can take appropriate follow-up actions and prevent the incident from having a negative impact on the rest of the sector. In the event that the incident also affects the financial interests of their customers, undertakings must inform them of this. They must also indicate what measures have been taken to limit the negative effects of the incident. In addition to the mandatory reporting of ICT incidents, undertakings also have the option to voluntarily report significant cyber threats to the supervisor. They can do this if they believe that the threat is relevant to the rest of the financial sector, users of financial services, or their customers. The requirements for reporting ICT incidents and cyber threats are set out in Article 19 of the regulation and the RTS/ITS for incident reporting (Articles 20(a) and 20(b)). These also describe what institutions must include in the incident report.

First notification As soon as an undertaking determines (based on the criteria in the previous chapter) that a major ICT incident has occurred, a first notification must be shared with the supervisor. For this, institutions have 4 hours from the moment the incident is classified as serious, but this may not be longer than 24 hours after the incident was detected. In the first notification, undertakings record general information about the incident, such as the description of the incident, when the incident was detected, and the classification of the incident (including the assessment of the aforementioned criteria). Furthermore, it is important that the undertaking states how the incident was discovered, whether the incident recurs frequently, and what the cause of the incident is. If possible, the institution also indicates whether the business continuity plan has been activated as a result of the incident and whether the incident has had an impact on other financial institutions and third parties.

Interim report After the first notification, institutions must also submit an interim report to the supervisor for serious ICT incidents. The interim report must be submitted within 72 hours after the classification of the incident or as soon as normal activities have been restored. As in the first notification, undertakings must state when the incident was identified and on the basis of which criteria it was determined to be a major incident. In addition, the undertaking describes the type of incident and provides information about the affected parts of the organization, such as business processes and infrastructure components. Furthermore, the interim report must indicate whether the incident has been communicated to customers and what temporary measures the undertaking has taken to recover from the incident. Finally, it is important that institutions indicate what the consequences of the incident are. For this, undertakings must check whether vulnerabilities have been exploited and whether there is an indication that IT systems or IT infrastructure can no longer be used securely.

Final report No later than one month after the classification of the incident, the undertaking must share a final report with the supervisor. If the incident has not yet been resolved at that time, the final report must be submitted no later than one day after the incident has been definitively resolved. The final report contains the date when the incident was resolved, information about the cause of the incident, and information about the undertaking's inability to comply with legal requirements and contractual agreements/SLAs (if applicable). The final report must also describe what measures the undertaking has taken to resolve the incident and to prevent it from recurring. Furthermore, it is important that the undertaking provides information about the direct and indirect costs incurred as a result of the incident.

6 https://portaal.afm.nl/

Reporting significant cyber threats In addition to the (mandatory) reporting of major ICT incidents, institutions also have the option to voluntarily report significant cyber threats to the supervisor. If they choose to report this, it is important that the most important information about the cyber threat is shared with the supervisor. This information consists of the date on which the threat was identified, a description of the cyber threat, and the status of the cyber threat. In addition, it is important that the institution states the potential impact of the threat on the institution and indicates what actions have been taken to prevent the threat from materializing. In the event that customers may be affected by the cyber threat, undertakings are obliged to inform them of appropriate protective measures they can take.

The AFM is currently developing an online environment where institutions can report their ICT-related incidents and identified cyber threats. This online environment will be part of the AFM Portal6 (to which supervised institutions have access). Institutions falling under DORA and supervised by the AFM will be able to submit reports on outsourcing, significant ICT incidents, and cyber threats in the AFM Portal from January 17, 2025. For ICT-related incidents, institutions can share the first notification with the AFM via the portal. As soon as the first notification has been shared, the incident will appear in the overview with all previous reports from the institution. The interim report and the final report will then be automatically linked to the incident as soon as the institution submits the necessary documents. Finally, the portal will display an overview of outstanding actions. If additional documents need to be submitted, the organization will receive a notification.

Table 3

Additional elaborations	Description	Completed
RTS for Article 20(a)	Reporting content and templates	By July 17, 2024
ITS for Article 20(b)	ITS to establish the reporting details for major ICT related incidents	By July 17, 2024

3. Outlook Currently, both the first and second batches of RTSs and ITSs have been published. The first batch (including that for Article 18(1)) has already been submitted to the European Commission, which will assess it and make a decision on it in July 2024. The second batch has been submitted by the ESAs to undertakings in the financial sector for consultation. This will likely be submitted to the European Commission in the third quarter of 2024.

In the meantime, the AFM is further preparing for the implementation of DORA supervision. The next publication in this series will delve deeper into testing digital operational resilience. The next edition will be published in the third quarter of