An article on the Digital Operational Resiliance Act cannot be without a quote from the cartoon character of the same name ‘Dora the explorer’. Every episode contains a recognisable event, a solution and a moral or lesson learned. The same applies to incidents that occur within an organisation. Every incident brings lessons.
‘Managing, classifying and reporting ICT-related incidents’ is the third chapter in the DORA Regulation. In this article, we elaborate on the requirements from DORA and include the draft Regulatory Standards on this topic.
Table of content
Management process for ICT-related incidents
When implementing new laws and regulations, two issues always come into play: 1) how do we ensure that we comply with the requirements imposed? And 2) how do we set up the associated processes within the organisation? For DORA’s ICT Incident Management, these two are pretty much an extension of each other, which can simplify implementation.
In summary, to properly handle an incident, an organisation needs to answer the following questions:
- What is an incident (art. 3(8) DORA)?
- How do I know that an incident has taken place? (17(3) DORA)
- What are the consequences of the incident? In other words, what is the impact (art. 18 DORA)?
- How do we mitigate the impact? And how do we do this as quickly as possible? (art. 17(3)(f) DORA)
- How can we prevent the incident from happening again? (art. 13 paragraph 2 DORA)
- How do we record an incident and to whom do we report/report the incident (art. 17(1) DORA)?
The answers to these questions constitute the management process for ICT-related incidents which DORA requires in Art. 17(1). The second paragraph requires financial entities to record their ICT incidents and significant cyber threats. Paragraph 3 of the same article articulates the objective of the ICT management process. This prescribes that the ICT management process must include the following items:
1. Indicators for early detection;
2. Underlying procedure to identify, detect, categorise and classify incidents;
3. Clear arrangements for handling different (standard) incident types;
4. Various (communication) plans for:
- Communication towards staff, external stakeholders and media;
- Communications to clients;
- Internal escalation, including complaints;
- Financial entities acting as counterparties (if necessary);
5. A procedure for reporting (serious) incidents to (senior) management, including effects/impact, response and additional mitigating controls;
6. A response procedure to minimise the negative effects of an incident and resume services as soon as possible.
Together, these steps provide an adequate process to handle an ICT incident. Still, there are some question marks. For instance, the classification requirement from Article 17(1)(b) is elaborated in Article 18 of DORA and the obligation to notify competent authorities, such as an AFM or DNB, is regulated in Article 19. For both of these articles, a draft technical standard (RTS or a ‘Regulatory Technical Standard’) was published in June 2023 that provides further, more detailed elaboration.
Classification of an ICT-related incident or cyber threat
To prioritise an incident, it should be classified as soon as possible. For example, if it involves problems logging in due to incorrect password , the incident will be rated ‘low’ (if it falls within the definition of ICT-related incident at all, this depends on the cause). However, if several staff members can no longer log in at the same time, then there may be more to it and urgency is required. A classification of serious (‘major’) is appropriate here, and so adequate response is required.
To classify these incidents, DORA gives seven criteria in Art 18, and in addition, the RTS also proposes a ‘threshold’ or threshold value for the ‘serious/major’ category.
The primary criteria are:
- Clients, financial counterparts and transactions affected’
- ‘Data losses’
- . ‘Duration and service downtime’
And the secondary criteria are:
- ‘Reputational impact’
- Geographical spread
- Critical services affected
- Economic impact’.
The reason the RTS distinguishes between primary and secondary criteria is so that these two types of criteria can be considered differently when assessing an incident. A serious incident occurs once the following conditions are met:
- The threshold values (“thresholds”) of two primary criteria are exceeded; or
- The thresholds of three or more criteria have been exceeded, including one primary criterion.
Schematically, this looks as follows:
Source: DORA draft RTS
Getting started with ICT-related incident management
Recently, the draft RTS was consulted to the market. Various parties, such as the Pension Federation and industry association Dufas, provided feedback to the European Supervisory Authorities. Among others, on the calculation of the thresholds that can qualify an incident as significant. But even though we may not all agree with the proposed thresholds or the method of classification, we will all recognise that classification does need to take place in the interests of adequate incident management.
Our advice is therefore not to wait to set up ICT-related incident management, but to take the following steps:
- Inventory and register your IT-assets and determine your critical processes and -IT components and applications (art. 8(4) DORA);
- Check what available mechanisms or tooling you can deploy to detect anomaly activities as soon as possible (art. 10 and 17(3)(a) DORA) and whether this is sufficient;
- Check whether your response and recovery measures are adequate (art. 11 DORA);
- Ensure an adequately designed incident management process (art. 17 DORA and including classification of incidents, art. 18 DORA); and
- Know how and when to report significant incidents to the regulator (art. 19 DORA).
Reporting of serious ICT-related incidents
Serious incidents must be reported to the competent authorities, or regulator. The format in which to report the timelines within which this must be done are regulated in an RTS based on art. 20 of DORA. This RTS will be published no later than 17 July 2024. It will then be submitted to the European Commission. In any case, it can be inferred from Article 19 that it involves:
- An initial notification;
- An interim report once the status of the incident has changed significantly;
- A final report once the root cause analysis has been completed and the actual impact figures are known.
For many licensed parties, it will apply that incident handling, especially for serious/significant incidents, is done by an external service provider or an external specialist. Think, for example, in the case of a ransom-ware attack. It is therefore permissible for the reports from the list above to be made by a third party.
The moral of the story
Every incident has a cause. And this cause you hope to avoid in the future. So it is important to analyse the incident afterwards so that you can find a cause and learn from it. This is what the post-incident evaluations from Article 13(2) DORA are for, which must be carried out after disruption of the organisation’s core activities due to a serious/significant incident. And again: document, record the analysis, define improvement actions and monitor progress!
Even if you have outsourced the entire IT-landscape, it is advisable to inquire about ‘incident handling procedures’ and periodic incident reports. Various seemingly unrelated small incidents can indeed have a larger underlying cause and can be seen as “recurring incidents”.They may still be classified as ‘serious’ according to Art. 16 of the draft RTS the moment they exceed the thresholds of the criteria on an aggregated level, over a three-month period. So pay attention to the little ones!
Want to know more?
Do you have questions about DORA, or need help preparing? Feel free to contact us for support.
Want to learn more about DORA requirements for financial entities at your own pace? Our DORA Awareness e-learning will guide you through this new law. The training covers ICT-risk management, dealing with ICT incidents, testing digital operational resilience and managing ICT-risk third-party providers, among other topics.
