DORA consultancy - helping financial institutes across the UK and Europe. — Zaksheuskaya, Green and White Abstract

Full Framework

ESA has recently released several draft Regulatory Technical Standards (RTSs), which provide some flavour of expected control levels.

TL;DR Be ready for a lot of operational work.

Why ESA created RTSs?

Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA) under its Article 15 requires to develop of draft regulatory technical standards ('RTSs') aiming at 'further harmonisation of ICT risk management tools, methods, processes and policies' and under its Article 16, to develop simplified ICT risk management framework for certain financial entities. Draft RTSs developed under Article 15 and Article 16(3) of DORA need to be understood as an essential part of the regulations.

The good news:

ESA considers that the RTSs should remain “technology-neutral” and not identify specific products or technologies.
ESA also did not reinvent the wheel, and we all should be really grateful that RTSs broadly follow the industry's best practices and established security frameworks (ISO-IEC 27000 family standards and NIST) and align with other existing regulations (NIS2 and EIOPA Guidelines on ICT security and governance etc.).

When will RTSs be released?

The final report and the submission of the RTSs to the European Commission are expected by 17 January 2024.

The Risk Management technical standards are under a broad umbrella for the following security-related controls, split into standard and simplified requirements.
Let's break down the proposed RTS (Title I) and highlight the challenges of Article 15 in this review.

Chapter I: ICT security policies, procedures, protocols, and tools

Provisions on governance.
As expected from the DORA requirements, the Financial entity must discuss and agree on the strategy, responsibilities and monitoring activities and set relevant information security objectives.
ICT Risk Management.
The Financial entity needs to develop and maintain an annual risk assessment process to guarantee accurate and prompt data transmission without significant disruptions and undue delay.
ICT Asset Management.
The organisation needs to define the asset lifecycle, detailed asset records and ownership that should be utilised for the criticality assessment.
Encryption and Cryptography.
Various cryptography controls, including key management, must be defined and implemented.
ICT Operations Security.
The Financial entity must operate, monitor, control and restore its ICT assets, including maintaining detailed documentation of ICT operations:
- Capacity and performance management - maintain and improve the availability and efficiency of ICT systems and prevent ICT capacity shortages before they materialise.
- Vulnerability and patch management - ensure the security of networks against intrusions and data misuse - conducted weekly.
  Note: ESAs are considering mandating these requirements for all ICT assets, with the independence of their classification and overall risk profile, and with the same weekly frequency already included for those ICT assets supporting critical or important functions.
- Data and system security, including information classification and associated controls per level.
- Logging of all audit and security-related information across the Financial entity environment.
Network security.
The organisation should define various network controls, Including segregation, segmentation, out-of-band management networks and data leakage prevention.
ICT Project and change management.
ICT project management shall include ALL of the following elements:
- project objectives;
- project governance, including roles and responsibilities;
- project planning, timeframe and steps;
- project risk assessment;
- key milestones;
- change management requirements;
- testing of all requirements, including security requirements and respective approval processes, when deploying an ICT system in the production environment.
ICT systems acquisition, development, and maintenance.
The financial entity shall develop, document and implement an ICT systems acquisition, development, and maintenance procedure for testing and approval of all ICT systems before their use, including source code reviews and security testing.

ICT change management shall include all changes to software, hardware, firmware components, systems or security parameters.
Physical and environmental security.
The usual physical controls are from unauthorised access, attacks, accidents, and environmental threats and hazards.
ICT and information security awareness and training.
Shall be aligned with the overall ICT security awareness programmes and digital operational resilience training.

Chapter II: Human Resources Policy and Access Control

Human resources policy.
The good old Joiners-Movers-Leavers process.
Identity Management.
A lifecycle management process for identities.
Access control.
Access rights to ICT assets based on need-to-know, need-to-use and least-privilege principles

Chapter III: ICT-related Incident Detection and Response

ICT-related incident management policy.
Identification, assessment, escalation, forensics, etc.
Anomalous activities detection and criteria for ICT-related incidents detection and response.
A lifecycle management process for identities.

Chapter IV: ICT Business Continuity Management

Components of the ICT business continuity policy.
This will be a lot of work, as typically, an organisation does not possess this level of readiness, business and technical-wise.
Testing of the ICT business continuity plans.
The testing scenarios considered for the development of the business continuity plans shall always be included in the testing;
- Include the testing of ICT services provided by ICT third-parties service providers, where applicable;
- Include the successful switchover of critical business functions, supporting processes and information assets to the disaster recovery environment for a sufficiently representative period of time;
- To challenge the assumptions on which business continuity plans rest. Include procedures to verify the ability of the financial entities staff, of ICT third-party service providers, of ICT systems and ICT services to respond adequately to the scenarios.
ICT response and recovery plans.
The scenarios shall include all of the following:
- cyber-attacks and switchovers between the primary ICT infrastructure and the redundant capacity, backups and redundant facilities;
- scenarios in which the quality of the provision of a critical or important function deteriorates to an unacceptable level or fails and duly considers the potential impact of the insolvency, or other failures, of any relevant ICT third-party service provider;
- partial or total failure of premises, including office and business premises and data centres;
- substantial failure of ICT assets or the communication infrastructure;
- the non-availability of a critical number of staff or key staff members;
- natural disasters, pandemic situations and physical attacks, including intrusions and terrorist attacks;
- insider attack;
- political and social instability, including, where relevant, in the jurisdiction from where the ICT third-party service provider provides its services and the location where the data is stored and processed;
- widespread power outage.

Chapter V: Report on the ICT risk management framework review
Suggestion for the reporting structure.

Our opinion:
The regulator wisely chose to keep the suggested controls mostly high-level and aligned with the industry security best practices. However, the operational effort should be considered. The financial entity must study in detail and fully understand DORA requirements and pragmatically evaluate its readiness.

Please contact us if you have any questions.

Full Framework

Would you like to talk about DORA compliance? Contact us.