In Episode 5 of MFSA’s Podcasts Series ‘Navigating Financial Regulation’, the speakers, Beatriz Brunelli Zimmermann and Matthew BenHamed, Analysts within the Supervisory ICT Risk and Cybersecurity function at the MFSA, delved into the requirements of Chapter III of the DORA Regulation as regards managing, classification and reporting of ICT-related incidents, particularly what financial entities must have in place as regards both pre- and post-incident phases.
Essentially, Chapter III of DORA can be classified into three, (i) management, (ii) classification, and (iii) reporting.
Management
First and foremost, as explained by Beatriz Brunelli Zimmermann, the ‘management of an incident’ refers to anything that a financial entity needs to have in place as an inherent part of its management of ICT-related entities, therefore at a pre-incident phase. In fact, according to Article 15 of DORA, “Financial entities shall establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents and shall put in place early warning indicators as alerts”.
However, Matthew BenHamed continues to add that financial entities should not just stop here. Rather, they should also test and perform simulations on these new implementation procedure systems and early warning indicators so as to ensure that the system is functioning properly and that the designated people can identify exactly what needs to be done at a time of crisis. In Mr. BenHamed’s words, “if you prepare yourself as much as you can, it will make the process at that time much easier”.
Classification
Secondly, Article 16 of DORA provides that “financial entities shall classify ICT-related incidents and shall determine their impact” based on the seven criteria provided in the Regulation, these being:
- The number of users affected;
- The duration of the incident;
- The geographical spread;
- The data losses the incident entails;
- The severity of the impact of the incident on the entity’s ICT systems;
- The criticality of the services affected; and
- The economic impact of the incident.
As explained by Ms. Brunelli Zimmermann, financial entities must then classify an ICT-related incident as either being a ‘major’ cyber threat, whereby the incident would have had a high adverse impact on the financial entity, or rather a ‘significant’ cyber threat, whereby the incident could have had a high adverse impact on the financial entity but did not. Due to the broadness of these definitions, the question remains as to how financial entities are expected to carry out this classification.
As explained above, DORA introduces a standard incident classification methodology with specific criteria, however the specific thresholds for these criteria are yet to be published. In fact, Article 16.2 of DORA mentions that the European Supervisory Authorities (the ‘ESAs’) are required to develop common draft Regulatory Technical Standards (the ‘RTSs’) in order to further specify (a) the abovementioned criteria including materiality thresholds for determining major ICT-related incidents which are subject to the reporting obligation, and (b) the criteria to be applied for the purpose of assessing the relevance of major ICT-related incidents to other Member States’ jurisdictions, and the details of reports to be shared with other competent authorities.
As Mr. BenHamed explained during the Podcast, we still do not have full visibility on such thresholds as they are still being drafted by the ESAs, having a delivery deadline between January and July 2024.
Reporting
The classification stage then leads to the third and final stage, i.e. reporting. The classification will impact the reporting basis because if the financial entity has classified the ICT-related incident as being of ‘major’ cyber threat, then reporting to the competent authority would be mandatory. On the other hand, if the financial entity has classified the ICT-related incident as being of ‘significant’ cyber threat, then reporting to the competent authority remains voluntary however the financial entity must keep an internal record of these incidents nonetheless.
Essentially, Article 17 of DORA explains how this reporting is to be carried out by adopting a three-tier model approach whereby financial entities shall submit to the competent authority:
- an initial notification, without delay, but no later than the end of the business day, or, in case of a major ICT-related incident that took place later than two (2) hours before the end of the business day, not later than four (4) hours from the beginning of the next business day, or, where reporting channels are not available, as soon as they become available;
- an intermediate report, no later than one (1) week after the initial notification referred to in point (a), followed as appropriate by updated notifications every time a relevant status update is available, as well as upon a specific request of the competent authority; and
- a final report, when the root cause analysis has been completed, regardless of whether or not mitigation measures have already been implemented, and when the actual impact figures are available to replace estimates, but not later than one (1) month from the moment of sending the initial report.
As discussed by Mr. BenHamed, the MFSA has already started implementing this three-tier reporting system whereby the MFSA would internally review the submitted reports and, where necessary, organise supervisory meetings with the relevant financial entity to better understand the situation and, where possible, assist.
Lastly, financial entities can certainly delegate and outsource these reporting obligations to a third party service, provided however that the outsourcing is approved by the competent authority and the financial entity must ensure that it remains responsible for the fulfilment of such obligations at all times.
About the Authors
This article has been authored by Dr Franklin Cachia, CSB Group Director - Tax & Regulated Industries and Dr Luana Agius, Junior Regulated Industries Advisor. Contact us here or on https://www.csbgroup.com/contact-us/ for more information.
