EY refers to the global organization, and may refer to one or more, of the member firms of Ernst & Young Global Limited, each of which is a separate legal entity. Ernst & Young Global Limited, a UK company limited by guarantee, does not provide services to clients.
Recent Searches
Published in December 2022, the Digital Operational Resilience Act1 (DORA) aims to strengthen the resilience of the EU financial sector by providing consistent rules addressing digital operational resilience needs of all regulated financial entities2 and an oversight framework for critical information and communication technology (ICT) third-party providers. DORA foresees the publication of several regulatory technical standards (RTS) which will provide financial entities with more details regarding, inter alia:
- The classification of ICT-related incidents
- The policy on ICT services supporting critical or important functions
- ICT risk management framework
In this sense, on 17 January 2024, the European Supervisory Authorities (ESAs) (ESMA3, EBA4 and EIOPA5) published the final reports on the three RTS, which are now being reviewed by the European Commission to be adopted in the coming months.
Application timeline
What are the specific requirements regarding ICT risk management?
DORA requires financial entities to have a sound, comprehensive and well-documented ICT risk management framework, which should ensure a high level of digital operational resilience by enabling entities to address ICT risks quickly and efficiently. The ICT risk management framework, which must include several strategies, policies, procedures and tools, must be reviewed at least once a year,6 upon the occurrence of major ICT-related incidents, and following supervisory instructions or conclusions derived from relevant digital operational resilience testing or audit processes.
The ESAs’ final report on the RTS on ICT risk management tools sets out the general and simplified frameworks7 that financial entities must implement in terms of ICT risk management. According to the RTS, financial entities must, inter alia:
- Have in place an internal governance and control framework with clear responsibilities to enable an effective and sound ICT risk management framework
- Ensure that roles and responsibilities relating to ICT security are correctly allocated and maintained
- Identify and remedy vulnerabilities, and ensure that both the financial entities and their ICT third-party service providers adhere to a coherent, transparent, and responsible vulnerability management framework
- Set out the consequences of non-compliance with ICT security policies or procedures
- Develop and implement several ICT-related policies
- Establish an ICT incident management process, in order to be able to detect, manage and report ICT incidents
In order to reduce the administrative and operational burden, the RTS allows entities to develop and document in one single policy, the Information security policy, the high-level principles and rules to protect the confidentiality, integrity, availability and authenticity of data, security of networks, adequate safeguards against intrusions, and data misuse.
As part of the ICT security policies and procedures, financial entities are required to develop, document and implement, inter alia:
An ICT asset management policy (which contains the records on the ICT assets, such as the identity of the ICT asset owners, the business functions or services supported by the assets and the business continuity requirements) and procedures detailing the criteria to perform the criticality assessment of information assets and ICT assets supporting business functions.
An encryption and cryptographic controls policy including the rules for the encryption of data and internal network connections, provisions for cryptographic key management and a requirement in the policy on encryption and cryptographic controls to record the adoption of mitigation and monitoring measures adopted.
ICT operations policies defining how financial entities operate, monitor, control and restore their ICT assets, including the documentation of ICT operations.
Capacity and performance management procedures including the identification of the capacity requirements of the ICT systems, application of resource optimization, monitoring procedures to maintain and improve the availability of data and ICT systems, and prevention of ICT capacity shortages.
Vulnerability and patch management procedures ensuring the security of networks against intrusions and data misuse.
Data and system security procedures including access restrictions, identification of security measures against malicious codes, implementation of security measures to ensure that teleworking and the use of private endpoint devices does not adversely impact the ICT security of the financial entity.
The RTS also establishes that financial entities must develop and implement access control and identity management policies, which, respectively, cover the authentication methods and physical access control and ensure the unique identification and authentication of natural persons and systems accessing the financial entities’ information.
In terms of safeguards against intrusions and data misuse, the RTS determines that financial entities must develop, document and implement procedures, protocols and tools regarding:
- Logging: Including the identification of the events to be logged, the retention period of the logs and the measures to secure and handle the log data
- Network security management: Including the segregation and segmentation of ICT systems and networks, the identification and implementation of network access controls to prevent and detect connections to the financial entity’s network by any unauthorized device or system, or any endpoint not meeting the financial entity’s security requirements; the encryption of network connections passing over corporate networks, public networks, domestic networks, third-party networks and wireless networks, for communication protocols used, the procedures to limit, lock and terminate system and remote sessions after a predefined period of inactivity
- Securing information in transit: Such as ensuring the availability, authenticity, integrity and confidentiality of data during network transmission, the prevention and detection of data leakage and the secure transfer of information between the financial entity and external parties
- ICT project management: Including a policy which must define the elements to ensure the effective management of the ICT projects related to the acquisition, maintenance and, where applicable, development of the financial entity’s ICT systems
- ICT systems acquisition, development, and maintenance: Including identifying security practices and methodologies relating to the acquisition, development and maintenance of ICT systems, defining measures to mitigate the risk of unintentional alteration or intentional manipulation of the ICT systems during development, maintenance and deployment in the production environment, developing, documenting and implementing an ICT systems’ acquisition, development and maintenance procedure
- ICT change management: Including procedures containing, inter alia, the mechanisms to ensure independence between the functions that approve changes and those responsible for requesting and implementing them, identification of fallback procedures and responsibilities, identification of the potential impact of a change on existing ICT security measures and assessment of whether it requires the adoption of additional ICT security measures
- Physical and environmental security: The policy must include, inter alia, measures to protect the premises, data centers and ICT assets
The framework for managing ICT risks must be recorded and reviewed at a minimum once a year, or periodically for microenterprises, and also when significant ICT-related issues arise. It should also be reviewed following directions or outcomes from relevant digital operational resilience testing or auditing. Continuous enhancements should be made drawing on the insights gathered from its implementation and monitoring. Upon their request, a review report of the ICT risk management framework must be presented to the competent authority.
Business continuity and recovery
Financial entities must have in place an ICT business continuity policy and ICT response and recovery plans. The ICT business continuity policy must contain, inter alia, provisions on governance and organization and a description of the criteria to (de)activate ICT business continuity plans. These plans must be tested taking into account the entity’s business impact analysis and the ICT risk assessment. Through these tests, entities must assess whether they are able to ensure the continuity of the critical or important functions.
In turn, the ICT response and recovery plans must:
- Identify and develop relevant scenarios (including those of severe business disruptions and increased likelihood of occurrence of disruption) based on current information on threats and on lessons learned from previous occurrences of business disruptions
- Specify the conditions prompting the (de)activation of the ICT response and recovery plans
- Describe what actions must be taken to ensure the availability, integrity, continuity and recovery of at least the entity’s ICT systems and services supporting critical or important functions
Measures to mitigate failures of ICT third-party service providers of ICT services supporting critical or important functions to the financial entity must also be implemented. In this sense, in addition to the other policies, financial entities must adopt a written policy on the use of ICT services supporting critical or important functions provided by ICT third-party service providers. The policy must take into account, inter alia, the type of ICT services included in the contractual arrangement, the location of the ICT third-party service provider, the nature of data shared with the ICT third-party service providers, whether the ICT third-party service providers are part of the same group of the financial entity, and the potential impact of disruptions on the continuity and availability of the financial entity’s activities.
It is worth noting that the relevant contractual arrangements do not exempt financial entities and their management bodies of their regulatory obligations and their responsibilities towards clients, and must not hinder effective supervision or contravene any supervisory restrictions on services and activities.
ICT-related incidents management policy
Financial entities must set clear roles and responsibilities to effectively detect and respond to ICT-related incidents and anomalous activities. The detection and response process must be triggered in the following cases:
What triggers ICT-related incident detection and response processes?
Entities must also have in place an ICT-related incident policy which:
- Documents the ICT-related incident management process
- Establishes a list of relevant contacts with internal functions and external stakeholders that are directly involved in ICT operations’ security
- Establishes, implements and operates technical, organizational and operational mechanisms to support the ICT-related incident management process
- Retains all evidence relating to ICT-related incidents for a period no longer than necessary for the purposes for which the data is collected, commensurate with the criticality of the affected business functions
- Establishes and implements mechanisms to analyze significant or recurring ICT-related incidents and patterns in the number and the occurrence of ICT-related incidents
Whenever an ICT-related incident is identified, it must be classified considering the below criteria:
- The number of clients/counterparts/transactions affected
- The reputational impact8
- The duration of an incident (including from the moment the incident occurs until it is solved and the service downtime)
- The locations affected
- Data losses
- Whether critical services were affected
- Direct and indirect costs and losses
Notion of critical services
According to the RTS, a critical service is affected when an incident:
- Affects or has affected ICT services or network and information systems that support critical or important functions of the financial entity
- Affects or has affected financial services that require authorization, registration or that are supervised by competent authorities; or
- Represents a successful, malicious and unauthorized access to the network and information systems of the financial entity
The RTS determines that incidents considered as major:
- Must have had any impact on critical services and either:
a) Are any successful, malicious and unauthorized access to network and information systems, which may result to data losses or
b) Meet two or more materiality thresholds specified below:
If an incident is not considered as major, but it is recurring, it must be considered as a major incident if:
- It has occurred at least twice within six months
- It has the same apparent root cause
Therefore, the incidents collectively categorize as a major incident
Luxembourg perspective
CSSF Circular 24/847 on ICT-related incident reporting, applicable to credit institutions and investment fund managers from 1 April and 1 June 2024 respectively, foresees the criteria to be taken into account when classifying ICT-related incidents. This Circular anticipates the requirements of the draft RTS on major incidents reporting (whose final report is expected to be published in the middle of 2024) and also integrates some provisions regarding the definition of major incidents contained in the final report on the draft RTS on criteria for the classification of ICT-related incidents. However, it does not determine the exact threshold that must be met. In this sense, entities are those responsible for determining whether an ICT-related incident is major or not. If the incident is classified as major, a specific notification process is required. However, in cases where the assessment does not lead to a clear outcome, entities must report the ICT-related incident to the CSSF. In order to classify the incidents, the CSSF requires entities to assess the incidents’ impact on the basis of the following criteria:
- The number and/or relevance of clients or financial counterparts affected and, where applicable, the amount or number of transactions affected by the ICT-related incident, and whether the ICT-related incident has caused reputational impact
- The duration of the ICT-related incident, including the service downtime
- The geographical spread with regard to the areas affected by the ICT-related incident, particularly if it affects more than two Member States
- The data losses that the ICT-related incident entails, in relation to availability, authenticity, integrity or confidentiality
- The criticality of the services affected, including the entity’s transactions and operations
- The economic impact, in particular direct and indirect costs and losses, of the ICT-related incident in both absolute and relative terms
Note that successful malicious unauthorized accesses must be considered as major ICT-related incidents.
What is the maximum delay for the classification of an ICT-related incident?
Entities must classify the ICT-related incident in a timely manner after the incident has been detected, and without undue delay after the information required for the classification is available to the entity, but no later than 24 hours after the detection of the incident. If more time is needed, entities must explain in the initial notification submitted to the competent authority (the CSSF) the reasons thereof. Where the deadline for classification falls on the weekend or on a bank holiday, entities may classify the incident on the next working day.
It is worthwhile mentioning that the Circular will repeal and replace Circular CSSF 11/504 on “Frauds and incidents due to external computer attacks” and that its three main objectives are:
- To increase the incident coverage (not only limited to fraud and incidents due to external computer attacks)
- To obtain more information on ICT incidents that impact the Luxembourg market
- To include within the reporting process and under the CSSF supervision, Operators of Essential Services (OES) and Digital Service Providers (DSP) subject to the Law of 28 May 2019 (the “NIS Law”), and for which the “NIS authority” is the CSSF according to article 3 of the NIS Law
Reporting ICT-related incident requirements
CSSF Circular 24/847 of 5 January 2024 also introduces new rules regarding ICT-related incident reporting notifications. According to the Circular, entities10 must submit notifications if the following occurs:
- Any successful malicious unauthorized access to the network and information systems (NIS)
- Any incident classified as a major ICT-related incident other than a successful malicious unauthorized access to the NIS
Entities must, within the time limits, submit the notifications of major ICT-related incidents to the CSSF.
What triggers ICT-related incident detection and response processes?
When entities have reason to believe that an ICT-related incident has or will potentially have a very serious impact (for example, an incident which results in the complete unavailability of systems), they must notify the CSSF as soon as possible, and if necessary, before the formal submission of the notification form.
It is worth noting that the sections of the notification form must be submitted in the order indicated, however in cases where the entity has all the information required available at the time of the initial notification, a single submission (containing all the sections) can be made.
Entities must also notify the CSSF when an ICT-related incident no longer fulfills the criteria to be considered as major and is not expected to fulfill them before the ICT-related incident is resolved. In these circumstances, entities must reclassify the incident and provide an explanation justifying this reclassification.
Outsourcing
Entities may outsource the reporting obligations to a third party. However, the entity remains fully responsible for the fulfillment of the ICT-related incident reporting requirements within the applicable timeline and for the whole content of the incident reporting.
How EY can help
As part of strategy consulting, we support various actors of the financial sector in designing, implementing or assessing the effectiveness and efficiency of ICT risk programs, compliance positions and how risks are managed now and going forward (resilience).
In addition, as DORA pulls critical ICT third-party providers (CCTPs) into the game with increased scrutiny from the competent authorities, EY has developed Third Party Security Risk Management (TPRM) solutions providing a support function for management bodies to identify, evaluate, monitor and manage the risks associated with third parties and contracts. Some of our services are outlined as follows.
Summary
Published in December 2022, the Digital Operational Resilience Act (DORA) aims to strengthen the resilience of the EU financial sector by providing consistent rules addressing digital operational resilience needs of all regulated financial entities and an oversight framework for critical ICT third-party providers.