DORA Regulation. A guide to compliance, strategy, policy, and governance.

Wondering how you can ensure compliance in your organisation with DORA? We’ve prepared a practical guide divided into 17 parts for legal and security departments. This will help you plan how to prepare your financial organisation for the changes that come with the DORA (Digital Operational Resilience Act) Regulation, which is a new document from the European Union about digital finance.

What is the DORA regulation?

Passed at the end of 2022, the Digital Operational Resilience Act (DORA) Regulation is part of the Digital Finance Package (DFP). The package, presented by the European Commission, includes a digital finance strategy, legislative proposals on crypto assets and cyber resilience, and a renewed retail payments strategy.

Which piece of legislation has priority: DORA or NIS 2?

The Directive on measures for a high common level of cybersecurity across the Union, or NIS 2, was adopted at the same time as DORA tightened cybersecurity requirements in European Union countries, including those for the financial sector.

DORA clarifies and adds more details to NIS 2. It is classified as a “lex specialis” within NIS 2, based on the principle that specific law prevails over general law.

“Consequently, this Regulation constitutes lex specialis with regard to Directive (EU) 2022/2555. At the same time, it is crucial to maintain a strong relationship between the financial sector and the Union horizontal cybersecurity framework as currently laid out in Directive (EU) 2022/2555” — The Recital 16, DORA.

What is the purpose of the DORA regulation?

The objective of DORA is stated in Recital 105, which serves as the preamble preceding the legislation and clarifies its motivations: “to attain a high level of digital operational resilience for regulated financial entities.”

What does “digital operational resilience” mean? According to the text of DORA, it means:“‘Digital operational resilience’ means the ability of a financial entity to build, assure and review its operational integrity and reliability by ensuring, either directly or indirectly through the use of services provided by ICT third-party service providers, the full range of ICT-related capabilities needed to address the security of the network and information systems which a financial entity uses, and which support the continued provision of financial services and their quality, including throughout disruptions;” — The wording of DORA, Article 3(1).

Prevention is better than cure

What does the word “digital operational resilience” really mean? Financial entities need to be able to prevent threats as well as defend themselves. Reliability and integrity of financial services are the real challenge with DORA. The financial industry needs to protect its data, software, and hardware, but it’s not enough. Defence serves a higher purpose in DORA: resilience.

When does DORA enter into force?

The DORA regulation will enter into effect on January 17, 2025, which is 24 months after it was published in the official journal of the European Union. The time frame is specified in Article 64.

EUN and ENISA: Clarification of regulatory technical standards in early 2024

You may notice that some policies and procedures introduced by DORA were not clear in 2023. Nevertheless, they should become clearer in early 2024.

Article 15 requires the European Supervisory Authorities (ESAs) and the European Union Agency for Cybersecurity (ENISA) to work together and submit proposed regulatory technical standards (RTS) by January 17, 2024. These have been published as a set of principles under DORA on ICT and third party risk management and incident classification.

These standards aim to clarify the activities outlined in DORA, covering specifics within ICT response and recovery plans, as well as the testing of business continuity plans for ICT-related processes.

Nevertheless, the regulation in itself, with its comprehensiveness, defines many tasks to be accomplished, so it makes sense to start taking action as soon as possible.

DORA compliance: a 17-step action plan

The regulation is structured in such a way that it indicates the steps you need to take to achieve ‘digital operational resilience’ in your organisation according to DORA. The steps indicated in the regulation can be broken down into 17 areas that will help you structure your work to ensure compliance with the document.

The proposed list identifies the most important areas of DORA that need to be analysed in the context of your organisation’s digital resilience strategy and ICT compliance assessment.

1. Learn whether DORA applies to your organisation

Before you start work to comply with DORA, you should check whether the company you work for is covered by its provisions. The Regulation on Digital Operational Resilience of the Financial Sector applies to 21 types of entities. These are described in Article 2:

• credit institutions
• payment institutions, including payment institutions exempted pursuant to Directive (EU) 2015/2366
• account information service providers
• electronic money institutions, including electronic money institutions exempted pursuant to Directive 2009/110/EC
• investment firms
• crypto-asset service providers as authorised under a Regulation of the European Parliament and of the Council on markets in crypto-assets, and amending Regulations (EU) No 1093/2010 and (EU) No 1095/2010 and Directives 2013/36/EU and (EU) 2019/1937 (‘the Regulation on markets in crypto-assets’) and issuers of asset-referenced tokens
• central securities depositories
• central counterparties
• trading venues
• trade repositories
• managers of alternative investment funds
• management companies
• data reporting service providers
• insurance and reinsurance undertakings
• insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries
• institutions for occupational retirement provision
• credit rating agencies
• administrators of critical benchmarks
• crowdfunding service providers
• securitisation repositories
• ICT third-party service providers.

DORA: list of exceptions

The scope of DORA is exempted from certain entities under Article 2(3) Check out the list to see if you belong to this category.

Excluded from the scope of DORA are:

• managers of alternative investment funds as referred to in Article 3(2) of Directive 2011/61/EU
• insurance and reinsurance undertakings as referred to in Article 4 of Directive 2009/138/EC
• institutions for occupational retirement provision which operate pension schemes which together do not have more than 15 members in total
• natural or legal persons exempted pursuant to Articles 2 and 3 of Directive 2014/65/EU
• insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries which are microenterprises or small or medium-sized enterprises
• post office giro institutions as referred to in Article 2(5), point (3), of Directive 2013/36/EU.

Certain specific entities referred to in Article 2(5) of Directive 2013/36/EU may be excluded from the scope of DORA by the Member States.

2. Learn details about the requirements specified by DORA

As we mentioned earlier, the goal of DORA is to improve the digital operational resilience of financial entities. To this end, Article 1 defines specific requirements for network and information system security, namely:

• Requirements applicable to financial entities concerning:
  • managing risks associated with the use of information and communications technology (ICT);
  • reporting serious ICT incidents to the competent authorities and voluntarily informing them of significant cyber threats;
  • reporting of serious operational incidents or serious security incidents related to payments to the competent authorities by financial entities;
  • testing digital operational resilience;
  • sharing information and analysis in connection with cyber threats and vulnerabilities in this area;
  • measures for sound risk management by third-party ICT service providers.
• Requirements for contractual arrangements between third-party ICT service providers and financial entities;
• Principles for the establishment and operation of a supervisory framework for key external ICT service providers providing services to financial entities;
• Rules for cooperation between competent authorities, and rules for supervision and enforcement by competent authorities on all matters covered by this Regulation.

As you might expect, these requirements are the focus of the rest of this article.

3. Create an information technology (ICT) risk management framework

DORA emphasises the absolute necessity of having an ICT risk management framework.

“Financial entities shall have a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system, which enables them to address ICT risk quickly, efficiently and comprehensively and to ensure a high level of digital operational resilience.” — DORA, Article 6(1)

As defined, ICT risk means:“any reasonably identifiable circumstance in relation to the use of network and information systems which, if materialised, may compromise the security of the network and information systems, of any technology dependent tool or process, of operations and processes, or of the provision of services by producing adverse effects in the digital or physical environment.” — DORA, Article 3(5)

DORA: protection of software, hardware, and data

The framework has to provide details on the measures introduced to protect the organisation’s information and ICT assets. Again, Article 3 provides their definition:

• “information resource” means a collection of information, in tangible or intangible form, that is worth protecting;
• “ICT resource” means software or computer resources on the network and information systems used by a financial entity.

In other words, financial sector representatives must protect not only the organisation’s software and physical hardware (servers, terminal equipment, etc.) but also the data.

What should be included in an ICT risk management framework?

According to Article 6, a mandatory ICT risk management framework must include at least:

• ICT strategies, policies, procedures, protocols, and tools necessary to protect:
  • all information and ICT assets, including software, hardware, servers, etc;
  • all physical components and infrastructures related to the protection of these assets, such as premises or data centres.

It can be said that DORA works like a matrioshka because it is made up of many policies. These policies are made up of various documents and procedures on topics ranging from business continuity to recovery plans.

It should be noted that a financial entity whose operation is regulated by DORA must keep records available to the competent authorities, who may request access to them. They may also request a report on reviewing the ICT risk management documentation, which takes us to the next point.

Update the documentation at least once a year

What cannot happen is that the policies and procedures required by DORA have been prepared and shelved. Documents must be updated at least once a year (or periodically for micro-enterprises);

• or in the event of a major ICT incident
• or based on decisions of supervisory instructions
• or conclusions resulting from relevant digital operational resilience tests
• or audit processes.

Implementing an ISMS with DORA in mind

Implementing an Information Security Management System (“ISMS”) is crucial to bolster the risk management area introduced by DORA. A systems approach facilitates the organisation’s information security management and mitigates risks associated with ICT.

ISO 27001 standard

NIS 2 suggests a future European certification framework for cyber security. However, until these are introduced, the international ISO 27001 standard remains the main reference for creating an ISMS. Obtaining ISO 27001 certification is time-consuming and labour-intensive, so it should be one of the priorities of any information security professional (e.g. CISO, head of security) dealing with DORA.

Simplified ICT risk management structure for designated entities

As per DORA’s Article 16, some organisations can apply a ‘simplified ICT risk management structure’.

This represents an updated version of the obligatory governance structure mandated by the Regulation.

Here is the list of entities entitled to the simplified structure:

• small and non-related investment firms, 
• payment institutions exempt under Directive (EU) 2015/2366; 
• institutions exempted under Directive 2013/36/EU for which the Member States have decided not to make use of the option referred to in Article 2(4) of this Regulation; 
• electronic money institutions exempt under Directive 2009/110/EC; and 
• small occupational pension institutions — those that operate pension schemes with a total number of members below 100.

4. Audit the ICT risk management framework regularly

Article 6(6) of the ICT risk management framework requires regular internal audit by the auditors. It’s important to make a clear distinction between managing risks in information and communication technology, controlling it, and checking it internally. To achieve this objective, Article 6(4) of the DORA recommends that financial institutions adopt the Three Lines of Defence (3LoD) model.

Adopt the Three Lines of Defence model

The 3LoD model allows for an organisational separation of responsibility and risk management. In practice:

• The first line of defence is the operational teams, the people who handle the objects of risk analysis. They are responsible for simplifying risk management for subsequent lines, considering risk factors. For the development team, for example, this could mean clearly defining each person’s responsibilities or adopting a culture of cyber security in the project, using secure development methods.
• The second line of defence is the risk management and compliance functions, such as the CISO. The second line is responsible for controlling the first. This includes creating monitoring processes, implementing the entity’s overall risk management strategy or ensuring that all areas of the company are operating in accordance with risk management policies; for example: in departments such as HR, sales, marketing or human resources.
• The third line of defence is the independent internal auditors. They must ensure that the defences put in place by the previous two lines are sufficiently strong. In other words, their task is to holistically audit the risk management in place. The auditors must verify the processes and their proper execution and then produce detailed audit reports. It is also understood that DORA clarifies that internal auditors must have ‘sufficient knowledge, skills, and expertise’ in ICT risk management.

How to avoid conflicts of interest? DORA answers this issue and states that organisations must ensure “adequate separation and independence of the ICT risk management function, the control function, and the internal audit function.” Each line must have its distinct characteristics to achieve a successful implementation of the 3LoD model. This is especially critical for the last line.

It is difficult to detail a one-size-fits-all 3LoD model that can be replicated everywhere, as it must be closely related to each organisation’s operations, structure, and functions. Several sources on the Internet can help in this regard. The latest model from the IIA (Institute of Internal Auditors) provides a good starting point.

Entity responsibility (including external suppliers and outsourcing) 

DORA permits both external and internal entities to perform ‘tasks to verify compliance with ICT risk management requirements.’ However, the financial entity remains fully responsible for this verification. In other words, there is no possibility that the responsibility can be transferred to the supplier, it always rests with the principal.

5. Define a digital operational resilience strategy

A digital operational resilience strategy is needed for an ICT risk management framework. These two concepts are a polar opposite of each other: while the risk management framework employs a comprehensive approach, the resilience strategy employs a practical approach. The plan should outline the strategies employed to manage the dangers and attain the specified goals.

According to Article 6(8), the resilience strategy must:

• explain how the ICT risk management framework supports the business strategy and business objectives of the financial entity;
• establish a risk tolerance limit for ICT risks, in line with the financial entity’s risk appetite, and analyse the impact tolerance of ICT disruptions;
• set out clear information security objectives, including key performance indicators and key risk indicators;
• explain the reference ICT architecture and any changes needed to achieve specific business objectives;
• outline the various mechanisms in place to detect, prevent and protect against ICT incidents;
• document the current situation of digital operational resilience based on the number of major ICT incidents reported and the effectiveness of preventive measures;
• implement testing of operational digital resilience, under Chapter 4 of the Regulation;
• outline a communication strategy for ICT incidents required to be disclosed under Article 14.

Depending on the scale of cooperation with external parties, you could have a single overall strategy that applies to multiple providers. The strategy should then explain the reasoning behind this choice and detail the key dependencies on different suppliers.

Monitoring and improving the effectiveness of the strategy over time

Financial institutions are obligated by Article 13 to oversee the efficacy of their digital operational resilience strategy.

This means tracking how ICT risks have changed over time and figuring out how often, what kind of incidents happen, how big they are, and how long they last. Cyber attacks and their corresponding patterns are monitored to comprehend the evolution of the entity’s risk exposure, particularly for crucial and essential functions.

The strategy should be continuously improved based on lessons learned from:

• mandatory reviews following a major incident;
• difficulties encountered during the activation of business continuity and response and recovery plans;
• cyber threat monitoring and information sharing arrangements;
• operational resilience testing.

A report to the entity’s governing body at least once a year (under Article 13(5)). This should include the results of the analysis described above, as well as recommendations.

6. Implementing asset protection and resilience mechanisms

How should a resilience strategy be structured? It should detail the different mechanisms implemented to identify ICT incidents, mitigate their effects, and offer protection against them. You are responsible for implementing the right procedures and resources.

Minimum requirements for asset protection and resilience

To protect assets under Article 9, solutions and processes must, as a minimum:

• ensure the security of the means of transferring data;
• minimise the risk of data corruption or loss, unauthorised access and technical failures that may impede business operations;
• prevent lack of availability, undermining of authenticity and integrity, breaches of confidentiality and data loss;
• ensure that data is protected against data management risks, including those related to mismanagement, processing and human error.

To prevent cyber attacks, the network infrastructure must be designed to be immediately disconnected or segmented, especially in the case of interconnected operational processes. In other words, in the event of problems, the team should be able to shut down the network at short notice.

The growing number of policies to be implemented

Financial entities also need to document:

• an information security policy outlining policies to protect the availability, authenticity, integrity, and confidentiality of assets and data, including customer data, if applicable;
• policies restricting access (physical or logical) to assets and data based on functions and roles;
• policies and protocols for strong authentication mechanisms and encryption key protection measures;
• ICT change management policies, procedures and controls, including changes to software, hardware, firmware components, systems, or security parameters. These should be based on a risk-based approach and be an integral part of the organisation’s overall change management process. The ICT change management process must be approved by the relevant decision-making body;
• appropriate and comprehensive documented policies for implementing patches and updates.

7. Implementing threat detection solutions

Proper asset protection requires the ability to detect anomalies, incidents and cyber attacks. This means having EDR (Endpoint Detection and Response), XDR (Extended Detection and Response), scanners, SIEM (Security Information and Event Management), etc. As per Article 10 of the DORA, financial entities are required to dedicate adequate resources and capabilities for this objective.

To meet the requirements of the Regulation, detection mechanisms must:

• enable multi-level control, define alert thresholds and trigger criteria and initiate incident response processes, including automatic alert mechanisms for relevant staff (for example, the SOC — Security Operations Centre);
• be regularly tested.

8. Develop an ICT business continuity policy

The DORA regulation imposes the task:

“Financial entities shall put in place a comprehensive ICT business continuity policy, which may be adopted as a dedicated specific policy, forming an integral part of the overall business continuity policy of the financial entity.” — the wording of DORA, Article 11.

The ICT business continuity policy must enable:

• continuity of critical or essential functions of the financial entity;
• rapid and effective response to all ICT incidents in a manner that limits damage and prioritises business resumption and recovery activities;
• activation of dedicated plans to contain each type of incident and prevent further damage, as well as appropriate response and recovery procedures;
• assessment of initial impact, damage, and losses;
• appropriate crisis management and internal communication measures for teams affected by third parties and relevant authorities.

Test business continuity plans at least once a year

Plans must be documented but also tested for effectiveness. Article 11(6) directs financial entities to test:

• ICT business continuity plans and ICT response and recovery plans:
  • at least once a year;
  • and in the event of significant changes to ICT systems supporting critical or essential functions.
• As well as crisis communication plans.

Testing of plans must consider cyber attack scenarios and switch between the main ICT infrastructure and redundant resources, backups and redundant facilities required by DORA.

Keep a record of actions in case of disruption

If the aforementioned plans are activated, financial entities must keep “readily available records of activities carried out before and during disruptions” under Article 11(8). The total annual expenses and losses incurred as a result of major incidents must be estimated by organisations if requested by the appropriate authorities.

9. Providing backup, restore, and recovery procedures (and related policies)

The DORA regulation aims to minimise disruption and downtime to systems and data processing. Specifically, this means three workflows: backup, restore and recovery. These are broken down into different policies that form part of the ICT business continuity policy.

Therefore, financial units need to have in place:

• backup policies and procedures that define:
  • the scope of data to be backed up;
  • and the minimum frequency of backups, depending on the criticality of the information or the level of confidentiality of the data;
• restoration and recovery procedures and methods.

The initiation of a backup restore should not affect the availability, authenticity, integrity, or confidentiality of the data. This implies no downtime of services during system restoration. In addition, DORA (Article 12(4)) makes redundancy of ICT capabilities mandatory. These must be duplicated to ensure a smooth transition in the event of failure of the original system.

In the context of restoration, an entity must ensure that its resources are physically and logically separated from the source system.

Finally, all backup, restore, and recovery procedures must be regularly tested under Article 12(2).

Some of these guidelines don’t apply to small businesses or can be assessed based on their risk profile. Central CSDs are, however, subject to additional requirements, such as having a second processing site. Article 12(5) explains this.

10. Prepare crisis communication plans

Article 14 of DORA clarifies the responsibilities of financial entities concerning communication during incidents.

“Financial entities shall have in place crisis communication plans enabling a responsible disclosure of, at least, major ICT-related incidents or vulnerabilities to clients and counterparts as well as to the public, as appropriate.” — DORA, Article 14(1)

Aside from environmental outreach strategies, organisations should also have strategies for internal operations and interactions with outside parties. During an incident, the internal communication policy should distinguish between the following:

• the employees who need to be informed of the incident;
• and employees who are actively involved in ICT risk management, especially in response and recovery.

Appoint a person responsible for crisis communication

DORA requires that at least one person be designated to manage the issue of crisis communication. It is a good idea to liaise with the legal, communications, and marketing teams on the attitude adopted and the processes to be implemented.

“At least one person in the financial entity shall be tasked with implementing the communication strategy for ICT-related incidents and fulfil the public and media function for that purpose.” — DORA, Article 14(3)

11. Establish an incident management process 

For DORA, financial entities are required to implement an ICT incident management process. It influences the ICT business continuity policy and resilience strategy, which themselves form part of the ICT risk management framework.

DORA: Obligation to register all incidents

The process is not an end in itself: it must record all relevant cyber threats and all recorded incidents.

According to Article 17, the incident management process includes:

• the introduction of early warning indicators;
• establishing procedures to identify, track, record, categorise and classify ICT incidents according to their priority and severity and the criticality of the services affected by the incidents;
• assigning roles and responsibilities to be put in place for different types of ICT incidents and relevant scenarios;
• defining plans for outreach to employees, external stakeholders and the media, as well as plans for customer notification, plans for internal escalation procedures, including ICT-related customer complaints, as well as the provision of information to financial entities acting as counterparties, where appropriate;
• ensuring that, as a minimum, serious ICT incidents are reported to the relevant senior management and that, as a minimum, serious ICT incidents are reported to the governing body, together with an explanation of the impact, response and additional controls to be established as a result of such ICT incidents;
• establishing procedures for responding to ICT incidents to mitigate the impact and ensure that services are restored to operational and secure status within a reasonable timeframe.

Classification of incidents under DORA

Under Article 18 of DORA, financial entities must classify incidents based on the following criteria:

1. the number or importance of financial customers or counterparties and, where applicable, the amount or number of transactions affected by the ICT incident and whether such incident has caused reputational effects;
2. the duration of the ICT incident, including interruption of services;
3. the geographical scope of the ICT incident, in particular, if more than two Member States are involved;
4. the loss of data as a result of the ICT incident in terms of data availability, authenticity, integrity, or confidentiality;
5. the criticality of the services affected by the ICT incident, including transactions and operations of the financial entity;
6. the economic impact of the ICT incident, in particular direct and indirect costs and losses, both in absolute and relative terms.

Organisations must also determine whether a cyber threat is significant, based on a similar list as above.

DORA establishes general guidelines for classifying incidents, but the exact thresholds within the document are unclear. The definitions were established by the European Supervisory Authorities, the ECB and ENISA on 17 January 2024 in the form of regulatory technical standards describing a set of principles under DORA on ICT and third-party risk management and incident classification.

Mandatory reviews after an incident

Article 13 requires organisations to conduct mandatory reviews after a major incident disrupting their core business.

These reviews must determine:

• whether established procedures have been followed;
• and whether they were effective in terms of:
  • the speed with which they responded to security alerts and determined the impact and severity of the incident;
  • the quality and speed of forensic analysis;
  • the effectiveness of the escalation of incidents within the financial entity;
  • effectiveness of internal and external communications.

Changes made as a result of post-incident reviews should be shared with the relevant authorities.

12. Write an incident response plan

Writing (or revising) an incident response plan (IRP) is one of the first things you should do to improve your handling of incidents. This will come in particularly useful when dealing with partners, customers or other authorities.

There exist numerous valuable resources accessible online for the creation of an IRP. It needs to adhere to the response obligations imposed by DORA, which brings us to the next point.

Find out which competent authority you should report to

Firstly, it’s important to highlight that competent authorities vary for different financial entities, making it impractical to provide comprehensive details here. Therefore, we direct your attention to Article 46 of DORA, aptly titled “Competent Authorities,” which will offer clarity regarding your specific circumstances. It’s worth noting that the principle of proportionality discussed earlier applies in this context as well. In cases where a financial entity is subject to multiple national authorities, the State will need to determine which one takes precedence.

In addition, as per Article 19(1), States have the authority to require a double reporting duty from some or all of the financial organisations under their control:

• to the competent authority under DORA;
• but also to competent authorities or Computer Security Incident Response Centres (CSIRTs) designated under NIS 2.

This is not mandatory, but possible. It is therefore up to each entity to verify its situation.

Information responsibilities to the relevant authority

You should already be aware of the competent authority you are dealing with. When to reach out to it is still a question.

In the event of a serious incident, Article 19(4) states that financial institutions are obligated to submit to the appropriate authority.

• an initial notification;  
• an interim report as soon as the status of the original incident has changed significantly or the handling of the serious incident has changed based on new information available
  • an updated notification whenever a relevant status update is available and when specifically requested by the competent authority;
• a final report, once the root cause analysis has been completed, regardless of whether mitigation measures have already been implemented, and when actual impact data is available to replace estimates.

The financial sector is also allowed to disclose material cyber threats to the appropriate regulatory body on their initiative, provided they believe they relate to the financial system, service users, or customers.

The DORA Regulation allows reporting obligations to be outsourced to an external service provider — see Article 19(5). The financial entity is still responsible for complying with its requirements. The provider is not to blame in this instance.

What are the timeframes for DORA-related information responsibilities?

The timeframes applicable to individual notifications were established by the European Supervisory Authorities, the ECB and ENISA on 17 January 2024 in the form of regulatory technical standards describing a set of principles under DORA on ICT and third-party risk management and incident classification.

Information responsibilities towards customers

DORA imposes obligations to notify not only competent authorities but also customers. This is set out in the passage:

“Where a major ICT-related incident occurs and has an impact on the financial interests of clients, financial entities shall, without undue delay as soon as they become aware of it, inform their clients about the major ICT-related incident and about the measures that have been taken to mitigate the adverse effects of such incident.

In the case of a significant cyber threat, financial entities shall, where applicable, inform their clients that are potentially affected of any appropriate protection measures which the latter may consider taking.”

— DORA, Article 19(3)

Customer outreach will, of course, need to be based on crisis communication plans, which we discussed in Section 10.

13. Watch out for cyber threats

It would be a mistake to underestimate attackers’ creativity in order to achieve their goals. That’s why Compliance and Security departments (CCOs, CISOs) need to be aware of the changing landscape of cyber threats. Monitoring must be persistent, collective, and continuous.

The topic of cyber intelligence is covered by DORA in Article 13. The document states that financial institutions require the capacity and personnel to collect data on their online weaknesses and threats. The impact of new solutions on cyber security and digital operational resilience requirements must be monitored continuously.

Annual report on major incidents in the financial sector published by ESA

The provisions of Article 22 of the DORA mandate the ESA to produce an annual, anonymised, and consolidated report on significant ICT incidents. Information about the number of major incidents, their nature and impact, the remediation steps taken, and the financial implications should be included in the report. Warnings and ‘high-level statistics’ will also be included.

The annual report will be one of the most important documents for cyber security teams in the financial sector.

Establish rules for the exchange of information between financial entities on cyber threats

Financial cooperation is encouraged by DORA. Chapter 6 says that financial companies can exchange information with each other about cyber threats, like signs that someone might be hacked, how to avoid being hacked, and what to do.

Such information sharing between financial institutions should:

• aim to enhance the digital operational resilience of financial entities;
• take place in trusted groups of financial entities;
• be based on mechanisms that protect the potentially sensitive nature of the information shared.

These exchanges should be conducted with full respect for business confidentiality, GDPR and competition policy guidelines. Sharing arrangements must set out the specific modalities of sharing (where, how?). This means that both financial institutions and public authorities and ICT service providers must follow certain rules when they want to participate.

In addition, any financial entity, regardless of its participation in such a scheme, must notify the relevant authorities of the event. 

14. Perform operational digital resilience testing

DORA devotes an entire Chapter 4 to operational digital resilience testing.

It should be noted that most of these requirements do not apply to micro-enterprises. If this is the case for you, we invite you to read Chapter 4 (especially Article 25(3)) to determine which points apply to your case.

Map your information system

Before testing your digital assets, you need to identify them. Without mapping your entire IT environment, it is not possible to conduct an effective test. This is an obligation under DORA, as it is a mandatory part of the ICT risk management framework. This step allows you to:

• have a high-level view of your organisation’s assets;
• then classify them according to criticality and risk level.

An operational digital resilience survey should be performed at least once a year

In the words of DORA, financial entities shall ensure “at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions.” (Article 24(6)).

These evaluations are structured within a digital operational resilience testing program, which is expected to adopt a risk-based approach. This program should encompass various assessments, tests, methodologies, practices, and tools.

Article 25 of DORA defines some typologies of testing, such as:

• vulnerability assessments and scans
• open source analyses
• network security assessments
• gap analyses
• physical security reviews
• questionnaires and scanning software solutions
• source code reviews where feasible
• scenario-based tests
• compatibility testing
• performance testing
• end-to-end testing
• and penetration testing

Testing can be done either internally or by third-party providers. Financial entities should allocate sufficient resources to the test if it is done by an internal tester, and they should make sure there are no conflicts of interest in the design and execution of the test.

DORA: obligation to respond to identified vulnerabilities and security remediation

It is useless to detect security vulnerabilities if they are not later patched. The repair of all vulnerabilities discovered during testing is formalised by DORA:

“Financial entities, other than microenterprises, shall establish procedures and policies to prioritise, classify and remedy all issues revealed throughout the performance of the tests and shall establish internal validation methodologies to ascertain that all identified weaknesses, deficiencies or gaps are fully addressed.”

— DORA, Article 24(5)

This means that even ‘low’ or ‘medium’ vulnerabilities cannot be overlooked. The remediation must be complete. This is a topic that must be addressed in collaboration with the development teams, the CIO and another relevant manager.

Give the team time to patch 

Patching vulnerabilities needs to be incorporated into the IT teams’ schedule. It is not an ‘extra’ task that should be completed during the developer’s spare time.

The most critical vulnerabilities must be addressed immediately, but others can be addressed during a periodic or weekly check, depending on the number of teams involved. Whichever approach you choose, it is important to realise that patching security vulnerabilities is at least as important as developing new features.

Encourage the use of secure system development methods

Cyber security in the design phase is a topic that is discussed widely and for good reason. It is essential to consider the security of products and services from the very beginning. This is the approach recommended by NIS 2, but also the EU Cyber Security Act of June 2019. 

Of course, CISOs cannot be expected to train development teams in secure programming practices. Nevertheless, nothing is stopping them from going one step further and making people aware of the issue. This is an issue that can be pursued with CTOs of SOC teams, or internal security experts. From training courses to workshops and CTF (Capture The Flag) opportunities abound.

15. Create a penetration testing plan 

In the previous section, we discussed the ‘traditional’ testing that all DORA entities are responsible for each year. However, some organisations are subject to additional testing requirements, also known as ‘threat-based penetration testing’ (TLPT).

Which entities are subject to advanced security testing?

It all depends on the competent authorities. Article 26(8) of DORA requires them to “identify the financial entities that are required to perform TLPTs […] based on an assessment”:

• impact factors, in particular, the extent to which the services provided and actions taken by the financial entity have an impact on the financial sector;
• possible financial stability concerns, including the systemic nature of the financial entity at the EU or national level, as appropriate;
• the specific risk profile associated with ICT, and the level of sophistication of the financial entity in terms of ICT or technology solutions used.

Competent authorities should apply the principle of proportionality when deciding on entities subject to advanced testing.

What is a penetration test based on threat scenarios?

The official definition given by DORA:

“threat-led penetration testing (TLPT)’ means a framework that mimics the tactics, techniques and procedures of real-life threat actors perceived as posing a genuine cyber threat, that delivers a controlled, bespoke, intelligence-led (red team) test of the financial entity’s critical live production systems;”

— DORA, Article 3(17)

Mandatory criteria for a threat scenario-based penetration test

The official definition explains the concept, but not the technical details. Fortunately, Article 26 sets out some mandatory criteria for a threat-based penetration test:

• The test must “cover several or all critical or important functions” of the financial entity;
• The scope is defined by the entity itself, but approved by the competent authorities;
  • If the scope includes third-party ICT services, the entity must take “the necessary measures and safeguards to ensure the participation” of the relevant provider. Full responsibility remains with the entity.
• Testing must be carried out in operational production environments;
• The test should be conducted at least every 3 years. Competent authorities may reduce or increase this frequency for a particular entity based on its risk profile or operational circumstances.
• At the end of the test, the financial entity must submit to the competent authorities a summary of the relevant findings, corrective action plans and documentation demonstrating that the test was carried out following the requirements.
• In return, the authorities issue a certificate “to enable mutual recognition of threat-based penetration tests between competent authorities”.

Combined testing for ICT service providers

There may be cases where an ICT service provider cannot be included because it would affect the security of its services or the quality of the test. Similarly, there may be cases where the provider is a supplier to different financial entities. In such cases, DORA is an exception.

A provider may conduct a “group TLPT” covering several financial entities for which it provides services. The supplier must then:

• agree to a written test with the different entities;
• sign contractual agreements with an external tester;
• ensure that the test covers all ICT services supporting critical functions of the financial entities; 
• conduct the test under the supervision of the designated financial entity.

If so, Article 26(4) provides that the group test shall be deemed to be a “TLPT conducted by the financial entities participating in this collective testing”.

TIBER-EU framework for operational requirements

The DORA establishes guidelines for threat-based penetration testing. However, operational requirements are governed by a different European framework. The TIBER-UE framework sets out the principles for the test scope, methodology, and approach to be applied at each specific stage of the test, from construction to repair.

The TIBER-EU framework is currently being implemented in various EU countries and is intended to apply to all members of the community. For example, TIBER-BE for Belgium, TIBER-LU for Luxembourg, TIBER-DK for Denmark, etc. It should be noted that there is currently no certification agency for TIBER-EU test providers in Europe.

How do you select a tester in the market to perform a penetration test based on threat realisation scenarios?

First, it is worth noting that financial entities can use internal testers, with every third test having to be conducted by an external tester. The exception to this rule is credit institutions classified as large, which must always rely on an external tester.

With this in mind, Article 27 of DORA details the requirements for testers who can perform threat-based penetration tests. Testers must:

• have the highest reputation;
• have the technical and organisational capabilities and demonstrate expertise in threat intelligence, penetration testing and Red Team testing;
• adhere to formal codes of conduct or ethical frameworks or be certified by an accreditation body in the Member State;
• provide independent assurance or an audit report on the sound management of risks associated with the implementation of the TLPT, including due protection of the financial entity’s confidential information and redress of the financial entity’s business risks;
• be duly and fully covered by adequate professional indemnity insurance, including misconduct and negligence risks.

16. Educate employees and management on cyber security

It is important to plan training, both for employees at board level and for all employees — depending on each person’s skills and responsibilities. The risks associated with staff in an organisation are at least equal to — if not greater than — those associated with cyber attacks. Bottom line: there is no point in having the best processes and technology if half of your staff write passwords on documents or transmit confidential information in plain text. If the people running your organisation are not trained in basic cyber hygiene practices, your organisation’s security will be at risk.

DORA: mandatory training for employees and managers

NIS 2 makes mandatory cyber risk management training mandatory for governing bodies but only encourages employees to do it. Operational digital resilience training for both managers and employees is imposed by DORA. According to the final wording:

“Financial entities shall develop ICT security awareness programmes and digital operational resilience training as compulsory modules in their staff training schemes. Those programmes and training shall be applicable to all employees and to senior management staff, and shall have a level of complexity commensurate to the remit of their functions. Where appropriate, financial entities shall also include ICT third-party service providers in their relevant training schemes.”

— DORA, Article 13(6)

The CISO is probably one of the best-placed individuals to lead the selection of training (or providers) in collaboration with HR and managers of each department. Proper training of employees is a giant undertaking, cross-cutting across different professions, which should be undertaken as soon as possible.

17. Assess and manage third-party ICT risks

Supply chain security is at the heart of NIS 2 and DORA is aligning with it. The regulation places particular emphasis on managing the risks associated with ICT service providers. 

It should be noted that this area is the responsibility of the CISO, but also of the legal departments. Many of DORA’s requirements on suppliers have a direct impact on the content of the agreements governing cooperation. The legal/contractual sphere is where most of the tasks fall. We recommend reading the entire Chapter 5 of DORA.

What are DORA’s guidelines for managing risks associated with service providers? Financial entities are required to execute this task following the “principle of proportionality, considering the nature, extent, complexity, and seriousness of the relationship of dependency”, as well as the potential hazards associated with such arrangements.

Implement a risk management strategy for ICT providers

As outlined in Article 28(2), financial institutions are obligated to implement a third-party ICT risk strategy and conduct regular reviews of it. This strategy should encompass a policy concerning the utilisation of services to bolster critical functions. Additionally, the governing body is required to consistently assess risks associated with these services and contracts. Furthermore, DORA aligns with the governance principles of NIS 2. It emphasises that cybersecurity shouldn’t be solely managed by operational teams; instead, top management must be understanding of and accountable for risks as well.

‘A register of information with all contractual arrangements for the use of ICT services provided by external ICT service providers’ is required as part of the framework for ICT risk management.

In short: you need to have a complete inventory of the entire ecosystem of ICT providers. You need to clearly distinguish between providers that support critical functions and those that do not. This register should be made available to the competent authorities if they ask for it.

What should you do before entering into a contract with an ICT provider?

Article 28(4) outlines the rules to be followed. Before signing a contract for the use of ICT services, financial entities must:

• assess whether the contractual arrangements cover the use of ICT services supporting a critical function;
• assess whether the supervisory conditions for contracting are met;
• identify and assess all material risks associated with the contractual arrangements, including the possibility that such contractual arrangements may contribute to the amplification of ICT concentration risk;
• perform due diligence on potential external ICT service providers and ensure throughout the selection and evaluation process that the external ICT service provider is suitable;
• identify and assess conflicts of interest that a contractual arrangement may cause;
• where appropriate, determine in advance the areas to be audited and the frequency of inspections.

The main contractual provisions to be followed can be found in Article 30.

Plan an exit strategy for cooperation with key ICT providers

Article 28(8) says that financial companies should have “comprehensive and documented” exit plans for important services. At a minimum, the exit strategy must include

• alternatives;
• transition plans for the disposal of services and data held by the provider;
• and a safe and complete handover to alternative providers or reintegration.

Article 28(7) specifies the criteria for terminating these contractual agreements, primarily centred around issues such as insufficient security measures or inadequate due diligence for the service provider.

Critical ICT providers according to the ESA

The ESAs have the right to consider certain service providers as important for financial entities. These providers are then subject to the oversight of the lead supervisor, who has been designated by the ESA for this specific role. The supervisory system covers more than 10 articles of the regulation. If you would like to learn more about this, please read articles 31 to 44 in DORA.

In short

The DORA regulation will enter into force on January 17, 2025. The European financial sector must prepare for its implementation before this deadline. We, therefore, recommend all CISOs of entities covered by the regulation start work on compliance immediately. The task is challenging and requires discipline, resources, and, above all, time.

Most of the work should focus on three main areas:

• ICT risk management framework;
• digital operational resilience testing;
• ICT third-party risk management.

We divided these important rules into 17 steps that we tried to explain clearly. It is probably most sensible to start with the development and implementation of the mandatory policies introduced by DORA. 

The ICT risk management framework should include:

• a digital operational resilience strategy;
• an ICT business continuity policy;
• backup, restore and recovery procedures;
• records of actions in the event of disruption;
• incident management process;
• incident response plan;
• crisis communication plans.

On the security testing side, it will be necessary to conduct:

• digital operational resilience tests at least once a year;
• for specific entities, threat-based penetration tests at least every 3 years, in line with the TIBER-EU framework.

DORA places such a strong emphasis on ICT risk that the main focus of compliance will become managing risks associated with external providers. Risk management will require an appropriate cyber resilience strategy and therefore the support of your organisation’s legal department and perhaps even a joint effort to include the ICT area in the strategy. Legal teams will likely play an important role in ensuring compliance with the DORA regulation, and security teams will need to manage and document risks, including collaboration with suppliers from start to finish, from mandatory contractual provisions to exit plans for the riskiest suppliers.