With 15 January 2025, the date on which financial entities and third-party service providers must be DORA compliant, rapidly approaching, more and more information is becoming available on how these entities need to comply.
On 23 and 24 October 2024, the European Commission adopted the following Regulatory Technical Standards (‘RTS’) and Implementing Technical Standard ('ITS’) through Delegated Regulations supplementing DORA:
- an RTS specifying the content and time limits for the initial notification of, and intermediate and final report on, major ICT-related incidents, and the content of the voluntary notification for significant cyber threats; and
- an accompanying ITS with regard to the standard forms, templates, and procedures for financial entities to report a major ICT-related incident and to notify a significant cyber threat; and
- an RTS on harmonisation of conditions enabling the conduct of the oversight activities.
In this blog we break down the adopted RTSs and ITS.
RTS and ITS on reporting requirements
As a general rule, DORA requires financial entities, such as credit institutions, electronic money institutions, investment fund managers and insurance undertakings, to establish procedures to detect, manage and report on major ICT-related incidents. Although some financial entities, such as payment institutions or electronic money institutions, already have reporting obligations based on existing European legislation, one of the objectives of DORA is to harmonise and streamline the reporting regime for all financial entities. To facilitate this objective, the newly adopted RTS and accompanying ITS lay down more detailed rules concerning the reporting framework. The reporting requirement framework is divided in three phases: (1) the initial notification, (2) the intermediate report, and (3) the final report.
(1) Initial notification
At the first detection of a major ICT incident, an initial notification must be sent to the national competent authority. The obligatory notification should contain only data that is strictly necessary, such as information on the financial entity, the contact person, and on the incident itself. The entity should report among others on the nature of the incident, how it was discovered, and whether the business continuity plan has been activated. The initial notification must be reported within 4 hours and no later than 24 hours, from the moment the incident is classified as major.
(2) Intermediate report
Subsequently, within 72 hours after submitting the initial notification, an intermediate report must be submitted. This report should enable competent authorities to further assess the ICT-related incident and decide on supervisory actions. Based on the RTS, the report should contain affected functional areas and business processes, as well as affected infrastructure components supporting these processes and the impact on the financial interests of clients. Information on the actions taken or planned to be taken to recover from the incident are to be included in the report as well. Moreover, updates are to be made in additional intermediate reports, should the situation or the measures taken change throughout the handling of the incident.
(3) Final report
The final report is submitted once the incident is resolved. The deadline of a final report is one month after filing the latest report. This report should contain information about, among other things, the root cause(s) of the ICT-related incident, dates and times when the incident was resolved and the root cause(s) addressed, and information about direct and indirect costs and losses stemming from the ICT-related incident plus information about financial recoveries.
Reporting templates
The accompanying ITS contains three templates to be used by financial entities when reporting major ICT-related incidents. Each report has a mandatory template.
Time limits
The RTS specifying the content and time limits of notifications states that if a financial entity is unable to report within the mandatory time limits, it must do so at its earliest opportunity, accompanied by an explanation for the delay. If the time limit ends on a weekend or bank holiday, the time limit is adjourned to noon the next working day. This postponement option is not applicable to credit institutions, central counterparties, operators of trading venues, and other financial entities identified as essential or important entities employing over 250 persons, a turnover exceeding EUR 50 million and/or an annual balance sheet exceeding EUR 43 million.
Voluntary notification
Based on DORA, financial entities can, on a voluntary basis, notify significant cyber threats to the competent authority when they deem the threat to be of relevance to the financial system, service users or clients. We refer to one of our previous DORA blogs in which the definition of significant cyber threats is described. The RTS specifying the content and time limits of notifications describes what a voluntary notification should contain. This includes, among other things, a description of the significance of the cyber threat, information about the potential impact on the financial entity, its clients or financial counterparts. If applicable, the financial entity should include a description of the actions taken to prevent the materialisation of the significant cyber threat (or threats).
RTS on harmonisations of conditions enabling oversight activities
The three European Supervisory Authorities (‘ESAs’) – the EBA, ESMA and EIOPA – have been designated as the ‘Lead Overseer’ to supervise critical ICT third-party service providers. The Lead Overseer has far-reaching power to conduct oversight and impose sanctions in case of non-compliance with the instructions from the respective ESA. ICT service providers that are not designated as critical may opt in to be supervised by the Lead Overseer. The RTS on harmonisation of conditions enabling the conduct of the oversight activities harmonises the information that should be submitted by a voluntary applicant.
Content of the voluntary request
The ICT third-party service provider must provide the Lead Overseer with all the necessary information to demonstrate its criticality. The information should be sufficiently detailed and complete to enable a clear and complete assessment of criticality. Examples of information to be included are the estimation of market share of the applicant and description of ICT services rendered to financial entities in the EU.
Content of the oversight activities
Upon request, critical third-party service providers must submit extensive information to the Lead Overseer that is necessary for the conduct of oversight. The information to be provided is described in the RTS on harmonisation of conditions enabling oversight activities. This includes a detailed overview of the applicant’s legal and geographical structure, its risk management framework and its response policies regarding major ICT-related incidents. In accordance with DORA, the Lead Overseer uses this information to assess whether the applicant has in place comprehensive, sound and effective rules, procedures, mechanisms and arrangements to manage the ICT risk which it may pose to financial entities. The new RTS clarifies that if the Lead Overseer provides the applicant with recommendations based on the assessment, the critical third-party service provider must respond with the information set out in the RTS. The information as set out in the RTS must include a report containing a remediation plan in order to mitigate the risks specified in the recommendations, among other things. Next to the Lead Overseer, the RTS compels the national competent authorities to assess the measures taken by the ICT third-party service provider based on the recommendations of the Lead Overseer. Upon request, the Lead Overseer will receive the assessment from the national competent authority.
The remainder of the second batch
The European Commission has yet to adopt two more RTSs: one on the criteria for determining the composition of the joint examination team and one on thread-lead penetration testing. In addition, one more ITS has yet to be adopted. This since the European Commission rejected the ITS on the register of information, proposing to include the European Unique Identifier (‘EuID’). The Commission argued that financial entities should have the choice between the EuID and the LEI code when identifying their ICT third-party service providers registered in the EU. The ESAs responded by expressing their concerns in this regard. They state that only the LEI code provides for international convergence for the identification of legal entities participating in financial markets and its related activities.
What’s next?
The Council of the EU and the European Parliament will scrutinise the RTSs and ITS for a maximum of three months. If neither object, the technical standards will be published in the Official Journal of the European Union. Twenty days thereafter, the RTSs and ITS will enter into force. Meanwhile, we wait for the final publication of the remaining RTSs and ITS on the register of information. As always, we will keep you updated on any development regarding DORA in our blogs.
With 15 January 2025, the date on which financial entities and third-party service providers must be DORA compliant, rapidly approaching, more and more information is becoming available on how these entities need to comply.
On 23 and 24 October 2024, the European Commission adopted the following Regulatory Technical Standards (‘RTS’) and Implementing Technical Standard ('ITS’) through Delegated Regulations supplementing DORA:
- an RTS specifying the content and time limits for the initial notification of, and intermediate and final report on, major ICT-related incidents, and the content of the voluntary notification for significant cyber threats; and
- an accompanying ITS with regard to the standard forms, templates, and procedures for financial entities to report a major ICT-related incident and to notify a significant cyber threat; and
- an RTS on harmonisation of conditions enabling the conduct of the oversight activities.
In this blog we break down the adopted RTSs and ITS.
RTS and ITS on reporting requirements
As a general rule, DORA requires financial entities, such as credit institutions, electronic money institutions, investment fund managers and insurance undertakings, to establish procedures to detect, manage and report on major ICT-related incidents. Although some financial entities, such as payment institutions or electronic money institutions, already have reporting obligations based on existing European legislation, one of the objectives of DORA is to harmonise and streamline the reporting regime for all financial entities. To facilitate this objective, the newly adopted RTS and accompanying ITS lay down more detailed rules concerning the reporting framework. The reporting requirement framework is divided in three phases: (1) the initial notification, (2) the intermediate report, and (3) the final report.
(1) Initial notification
At the first detection of a major ICT incident, an initial notification must be sent to the national competent authority. The obligatory notification should contain only data that is strictly necessary, such as information on the financial entity, the contact person, and on the incident itself. The entity should report among others on the nature of the incident, how it was discovered, and whether the business continuity plan has been activated. The initial notification must be reported within 4 hours and no later than 24 hours, from the moment the incident is classified as major.
(2) Intermediate report
Subsequently, within 72 hours after submitting the initial notification, an intermediate report must be submitted. This report should enable competent authorities to further assess the ICT-related incident and decide on supervisory actions. Based on the RTS, the report should contain affected functional areas and business processes, as well as affected infrastructure components supporting these processes and the impact on the financial interests of clients. Information on the actions taken or planned to be taken to recover from the incident are to be included in the report as well. Moreover, updates are to be made in additional intermediate reports, should the situation or the measures taken change throughout the handling of the incident.
(3) Final report
The final report is submitted once the incident is resolved. The deadline of a final report is one month after filing the latest report. This report should contain information about, among other things, the root cause(s) of the ICT-related incident, dates and times when the incident was resolved and the root cause(s) addressed, and information about direct and indirect costs and losses stemming from the ICT-related incident plus information about financial recoveries.
Reporting templates
The accompanying ITS contains three templates to be used by financial entities when reporting major ICT-related incidents. Each report has a mandatory template.
Time limits
The RTS specifying the content and time limits of notifications states that if a financial entity is unable to report within the mandatory time limits, it must do so at its earliest opportunity, accompanied by an explanation for the delay. If the time limit ends on a weekend or bank holiday, the time limit is adjourned to noon the next working day. This postponement option is not applicable to credit institutions, central counterparties, operators of trading venues, and other financial entities identified as essential or important entities employing over 250 persons, a turnover exceeding EUR 50 million and/or an annual balance sheet exceeding EUR 43 million.
Voluntary notification
Based on DORA, financial entities can, on a voluntary basis, notify significant cyber threats to the competent authority when they deem the threat to be of relevance to the financial system, service users or clients. We refer to one of our previous DORA blogs in which the definition of significant cyber threats is described. The RTS specifying the content and time limits of notifications describes what a voluntary notification should contain. This includes, among other things, a description of the significance of the cyber threat, information about the potential impact on the financial entity, its clients or financial counterparts. If applicable, the financial entity should include a description of the actions taken to prevent the materialisation of the significant cyber threat (or threats).
RTS on harmonisations of conditions enabling oversight activities
The three European Supervisory Authorities (‘ESAs’) – the EBA, ESMA and EIOPA – have been designated as the ‘Lead Overseer’ to supervise critical ICT third-party service providers. The Lead Overseer has far-reaching power to conduct oversight and impose sanctions in case of non-compliance with the instructions from the respective ESA. ICT service providers that are not designated as critical may opt in to be supervised by the Lead Overseer. The RTS on harmonisation of conditions enabling the conduct of the oversight activities harmonises the information that should be submitted by a voluntary applicant.
Content of the voluntary request
The ICT third-party service provider must provide the Lead Overseer with all the necessary information to demonstrate its criticality. The information should be sufficiently detailed and complete to enable a clear and complete assessment of criticality. Examples of information to be included are the estimation of market share of the applicant and description of ICT services rendered to financial entities in the EU.
Content of the oversight activities
Upon request, critical third-party service providers must submit extensive information to the Lead Overseer that is necessary for the conduct of oversight. The information to be provided is described in the RTS on harmonisation of conditions enabling oversight activities. This includes a detailed overview of the applicant’s legal and geographical structure, its risk management framework and its response policies regarding major ICT-related incidents. In accordance with DORA, the Lead Overseer uses this information to assess whether the applicant has in place comprehensive, sound and effective rules, procedures, mechanisms and arrangements to manage the ICT risk which it may pose to financial entities. The new RTS clarifies that if the Lead Overseer provides the applicant with recommendations based on the assessment, the critical third-party service provider must respond with the information set out in the RTS. The information as set out in the RTS must include a report containing a remediation plan in order to mitigate the risks specified in the recommendations, among other things. Next to the Lead Overseer, the RTS compels the national competent authorities to assess the measures taken by the ICT third-party service provider based on the recommendations of the Lead Overseer. Upon request, the Lead Overseer will receive the assessment from the national competent authority.
The remainder of the second batch
The European Commission has yet to adopt two more RTSs: one on the criteria for determining the composition of the joint examination team and one on thread-lead penetration testing. In addition, one more ITS has yet to be adopted. This since the European Commission rejected the ITS on the register of information, proposing to include the European Unique Identifier (‘EuID’). The Commission argued that financial entities should have the choice between the EuID and the LEI code when identifying their ICT third-party service providers registered in the EU. The ESAs responded by expressing their concerns in this regard. They state that only the LEI code provides for international convergence for the identification of legal entities participating in financial markets and its related activities.
What’s next?
The Council of the EU and the European Parliament will scrutinise the RTSs and ITS for a maximum of three months. If neither object, the technical standards will be published in the Official Journal of the European Union. Twenty days thereafter, the RTSs and ITS will enter into force. Meanwhile, we wait for the final publication of the remaining RTSs and ITS on the register of information. As always, we will keep you updated on any development regarding DORA in our blogs.