🔒
There are new articles available, click to refresh the page.
Before yesterdayNVISO Labs

The digital operational resilience act (DORA): what you need to know about it, the requirements and challenges we see.

23 November 2021 at 15:02

TL;DR – In this blogpost, we will give you an introduction to DORA, as well as how you can prepare yourself to be ready for it.

More specifically, throughout this blogpost we will try to formulate an answer to following questions:

  • What is DORA and what are the key requirements of DORA?
  • What are the biggest challenges that you might face in becoming “DORA compliant”?

This blog post is part of a series, keep an eye out for the following parts! In the following blogposts, we will further explore the requirements of DORA, as well as elaborate a self-assessment checklist for financial entities to start assessing their compliance.

What is DORA?

DORA stands for Digital Operational Resilience Act. DORA is the EU proposal to tackle digital risks and build operational resilience in the financial sector. 

The idea of DORA is that organizations are able to demonstrate that they can resist, respond and recover from the impacts of ICT incidents, while continuing to deliver critical functions and minimizing disruption for customers and for the financial system as a whole.

With the DORA, the EU aims to make sure financial organisations mitigate the risks arising from increasing reliance on ICT systems and third parties for critical operations. The risks will be mitigates through appropriate Risk Management, Incident Management, Digital Operational Resilience Testing, as well as Third-Party Risk Management.

Who is concerned?

DORA applies to financial entities, from banks i.e. credit institutions to investment & payment institutions,  electronic money institutions, pension, audit firms, credit rating agencies, insurance and reinsurance undertakings and intermediaries.

Beyond that it also applies to providers of digital and data services, including providers of cloud computing services, data analytics, & data centres.

Note that, while the scope of the DORA itself is proposed to encompass nearly the entire financial system, at the same time it allows for a proportionate application of requirements for financial entities that are micro enterprises.

Exploring DORA

What is operational resilience? Digital operational resilience is the ability to build, assure and review the technological operational integrity of an organisation. In a nutshell, operational resilience a way of thinking and working that emphasizes the hardening of systems so that when an organization is attacked, it has the means to respond, recover, learn, and adapt.

Organizations that do not adopt this mindset are likely to experience DORA as an almost impossibly long checklist of disconnected requirements. We will cover the requirements in the coming blogposts.

DORA introduces requirements across five pillars: 

  • ICT Risk Management
  • ICT-related Incidents Management, Classification and Reporting
  • Digital Operational Resilience Testing
  • ICT Third-Party Risk Management
  • Information and Intelligence Sharing

We have summarised the requirements and these key challenges to start addressing now for each of the 5 pillars. 

ICT Risk Management

DORA requires organizations to apply a strong risk-based approach in their digital operational resilience efforts. This approach is reflected in Chapter 2 of the regulation.

What is required?

ICT risk management requirements form a set of key principles revolving around specific functions (identification, protection and prevention, detection, response and recovery, learning and evolving and communication). Most of them are recognized by current technical standards and industry best practices, such as the NIST framework, and thus the DORA does not impose specific standardization itself.

What do we consider as potential challenges for most organizations?

As described in DORA, the structure does not significantly deviate from standard Information security risk management as defined in NIST Cyber Security Framework.

However, we foresee some elements that might rise additional complexity:

First, as we reviewed, the ICT risk management requirements are organised around:

  • Identifying business functions and the information assets supporting these.
  • Protecting and preventing these assets.
  • Detecting anomalous activities.
  • Developing response and recovery strategies and plans, including communication to customers and stakeholders.

We foresee several elements that might rise additional complexity:

1. Nowadays, we see many organizations struggling with adequate asset management. A first complexity might emerge from the fact the ICT risk management framework shall include the identification of critical and important functions as well as the mapping of the ICT assets that underpin them. This framework shall also include the assessment of all risks associated with the ICT-related business functions and information assets identified.

2. Protection and Prevention is also a challenge for most organizations. Based on the risk assessment, financial entities shall set up protection and prevention measures to ensure the resilience, continuity and availability of ICT systems. These shall include ICT  security  strategies, policies,  procedures and appropriate technologies to ensure the continuous monitoring and control of ICT systems and tools.

3. Most organizations also struggle with timely or prompt detection of anomalous activities. Some complexity might arise as financial entities shall have to ensure the prompt detection of anomalous activities, enforce multiple layers of control, as well as enable the identification of single points of failure.

4. However, while the first three of these will be fairly familiar to most firms, although implemented with various degrees of maturity, the latter (response and recovery) should focus minds. This will require financial entities to think carefully about substitutability, including investing in backup and restoration systems, as well as assess whether – and how – certain critical functions can operate through alternative systems or methods of delivery while primary systems are checked and brought back up.

5. On top of this, as part as the “Learning and Evolving” part of DORA’s Risk Management Framework, DORA not only introduces compulsory training on digital operational resilience for the management body but also for the whole staff, as part of their general training package. Getting all staff on-board might create additional complexity.

In a coming blogpost, we will be reviewing the requirements associated with the risk-based approach based on the ICT risk management framework of DORA, as well as elaborating a self-assessment checklist for financial entities to start assessing their compliance.

ICT-related Incidents Management, Classification and Reporting

DORA has its core in a strong evaluation and reporting process. This process is reflected in Chapter 3 of the regulation.

What is required?

What is required?

In the regulation, ICT-related incident reporting obliges financial entities to establish and implement a management process to monitor and log ICT-related incidents and to classify them based on specific criteria.

The ICT-related Incident Management requirements are organised around:

  • Implementation of an ICT-related incident management process
  • Classification of ICT-related incidents
  • Reporting of major ICT-related incidents

What do we consider as potential challenges for most organizations?

We foresee two elements that might rise additional complexity:

1. First, financial entities will need to review their incident classification methodology to fit with the requirements of the regulation. To help organisations prepare, we anticipate that the incident classification methodology will align with the ENISA Reference Incident Classification Taxonomy.  Indeed, this framework is referenced in the footnote of DORA. Other standards might be permissible, provided they meet the conditions set out in the Regulation but, when a standard or framework is especially called out, there is no downside to considering it.

2. Second, financial entities will also need to set up the right processes and channels to be able to notify the regulator fast in case a major incident occurs. Although firms will only need to report major incidents to their national regulator, this will need to be within strict deadlines. Moreover, based on what gets classified as “major”, this might happen frequently. 

In a coming blogpost, we will be reviewing the requirements associated with the ICT-related Incidents Management of DORA, as well as elaborating a self-assessment checklist for financial entities to start assessing their compliance.

Digital Operational Resilience Testing

DORA introduces the testing efficiency of the risk management framework and measures in place to respond to and recover from a wide range of ICT incident scenarios. This process is reflected in Chapter 4 of the regulation.

What is required?

The underlying rationale behind this part of the regulation would be that undetected vulnerabilities in financial entities could threaten the stability of the financial sector. In order to mitigate this risk, DORA introduces a comprehensive testing program with the aim to identify and explore possible ways in which financial entities could be compromised.

Digital operational resilience testing serves for the periodic testing of the ICT risk management framework for preparedness and identification of weaknesses, deficiencies or gaps, as well as the prompt adoption of corrective measures.

DORA also strongly recommends advanced testing of ICT tools, systems and processes based on threat led penetration testing (“TLPT”), carried out at least every 3 years. The technical standards to apply, when conducting intelligence-based penetration testing, are likely to be aligned with the TIBER-EU developed by the ECB.

The Digital Operational Resilience Testing requirements are therefore organised around:

  • Basic Testing of ICT tools and systems – Applicable to all financial entities
  • Advanced Testing of ICT tools, systems and processes (“TLPT”) – Only applicable to  financial entities identified as significant by competent authorities

What do we consider as potential challenges for most organizations?

We foresee two elements that might rise additional complexity:

1. First, from a cultural standpoint, a challenge might be that financial entities see or perceive Operational Resilience testing as BCP or DR testing. A caution has to be raised here as the objective of DORA with this requirements focuses more on penetration testing than the traditional Operational Resilience testing.

From another cultural standpoint, resilience testing programs should not be perceived as a single goal. It should not be perceive as a binary value concept (either it is in place or not). As stated, the underlying behind DORA is rather about identifying weaknesses, deficiencies or gaps, and admitting that a breach might happen or a vulnerability could go undetected. DORA is therefore more about preparing to withstand just such a possibility.

2. Second, as stated, significant financial entities (might be firms already in the scope of NIS regulation) will have to implement a threat-led penetration testing program and exercise. It is likely that this first exercise will have to be organized by the end of 2024. This might seem like a sufficient period to time for these tests to be conducted, however, consider that these types of tests will require a lot of preparation. First, all EU-based critical ICT third parties are required to be involved. This means that all of these third-parties should also be involved in the preparation of this exercise, which will require a lot of coordination and planning beforehand. Second, the scenario for these threat-led penetration testing exercises will have to be agreed by the regulator in advance. Significant financial entities should therefore start thinking about the scenario as soon as possible to enable validation with the regulator at least 2 years before the deadline.  

In a coming blogpost, we will be reviewing the requirements associated with the Resilience Testing of DORA, as well as elaborating a self-assessment checklist for financial entities to start assessing their compliance.

ICT Third-Party Risk Management

DORA introduces the governance of third-party service providers and the management of third-party risks. DORA states that financial entities should have appropriate level of controls and monitoring of their ICT third parties. This process is reflected in Chapter 5 of the regulation.

What is required?

Chapter 5 addresses the key principles for a sound management of ICT Third-Party risks. In a nutshell, the main requirements associated with these key principles could be described as the following:

  • Obligatory Contractual Provisions :
    • DORA introduces obligatory provisions that have to be present in any contract concluded between a financial institution and an ICT third-party provider.
  • ICT third-party risk strategy definition :
    • Firm shall define a multi-vendor ICT third-party risk strategy and policy owned by a member of the management body.
  • Maintenance of a Register of Information :
    • Firms shall define and maintain a register of information that contains the full view of all their ICT third-party providers, the services they provide and the functions they underpin according to the key contractual provisions.
  • Perform due diligence/assessments :
    • Firms shall assess ICT service providers according to certain criteria before entering into a contractual arrangement on the use of ICT services (e.g. security level, concentration risk, sub-outsourcing risks).

What do we consider as potential challenges for most organizations?

We foresee several elements that might rise additional complexity:

1. One of the main challenges that we foresee relates to the assembling and maintenance of the Register of Information. Financial entities will have to collect information on all ICT vendors (not only the most critical).  

This might create additional complexity as DORA states that this register shall be maintained at entity level and, at sub-consolidated and consolidated levels. DORA also states that this register shall include all contractual arrangements on the use of ICT services provided, identifying the services the third-party provided and the functions they underpin. 

This requirement could be considered as a challenge, on one hand, for large financial entities that rely on thousands of big and small providers, as well as on the other hand, for smaller, less mature financial institutions that will have to ensure that that register of information is complete and accurate.

Some other challenges also have to be foreseen.

2. Contracts with all ICT providers will probably need to be amended. For “EBA” critical contracts this will be covered through the EBA directive on this, however for others (if all ICT providers are affected) this will not be the case yet. Identifying those, and upgrading their contracts will be a challenge.

3. Regarding the Exit strategy, and following the same reasoning, for “EBA” critical contracts this will be covered through the EBA directive on this, however for others this might not be the case yet. Determining how to enforce this requirement in these contract will also have to be seen as creating additional complexity.

4. Determining a correct risk-based approach for performing assessments on the ICT providers will possibly add additional complexity as well. Performing assessments on all ICT providers is not feasible. ICT providers will have to be prioritized based on criticality criteria that will have to be defined.

In a coming blogpost, we will be reviewing the requirements associated with the ICT Third-Party Risk Management of DORA, as well as elaborating a self-assessment checklist for financial entities to start assessing their compliance.

Information and Intelligence Sharing

DORA promotes information-sharing arrangements on cyber threat information and intelligence. This process is reflected in Chapter 6 of the regulation.

What is required?

DORA introduces guidelines on setting up information sharing arrangements between firms to exchange among themselves cyber threat information and intelligence on tactics, techniques, procedures, alerts and configuration tools in a trusted environment.

What do we consider as potential challenges for most organizations?

While, many organisations already have such agreements in place, such challenges might still emerge as: 

  • How will you determine what information to share? There should be a balance between helping the community and ensuring alignment with laws and regulations, as well as not sharing sensitive information with competition
  • How will you share this information efficiently?
  • What processes will you set up to consume the shared information by other entities?

Preparing yourself

In order to be ready, we recommend organisations take the following steps in 2021 and 2022:

  • Conduct a maturity assessment against the DORA requirements and define a mitigation plan to reach compliance.
  • Start consolidating the register of information for all ICT third-party providers.
  • Start defining a potential scenario for the large-scale penetration test.

About the Author

Nicolas is a consultant in the Cyber Strategy & Culture team at NVISO. He taps into his technical hands-on experiences as well as his managerial academic background to help organisations build out their Cyber Security Strategy. He has a strong interest IT management, Digital Transformation, Information Security and Data Protection. In his personal life, he likes adventurous vacations. He hiked several 4000+ summits around the world, and secretly dreams about one day hiking all of the top summits. In his free time, he is an academic teacher who has been teaching for 7 years at both the Solvay Brussels School of Economics and Management and the Brussels School of Engineering. 

Find out more about Nicolas on Linkedin.

DORA and ICT Risk Management: how to self-assess your compliance

2 December 2021 at 10:09

TL;DR – In this blogpost, we will give you an introduction to the key requirements associated with the Risk Management Framework introduced by DORA (Digital Operational Resilience Act); 

More specifically, throughout this blogpost we will try to formulate an answer to following questions:

  • What are the key requirements associated with the Risk Management Framework of DORA?
  • What are the biggest challenges associated with these requirements?
  • How can you prepare yourself and what are the actions that you should took in aligning your organization to the Risk Management Framework requirements?

In the following sections, we will share our thoughts on how to self-assess your compliance on this requirement. Note also that, if this self-assessment checklist is of interest to you, you will be able to find it in an excel format in our GitHub repository, here.  

What are the ICT Risk Management requirements?

DORA requires organizations to apply a strong risk-based approach in their digital operational resilience efforts. This approach is reflected in Chapter 2 of the regulation.

Chapter 2 – Section 1 – Risk management governance

The first part of Chapter 2 addresses the risk management governance requirements. They include, but are not limited to, setting roles and responsibilities of the management body, planning and periodic auditing.

This section states the responsibilities of the management body for the definition, approval, overseeing of all arrangements related to the ICT risk management framework.

This section also states the definition and attribution of the role of ICT third party Officer. This position shall be in charge of defining and monitoring all the arrangements concluded with ICT third-party service providers on the use of ICT services.

The following table provides a checklist for financial entities to self-assess their compliance on this requirement:

Article 4 Governance and organisation
Responsibilities of the management body The management body shall define, approve, oversee and be accountable for the implementation of all arrangements related to the ICT risk management framework.
ICT third party Officer The role of ICT third party Officer shall be defined to monitor the arrangements concluded with ICT third-party service providers on the use of ICT services 
Training of the management body The management body shall, on a regular basis, follow specific trainings related to ICT risks and their impact on the operations 

Chapter 2 – Section 2 – Risk management framework

The second part of Chapter 2 introduces the ICT risk management framework itself as a critical component of the regulation.

ICT risk management requirements form a set of key principles revolving around specific functions (identification, protection and prevention, detection, response and recovery, learning and evolving and communication). Most of them are recognized by current technical standards and industry best practices, such as the NIST framework, and thus the DORA does not impose specific standardization itself.

Before exploring the functions, let’s note that DORA specifies several governance mechanisms around the risk management framework. They include, but are not limited to, setting the objectives of the risk management framework, planning and periodic auditing.

The following table provides a checklist for financial entities to self-assess their compliance on these governance requirement:

Article 5 ICT risk management framework
Protecting physical elements Entities shall define a well-documented ICT risk management framework which shall include strategies, policies, procedures, ICT protocols and tools which are necessary to protect all relevant physical components and infrastructures
Information on ICT risks Entities shall minimise the impact of ICT risk by deploying appropriate strategies, policies, procedures, protocols and tools
ISMS Entities shall implement an information security management system based on recognized international standards
Three lines of defence  Entities shall ensure appropriate segregation of ICT management functions, control functions, and internal audit functions
Review The ICT risk management framework shall be reviewed at least once a year, as well as upon the occurrence of major ICT-related incidents
Improvement The ICT risk management framework shall be continuously improved on the basis of lessons derived from implementation and monitoring
Audit The ICT risk management framework shall be audited on a regular basis by ICT auditors 
Remediation Entities shall define a formal follow-up process for the timely verification and remediation of critical ICT audit findings
ICT risk management framework objectives The ICT risk management framework shall include the methods to address ICT risk and attain specific ICT objectives

Identification

Financial entities shall identify and classify the ICT-related business functions, information assets and supporting ICT resources based on which risks posed by current cyber threats and ICT vulnerabilities are identified and assessed.

The following table provides a checklist for financial entities to self-assess their compliance on the Identification requirement:

Article 7 Identification 
Asset Identification Entities shall identify and adequately document:
(a) ICT-related business functions
(b) Information assets supporting these functions
(c) ICT system configurations and interconnections with internal and external ICT systems
Asset Classification  Entities shall classify and adequately document:
(a) ICT-related business functions
(b) Information assets supporting these functions
(c) ICT system configurations and interconnections with internal and external ICT systems
Asset Classification Review  Entities shall review as needed, and at least yearly, the adequacy of the classification of the information assets 
ICT risks Identification and Assessment  Entities shall identify all sources of ICT risks, and assess cyber threats and ICT vulnerabilities relevant to their ICT-related business functions and information assets. 
ICT risks Identification and Assessment Review Entities shall regularly review the ICT risks Identification and Assessment yearly or upon each major change in the network and information system infrastructure
ICT mapping Entities shall identify all ICT systems accounts, the network resources and hardware equipment
(a) Entities shall map physical equipment considered critical
(b) Entities shall map the configuration of the ICT assets and the links and interdependencies between the different ICT assets. 
 ICT third-party service providers identification Entities shall identify all ICT third-party service providers
(a) Entities shall identify and document all processes that are dependent on ICT third-party service providers
(b) Entities shall identify interconnections with ICT third-party service providers.
 ICT third-party service providers identification review Entities shall regularly review the  ICT third-party service providers identification
Legacy ICT systems Entities shall on a regular basis, and at least yearly, conduct a specific ICT risk assessment on all legacy ICT systems

This ICT risk management framework shall include the identification of critical and important functions as well as the mapping of the ICT assets that underpin them. Moreover, this ICT risk management framework shall also include the assessment of all risks associated with the ICT-related business functions and information assets identified.

What to identify and assess? Well …

  • ICT-related business functions
  • Supporting information assets supporting these functions
  • ICT system configurations
  • Interconnections with internal and external systems
  • Sources of ICT risk
  • All ICT system accounts
  • Network resources and hardware equipment
  • Critical physical equipment
  • All processes dependent on and interconnections with ICT third-party service providers

Protection and Prevention

Financial entities shall (based on the risk assessment) set up protection and prevention measures to ensure the resilience, continuity and availability of ICT systems. These shall include ICT  security  strategies, policies,  procedures and appropriate technologies.

The following table provides a checklist for financial entities to self-assess their compliance on this requirement:

Article 8 Protection and Prevention 
CIA Entities shall develop and document an information security policy defining rules to protect the confidentiality, integrity and availability of theirs, and their customers’ ICT resources, data and information assets; 
Segmentation Entities shall establish a sound network and infrastructure management using appropriate techniques, methods and protocols including implementing automated mechanisms to isolate affected information assets in case of cyber-attacks
Access privileges Entities shall implement policies that limit the physical and virtual access to ICT system resources and data and establish to that effect a set of policies, procedures and controls that address access privileges
Authentication mechanisms Entities shall implement policies and protocols for strong authentication mechanisms and dedicated controls systems to prevent access to cryptographic keys 
ICT change management  Entities shall implement policies, procedures and controls for ICT change management including changes to software, hardware, firmware components, system or security changes. The ICT change management process shall be approved by appropriate lines of management and shall have specific protocols enabled for emergency changes. 
Patching Entities shall have appropriate and comprehensive policies for patches and updates

What does this entail?

  • Ensuring the resilience, continuity and availability of ICT systems
  • Ensuring the security, confidentiality and integrity of data
  • Ensuring the continuous monitoring and control of ICT systems and tools
  • Defining and implementing Information security policies such as
    • Limit physical and virtual access to ICT systems
    • Protocols on strong authentication
    • Change management
    • Patching / updates management

Detection

Financial entities shall continuously monitor and promptly detect anomalous activities, threats and compromises of the ICT environment.

The following table provides a checklist for financial entities to self-assess their compliance on this requirement:

Article 9 Detection 
Detect anomalous activities Entities shall have in place mechanisms to promptly detect anomalous activities
(a) ICT network performance issues
(b) ICT-related incidents
Detect single points of failure Entities shall have in place mechanisms to identify all potential material single points of failure
Testing All detection mechanisms shall be regularly tested 
Alert mechanism All detection mechanisms shall enable multiple layers of control
(a) Define alert thresholds
(b) Define criteria to trigger ICT-related incident detection
(c) Define criteria to trigger ICT-related incident response processes
(d) Have automatic alert mechanisms in place for relevant staff in charge of ICT-related incident response. 
Trade reports checking Entities shall have in place systems that can effectively check trade reports for completeness, identify omissions and obvious errors and request re-transmission of any such erroneous reports. 

What does this entail?

  • Ensure the prompt detection of anomalous activities
  • Enforce multiple layers of control
  • Enable the identification of single points of failure

Response and recovery (including Backup policies and recovery methods)

Financial entities shall put in place dedicated and comprehensive business continuity policies and disaster and recovery plans to adequately react to identified security incidents and to ensure the resilience, continuity and availability of ICT systems.

The following table provides a checklist for financial entities to self-assess their compliance on Response and recovery requirements:

Article 10 Response and recovery 
ICT Business Continuity Policy  Entities shall put in place a dedicated and comprehensive ICT Business Continuity Policy as an integral part of the operational business continuity policy  of the entity
ICT Business Continuity Mechanisms Entities shall implement the ICT Business Continuity Policy through appropriate and documented arrangements, plans, procedures and mechanisms aimed at:
(a) recording all ICT-related incidents ;
(b) ensuring the continuity of the entity’s critical functions;
(c) quickly, appropriately and effectively responding to and resolving all ICT-related incidents
(d) activating without delay dedicated plans that enable containment measures, processes and technologies, as well as tailored response and recovery procedures 
(e) estimating preliminary impacts, damages and losses;
(f) setting out communication and crisis management actions which ensure that updated information is transmitted to all relevant internal staff and external stakeholders, and reported to competent authorities 
ICT Disaster Recovery Plan Entities shall implement an associated ICT Disaster Recovery Plan
ICT Disaster Recovery Audit Review Entities shall define a process for the ICT Disaster Recovery Plan to be subject to independent audit reviews.  
ICT Business Continuity Test  Entities shall periodically test the ICT Business Continuity Policy, at least yearly and after substantive changes to the ICT systems;
ICT Disaster Recovery Test Entities shall periodically test the ICT Disaster Recovery Plan, at least yearly and after substantive changes to the ICT systems;
Testing Plans Entities shall include in the testing plans scenarios of cyber-attacks and switchovers between the primary ICT infrastructure and the redundant capacity, backups and redundant facilities 
Crisis Communication Plans Entities shall implement a crisis communication plan
Crisis Communication Plans Test Entities shall periodically test the crisis communication plans, at least yearly and after substantive changes to the ICT systems;
Crisis Management Function Entities shall have a crisis management function, which, in case of activation of their ICT Business Continuity Policy or ICT Disaster Recovery Plan, shall set out clear procedures to manage internal and external crisis communications 
Records of Activities Entities shall keep records of activities before and during disruption events when their ICT Business Continuity Policy or ICT Disaster Recovery Plan is activated. 
ICT Business Continuity Policy Communication When implementing changes to the ICT Business Continuity Policy, entities shall communicate those changes to the competent authorities
Test Communication Entities shall define a process to provide to the competent authorities copies of the results of the ICT business continuity tests
Incident Communication Entities shall define a process to report to competent authorities all costs and losses caused by ICT disruptions and ICT-related incidents

The following table provides a checklist for financial entities to self-assess their compliance on Backup policies requirements:

Article 11 Backup policies and recovery methods 
Backup Policy Entities shall develop a backup policy
(a) specifying the scope of the data that is subject to the backup
(b) specifying the minimum frequency of the backup
(c) based on the criticality of information or the sensitiveness of the data
Backup Restoration When restoring backup data using own systems, entities shall use ICT systems that have an operating environment different from the main one, that is not directly connected with the latter and that is securely protected from any unauthorized access or ICT corruption
Recovery Plans Entities shall develop a recovery plans which enable the recovery of all transactions at the time of disruption to allow the central counterparty to continue to operate with certainty and to complete settlement on the scheduled date
Recovery Methods Entities shall develop recovery methods to limit downtime and limited disruption
ICT third-party providers Continuity Entities shall ensure that their ICT third-party providers maintain at least one secondary processing site endowed with resources, capabilities, functionalities and staffing arrangements sufficient and appropriate to ensure business needs
ICT third-party providers secondary processing site Entities shall ensure that the ICT third-party provider secondary processing site is:
(a) located at a geographical distance from the primary processing site
(b) capable of ensuring the continuity of critical services identically to the primary site
(c) immediately accessible to the entity’s staff to ensure continuity of critical services 
Recovery time objectives Entities shall determine recovery time and point objectives for each function. Such time objectives shall ensure that, in extreme scenarios, the agreed service levels are met
Recovery checks When recovering from an ICT-related incident, entities shall perform multiple checks, including reconciliations, in order to ensure that the level of data integrity is of the highest level

How to meet the compliance on the Response and Recovery requirements?

  • Define and implement an ICT Business Continuity Policy
  • Define and implement an ICT Disaster Recovery Plans
  • Define and implement an Back-up policies
  • Develop recovery methods
  • Determine flexible recovery time and point objectives for each function

Developing response and recovery strategies and plans adds an additional level of complexity, as it will require financial entities to think carefully about substitutability, including investing in backup and restoration systems, as well as assess whether – and how – certain critical functions can operate through alternative systems or methods of delivery while primary systems are checked and brought back up.

Learning and evolving

Financial entities shall include continuous learning and evolving in the internal processes in the form of information-gathering, as well as post-incident review and analysis.

The following table provides a checklist for financial entities to self-assess their compliance on this requirement:

Article 12 Learning and evolving 
Risk landscape Entities shall gather information on vulnerabilities and cyber threats, ICT-related incidents, in particular cyber-attacks, and analyse their likely impacts on their digital operational resilience.
Post ICT-related incident reviews  Entities shall put in place post ICT-related incident reviews after significant ICT disruptions of their core activities
(a) analysing the causes of disruption
(b) identifying required improvements to the ICT operations or within the ICT Business Continuity Policy  
Post ICT-related incident reviews mechanism Entities shall ensure the post ICT-related incident reviews determines whether the established procedures were followed and the actions taken were effective
(a) the promptness in responding to security alerts and determining the impact of ICT-related incidents and their severity;
(b) the quality and speed in performing forensic analysis;
(c) the effectiveness of incident escalation within the financial entity;
(d) the effectiveness of internal and external communication 
Lessons learned from the ICT Business Continuity and ICT Disaster Recovery tests Entities shall derive lessons from the ICT Business Continuity and ICT Disaster Recovery tests. Lessons shall be duly incorporated on a continuous basis into the ICT risk assessment process
Lessons learned reporting Senior ICT staff shall report at least yearly to the management body on the findings derived from the lessons learned from the ICT Business Continuity and ICT Disaster Recovery tests
Monitor the effectiveness of the implementation of the digital resilience strategy Entities shall map the evolution of ICT risks over time, analyse the frequency, types, magnitude and evolution of ICT-related incidents, in particular cyber-attacks and their patterns, with a view to understand the level of ICT risk exposure and enhance the cyber maturity and preparedness of the entity
ICT security awareness programs  Entities shall develop ICT security awareness trainings as compulsory modules in their staff training schemes
Digital operational resilience training Entities shall develop ICT digital operational resilience trainings as compulsory modules in their staff training schemes 

What does this entail?

  • Ensure information gathering on vulnerabilities and cyber threats
  • Ensure post-incident reviews after significant ICT disruptions
  • Define a procedure for the analysis of causes of disruptions
  • Define a procedure for the reporting to the management body
  • Develop ICT security awareness programs and trainings

Developing an ICT security awareness programs and trainings adds another level of complexity, as DORA does not only introduces compulsory training on digital operational resilience for the management body, DORA also introduces it for the whole staff, as part of their general training package. 

Communication

Financial entities shall define a communication strategy, plans and procedures for communicating ICT-related incidents to clients, counterparts and the public

The following table provides a checklist for financial entities to self-assess their compliance on this requirement:

Article 13 Communication 
Clients and counterparts communication Entities shall have in place communication plans enabling a responsible disclosure of ICT-related incidents or major vulnerabilities to clients and counterparts as well as to the public, as appropriate. 
Staff communication Entities shall implement communication policies for staff and for external stakeholders.
(a) Communication policies for staff shall take into account the need to differentiate between staff involved in the ICT risk management, in particular response and recovery, and staff that needs to be informed. 
Mandate At least one person in the entity shall be tasked with implementing the communication strategy for ICT-related incidents and fulfil the role of public and media spokesperson for that purpose. 

What does this entail?

  • Develop communication plans to communicate to clients, counterparts and the public
  • Mandate at least one person to implement the communication strategy for ICT-related incidents

I hope you found this blogpost interesting.

Keep an eye out for the following parts! This blog post is part of a series. In the following blogposts, we will further explore the requirements associated with the Incident Management process, the Digital Operational Resilience Testing and the ICT Third-Party Risk Management of DORA.

About the Author

Nicolas is a consultant in the Cyber Strategy & Culture team at NVISO. He taps into his technical hands-on experiences as well as his managerial academic background to help organisations build out their Cyber Security Strategy. He has a strong interest IT management, Digital Transformation, Information Security and Data Protection. In his personal life, he likes adventurous vacations. He hiked several 4000+ summits around the world, and secretly dreams about one day hiking all of the top summits. In his free time, he is an academic teacher who has been teaching for 7 years at both the Solvay Brussels School of Economics and Management and the Brussels School of Engineering. 

Find out more about Nicolas on Linkedin.

  • There are no more articles
❌