DORA Explored part 2: ICT Risk Management framework

In a year and a half, the Digital Operational Resilience Act (DORA) will come into effect. Are you already preparing for it? We can assist you with that. In a series of in-depth articles, we explain DORA on a topic-by-topic basis. In the previous article, we focused on the requirements from articles 5 to 7, also known as ‘Chapter II: ICT Risk Management’. In this article, we, like DORA, delve deeper into the framework for ICT risk management, as described in articles 8 to 15.

ICT Risk Management framework

Chapter II of DORA contains various prerequisites that establish the foundation for an effectively designed ICT Risk Management Framework. These prerequisites have a clear overlap with the NIST Cybersecurity Framework from 2018 (see the figure below).

In this version of the NIST Cybersecurity Framework, Training and Development are not included. The English version of DORA refers to this as article 13, Learning & Evolving. In our view, this has a slightly different meaning, but it does clarify that this relates to the feedback loop for implementing ‘continuous improvement’ in the ICT Risk Management framework.

DORA sets various requirements for each of these phases regarding their organisation and content. Below, we will discuss each of these phases in detail.

Identification

Article 8 addresses both the identification of ICT risks and the mapping of processes and infrastructure that could be threatened. Below, we present the various requirements in detail.

Section 1: Identification, classification, and documentation of ICT-supported business functions and ICT tasks and responsibilities

It is essential to map the hardware/software/systems/applications, etc., that support these functions. Note that this inventory is expected to take place at least annually.

Section 2: Identification of ‘all sources of ICT risk’ and assessment of relevant cyber threats and ICT vulnerabilities

The legislator emphasises the need to pay attention to possible risks that could also affect other financial entities (directly or indirectly). Assessing threats refers to conducting a risk analysis, which should also be reviewed annually. DORA repeats this evaluation requirement in Article 8, section 7, specifically for ‘legacy’ ICT systems.

Section 3: Performing a risk assessment during significant changes

When major changes are implemented, such as in the network or applications, an estimate of the impact of the change on the security of relevant business functions is necessary. We recommend documenting the assessment so that the results can be shared with management or regulators.

Section 4: Identifying all information and ICT assets, including interconnections and dependencies

Unlike point 1, this specifically pertains to pure ICT equipment, such as network components like firewalls. In ICT terminology, this is also referred to as ‘configuration management.’

Section 5: Inventory of processes dependent on third-party ICT service providers

This requires a deeper understanding by indicating interconnections with providers that support critical or important functions. This inventory will form the basis for analysing ICT third-party risk management.

Protection & Prevention

As an organisation, you want to prevent risks from manifesting as much as possible. Article 9 of DORA describes the preventive measures that should be taken, logically derived from the performed risk analysis.

For organising these measures, DORA refers to the establishment of an Information Security Policy. This policy outlines the general IT governance processes, focusing on the availability, authenticity, integrity, and confidentiality of data and ICT assets. For example, in (see also Article 9, section 4):

• Identity Management;
• User Accountmanagement;
• Change Management;
• Patch Management.

Detection

Early detection of abnormal activities, such as noticeable network performance or related to ICT incidents, can ultimately limit the impact of potential cyber threats. Therefore, DORA requires in Article 10 that a financial entity must have multiple detection mechanisms implemented (section 1) across multiple layers of control (section 2). Of course, it is also essential to regularly test these mechanisms, as stipulated in Article 25.

Early detection of abnormal activities, such as noticeable network performance or related to ICT incidents, can ultimately limit the impact of potential cyber threats.

Regarding detection, it is crucial to monitor the ICT setup for possible deviations in users, ICT infrastructure, network traffic, etc. Ideally, in case of anomalies, automatic alerts are sent to, for example, an Information Security Officer.

Response & Recovery

For an adequate setup of Response & Recovery, DORA requires the implementation of a continuity policy in Article 11. As DORA demands for almost every policy and process, this must also be tested periodically/annually, subject to review by Internal Audit, and consider potential implications for third-party providers.

The continuity policy contains the principles to ensure the organisation’s continuity and/or critical functions and to respond appropriately to disruptions

The continuity policy contains the principles to ensure the organisation’s continuity and/or critical functions and to respond appropriately to disruptions. The implementation of these measures should be reflected in various underlying plans, such as a business continuity plan and response & recovery plans.

Business Impact Analysis

An essential part of the continuity policy is the Business Impact Analysis, which must illustrate the organisation’s exact exposure to serious disruptions of business activities. Both qualitative and quantitative criteria should be included in this analysis. This part should not be taken lightly, especially because Article 11, section 10, allows the regulator to request the actual cost estimates of ICT disruptions.

The Business Impact Analysis must illustrate the organisation’s exact exposure to serious disruptions of business activities.

Having a backup capability and an adequate backup and restore policy ensures minimal downtime and disruption of critical business functions and minimal data loss. This is, therefore, a crucial component that needs to be well in order for “response and recovery” to function effectively.

Determining the Recovery Time Objective (RTO) and the Recovery Point Objective (RPO) aligns with the business requirements for critical ICT applications and processes. Article 13 states that a backup policy should be developed with underlying procedures specifying the minimum backup frequency applied to data. This backup policy should align with the RPO. It should also outline the restoration/recovery procedures to achieve the RTO. An important consideration here is that backups must also be protected against unauthorised access.

For communication during a disruption to employees, customers, and regulators, a crisis communication plan must be developed, as specified in Article 14.

Learning & Evolving

Learning & Evolving, as mentioned in Article 13 of DORA, focuses on the organisation’s learning capability and continuous improvement, including its employees. Knowledge about vulnerabilities and cyber threats must be maintained at an appropriate level. Incidents and their handling should be subject to a post-incident evaluation. Lessons learned from such evaluations and suggestions for improvements in procedures, for example, should be provided to the regulator upon request.

Learning & Evolving, as mentioned in Article 13 of DORA, focuses on the organisation’s learning capability and continuous improvement, including its employees.

Article 13, section 6, specifically refers to building knowledge about cyber and ICT-related threats for employees of financial entities. In summary, this article states that it is mandatory to have an awareness program and implement a training program, with digital resilience being a required module. These programs should be proportionate and tailored to the employee’s level and responsibilities, with a specific mention of higher-level management personnel. Additionally, involving third-party ICT service providers in awareness programs and training may be relevant.

Regulatory Technical Standards (RTS)

By January 17, 2024, the European Supervisory Authorities will provide further details through “Regulatory Technical Standards” on several topics related to Chapter 2 of DORA. Specifically, this includes:

• RTS Article 9(2): Providing additional details on the content of policy documents, protocols, procedures, and instruments related to ICT security.
• Article 9(4): Elaborating on the control of access management.
• Article 10(1) and 10(2): Clarifying the meaning of “mechanisms” for rapid detection of abnormal activities and appropriate response and recovery measures.
• Article 11(1): Specifying the components of an ICT Business Continuity Policy.
• Article 11(6): Specifying the testing of ICT Business Continuity Plans.
• Article 11(3): Specifying the components of ICT Response and Recovery Plans.
• Article 6(5): Detailing the form and content of the evaluation report required for ICT risk management.

Steps towards becoming DORA compliant

Chapter 2 of DORA outlines the requirements for an ICT risk management framework and the organisational requirements for implementation within the organisation. The process for identification, protection & prevention, detection, response & recovery, and continuous improvement is further elaborated in articles 8 to 14. DORA mandates various policy documents and procedures, and sometimes also specifies their content.

Although some elements will receive further technical regulation through RTS, it is possible to make an initial assessment based on the structure of DORA and security standards like the NIST Cybersecurity Framework and ISO 27001/27002.

The first step towards becoming DORA compliant involves an analysis: Are the required policies and necessary documentation in place?

The first step towards becoming DORA compliant involves an analysis: Are the required policies and necessary documentation in place? A deeper analysis of existing documentation will determine whether DORA’s requirements are already covered. In a previous article, we have already layed out a similar approach If you have any questions or need assistance in preparing for DORA implementation, our consultants are available to help. They can provide guidance, support, and expertise to ensure your organisation is ready to meet the requirements of DORA within the remaining one and a half years.

DORA Awareness e-learning

If you want to learn more about the requirements DORA imposes on financial institutions, our DORA Awareness e-learning can provide guidance. This e-learning covers topics such as ICT risk management, handling ICT incidents, testing digital operational resilience, and managing ICT risk with third-party providers. For further information and assistance, feel free to contact our consultants. The deadline for compliance is approaching – you have only one and a half years left…

About Projective Group

Established in 2006, Projective Group is a leading Financial Services change specialist. With deep expertise across practices in Data, Payments, Transformation and Risk & Compliance.

We are recognised within the industry as a complete solutions provider, partnering with clients in Financial Services to provide resolutions that are both holistic and pragmatic.  We have evolved to become a trusted partner for companies that want to thrive and prosper in an ever-changing Financial Services landscape.