1 Introduction

In September 2020 the European Commission published the digital finance package. It included the digital finance strategyFootnote 1 and the retail payment strategyFootnote 2, and two legislative proposals, the markets in crypto-assets (MiCA)Footnote 3 and the Digital Operational Resilience Act (DORA)Footnote 4. The digital finance strategy builds on the Fin Tech Action Plan (2018)Footnote 5 and supports the digital transition of the financial sector and embraces technological innovations. However, the digital transformation of the financial sector can only be successful with resilient IT systems of all European financial entities. That is why the Digital Finance Package includes DORA.

The threat of cyber-attacks in the financial sector has dramatically increased in recent years. In comparison to other sectors, the financial sector presents an attractive target for cyber criminals. Cyber-attacks also have the potential to disturb or disrupt financial services which are important for the global financial system. According to Kost in just the first six months of 2021, phishing attacks in the financial sector increased by 22% since the same period in 2020.Footnote 6 On top of this, financial firms are facing rising ransomware and distributed denial-of-service (DDoS) attacks.Footnote 7 In the past, strong voices in the financial market predicted the next financial crisis could result from a systemic cyber-attack.Footnote 8

The European Commission was alert to and addressed cyber risks in the DORA proposalFootnote 9 in order to strengthen the IT security of financial firms in the EU. After quick Council negotiations during the German, Portuguese and Slovenian Presidency, a general approach was reached in November 2021.Footnote 10 The European Parliament published its report in December 2021.Footnote 11 During the following French Presidencies, the European Parliament, Commission and Council negotiated in trialogue and reached a political agreement in June 2022.Footnote 12 DORA was formally adopted in November 2022 and will be applicable two years later. In the meantime, the European Supervisory Authorities (ESAs) will develop technical standards to provide further clarification and guidance.Footnote 13

DORA includes new requirements for financial firms in the field of IT governance, reporting and also penetration testing. Critical ICT third-party service providers (CTPP) will be overseen by the three ESAs (EBA, EIOPA or ESMAFootnote 14). After giving an overview on the general provisions of DORA, this publication will focus on the new requirements for financial firms and analyse whether its rules are appropriate to prevent and better mitigate rising cyber threats in the financial sector in an efficient way for all stakeholders.

2 General provisions

DORA entails several general provisions. First, which financial entities are in the scope of DORA will be explained. The principle of proportionality also plays an important role for the application of DORA and will be discussed in a second step. Third, the relation to the horizontal Network and Information Security Directive (NIS) will be explained.

2.1 Personal scope of DORA

The broad personal scope of DORA is defined in Article 2 and includes all supervised financial entities, not only traditional financial institutes, such as banks, insurances and investment firms. DORA also applies to less traditional financial entities, such as credit rating agencies, trade repositories, payment and e‑money institutions as well as trading venues. DORA also applies to crypto-asset service providers as authorized under MiCA and issuers of asset referenced tokens. It can only be supported that DORA has a large personal scope, given the omnipresent threat in the financial sector. New technology driven financial entities should maintain from the beginning some basic cyber hygiene rules. Even if especially younger FinTechs will be faced with DORA cyber regulation for the first-time, this does not seem excessive since DORA contains a simplified ICT risk management framework for such microenterprises, as well as for smaller and medium-sized businesses.Footnote 15

DORA will not apply to audit firms. The inclusion of auditors was initially proposed by the European Commission and supported by the European Parliament.Footnote 16 However, the aim of DORA is to strengthen the cyber resilience of financial entities, and auditors are not financial firms and are also not supervised by financial supervisory authorities.Footnote 17 Therefore, rightfully so, auditors are not in the scope of DORA.

2.2 Proportionality principle

Article 3a DORA states that financial entities shall implement the rules in accordance with the principle of proportionality, considering their size, the nature, scale and complexity of their services, activities and operations, and their overall risk profile. Although the principle of proportionality is a general rule of law which should be applied throughout European law as such,Footnote 18 and therefore the specific article in DORA seems to be unnecessary, it is an important signal that the rules of DORA should not only be applied as such but in accordance to specific risk profiles and in order to keep the financial sector safe. The scope of DORA is very broad and some requirements are quite prescriptive. The consistent application of the principle of proportionality will correct an exhaustive application of the law.

2.3 Interaction between DORA and NIS

The European Parliament and Council adopted the horizontal NIS Directive in 2016 which aims to improve the overall level of cybersecurity in the EU for providers of critical infrastructure.Footnote 19 This directive applies to operators of essential services in seven sectorsFootnote 20, including the financial sector. NIS makes the adoption of enhanced security measures obligatory for relevant operators in those sectors. The operators are identified on a national level by a mechanism set out in NIS. In the financial sector only larger credit institutions, trading venues, insurance firms and central counterparties fall within the scope of NIS.Footnote 21

The upcoming NIS 2.0 Directive (NIS2) which was finally adopted in November 2022 broadens the scope of the current NIS by covering more firms in existing sectors.Footnote 22 The scope of NIS2 is broader but the DORA requirements are by far more prescriptive and detailed than the NIS2 requirements. In addition, the scope of DORA includes all financial entities regardless of their criticality for the financial sector. That is why a lex specialis clause was introduced into NIS2 stating that DORA takes precedence over the NIS Directive as a lex generalis.Footnote 23 In case of overlaps the NIS2 requirements will not apply to financial entities. Nevertheless, competent supervisory authorities shall exchange information on incidents with NIS authorities.Footnote 24 The importance that DORA’s and NIS’ ecosystems interconnect is convincing given the overlapping aims, scopes and rules.

3 Specific provisions

DORA entails requirements for financial firms in the field of ICT risk management, incident reporting and testing. DORA will also introduce a new oversight framework for CTPP.

3.1 ICT risk management

DORA includes requirements for internal risk management and third-party risk management.

3.1.1 Management of internal ICT risks

To improve their cyber resilience financial firms are required by Article 4 DORA to set-up an internal governance and control framework to ensure effective and prudent management of all ICT risks. This includes establishing a management body to define, approve and oversee the implementation of all arrangements related to an ICT risk management framework. The ICT risk management framework must include strategies, policies, procedures, ICT protocols and tools necessary to adequately protect all information and ICT assetsFootnote 25, and pursuant to Article 7 identify, classify and adequately document all ICT–supported business functions, roles and responsibilities, and the information assets and ICT assets supporting these functions, and their roles and dependencies with ICT risk.

Article 9 DORA obliges financial entities to have in place mechanisms to promptly detect anomalous activities. Entities shall put in place a comprehensive ICT Business Continuity Policy.Footnote 26 For the purpose of ensuring the restoration of ICT systems and data with minimum downtime, limited disruption and loss, as part of their ICT risk management framework, financial entities shall develop and document backup policies and recovery methodsFootnote 27 as well as a communication strategy.Footnote 28

The above-described requirements are very prescriptive.Footnote 29 Risk management is an important element but always needs to be implemented by measures that are appropriate to the financial entities’ level of risk. Clear guidance from ESAs on how to put this into practice will surely be appreciated by the affected financial entities.

3.1.2 Management of ICT third-party risks

In recent years, the extent and nature of financial entities with third-party service providers have evolved, particularly in the field of technology. The “G7 Fundamental Elements for Third-Party Cyber Risk Management in the Financial Sector (2018)”Footnote 30 states that entities’ governing bodies are responsible and accountable for effective oversight and implementation of third-party cyber risk management. Although by DORA entities cannot outsource their responsibilities to a third-party, DORA entails key principles for a sound management of ICT third-party risk and considers the complexity of ICT-related dependencies. This might help governing bodies to get a better understanding of their third-party risks.

Financial entities shall be aware of the nature, scale complexity and importance of ICT-related dependencies. That is why financial entities shall maintain a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers.Footnote 31 The register must distinguish between services that cover critical or important functions and those that do not. The register is a key element to the proper management of third-party related risks.

Article 27 DORA entails key contractual provisions to ensure a more balanced playing field between the financial entity and the third-party service provider. The contractual arrangement shall include at least provisions on accessibility, availability and integrity, as well as provisions on ensuring access, recovery, service level descriptions and termination right, and also the obligation of the ICT third party service to help in case of an ICT–related incident.Footnote 32 The contractual clauses should strengthen especially smaller financial entities while negotiating contracts with the most prosperous and dominant technology companies, so called BigTechs.

3.2 ICT-related incidents management, classification and reporting

3.2.1 Harmonizing of reporting requirements

Reporting of ICT-related incidents to the supervisory authority is a key element of cybersecurity. The notification gives a higher chance to better understand and identify the source of the incident, to analyse the potential for repercussions and to seek assistance. A quick notification of an incident might also help other institutes to better get prepared for similar attacks. Hackers are often using similar networks or widely used software vulnerabilities.Footnote 33 Informed authorities are in the position to publicly warn against and prevent other attacks.

Unfortunately, reporting rules are fragmented. The Financial Stability Board (FSB) found in its 2021 report that fragmentation exists across sectors and jurisdictions in the scope of what should be reported for a cyber incident. Also, time frames for reporting cyber incidents, and how cyber incident information is used, differ in most jurisdictions. This is especially a challenge for financial institutions that operate in multiple countries. Those firms face several different reporting requirements for a single cyber incident. In addition, also financial supervisory authorities receive heterogeneous incident information.Footnote 34

DORA harmonizes reporting requirements for all EU based financial institutions. Financial entities shall establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents.Footnote 35 While all incidents shall be recorded, financial entities shall only report major incidents to the financial supervisory authority.Footnote 36 Relevant criteria to determine a major incident are among others the relevance of the incident on the criticality of the services affected, the duration of the incident and the economic impact. The ESAs are instructed to develop regulatory technical standards in order to establish the content of the notification for significant cyber threats and uniform templates.Footnote 37 As a result, the competent authorities should receive homogenous incident information from the whole industry in the future.

Article 17 al. 3 (a) DORA obliges financial entities to produce in a first phase an initial notification. This should include all information necessary for the competent authority to determine the significance of the major ICT-related incident and assess possible cross-border impacts. In case the status of the original incident has changed significantly an intermediate report should be producedFootnote 38. A final report should be delivered, when the root cause analysis has been completed, regardless of whether or not mitigation measures have already been implemented.Footnote 39

DORA is not directly introducing a timeframe for financial institutions to report major incidents to the competent authorities. This is left to the ESAs and the European Union Agency for Cybersecurity (ENISA) having to consult and come up with a consistent time frame in line with the time frame planned under the upcoming NIS 2 Directive.Footnote 40 Initially, the European Commission proposed strict time limits in DORA that were not consistent with the longer time limits in NIS2.Footnote 41 In order to avoid fragmentation, it was the right trialogue decision to let the time limits be defined by regulatory technical standards at a later stage.

3.2.2 Sharing of incident information

Information sharing is key to achieving cyber resilience and preventing further harm from cyber-attacks. Thus, it will also be important that the financial supervisory authority shares relevant information with the NIS authority. Both authorities have different roles.Footnote 42 The financial supervisory authority focuses on potential impacts of an incident on the financial system. The NIS authority should analyse potential impacts on providers of critical infrastructures of all branches that are essential for the functioning of a society and economy.Footnote 43

Information of incidents will also be shared by national competent authorities with the ESAs. ESAs will gain an overview of all major cyber incidents in the European financial sector. DORA also invites ESAs to prepare a joint report assessing the feasibility of further centralisation of incident reporting through the establishment of a single EU Hub for major ICT-related incident reporting by financial entities. The establishment of such an EU Hub can only be supported as it would give the possibility to gain a threat landscape of potential and identified cyber threats affecting the European financial sector. ENISA and NIS authorities could also benefit from the threat analyses of such a centralised data pool.

3.3 Testing

3.3.1 Requirements of threat led penetration tests

Once a financial entity has reached cyber maturity, because it has developed and implemented both an effective, actionable plan and an infrastructure to keep its business resilient, it should be tested. DORA obliges financial entities to regularly test their operational resilience and it defines common standards for testing programs.Footnote 44 Tests should also include vulnerability assessments, open-source analysis and source code reviews. DORA requires larger financial entities to carry out at least every three years a threat led penetration test (“TLPT”).Footnote 45 The TLPT may be carried out in a manner proportionate to the size, scale, activity and overall risk of the financial entity.

The G7 Fundamental ElementsFootnote 46 define TLPT as follows: “TLPT is a controlled attempt to compromise the cyber resilience of an entity by simulating the tactics, techniques and procedures of real-life threat actors. It is based on targeted threat intelligence and focuses on an entity’s people, processes and technology, with minimal foreknowledge and impact on operations. The purpose of TLPT is to assess and provide insights on entities’ resilience capabilities against a real world simulated cyber incident. TLPT should be conducted within a set scope and incorporate a risk management process to ensure a controlled test that minimizes risk to entities.”

3.3.2 Internal or external testers

The G7 Fundamental Elements do not advise if a test should be performed by an internal or external tester. In 2018 the European Central Bank (ECB) published TIBER-EU, a European framework for threat intelligence-based ethical red-teaming. It is the first EU-wide guide on how authorities, entities, and threat intelligence and red-team providers should work together to test and improve the cyber resilience of entities by carrying out a controlled cyber-attack. The framework foresees only external testers.Footnote 47

An external tester is more neutral and independent than an in-house testing team. On the other hand, contracts with external companies are costive. The European Commission and Parliament wanted to leave the decision whether to use an internal or external tester to the financial entity itself.Footnote 48 The Council had a strong opinion to only allow external testers.Footnote 49 As a compromise, DORA requires larger financial institutes that are supervised by the European Central Bank (ECB) to instruct external testers only. All other financial entities are authorized to perform in-house tests. The ESAs will develop a regulatory technical standard to specify further the requirements and standards governing the use of internal testers.Footnote 50 ESAs should also specify further the requirements and standards regarding the scope of the test and the testing methodology. As quite a lot of Member States have already implemented the TIBER-EU Framework it will be important that the standards will be developed in accordance with this framework.

It is important to know that NIS2 will not require any TLPT for entities falling under its scope. That means that there is no risk of overlapping regulation regarding testing obligations with DORA. Still, DORA testing standards are quite high, regardless of the type of tester. Also, smaller entities are not obliged to perform expensive TLPTs. They should rather first invest their limited budget in a robust IT infrastructure before investing to comply with higher testing standards.

TLPTs should be carried out at least every three years.Footnote 51 Based on the risk profile of the financial entity and considering operational circumstances, the competent authority may in accordance with Article 23 DORA, where needed, request the financial entity to reduce or extend this frequency. TLPTs are expensive and time consuming. Therefore, authorities should make use of the exception to extend the time period in case the operational circumstances allow for it.

3.4 Oversight framework for critical ICT service providers

The FSB considers in its report on BigTechs (2019) financial stability implications of BigTech in finance.Footnote 52 Financial entities rely on advanced ICT services often provided by BigTechs. DORA addresses this problem and the ongoing trend of financial entities to outsource their IT-infrastructure to third-party service providers in Chapter V.

IT architectures have been becoming more complex over the last years, and it can only be welcomed that DORA takes a more holistic approach beyond internal processes and systems. As a new model of European oversight, DORA foresees an oversight framework for CTPP, such as cloud services, under a joint oversight regime, appointing either EBA, ESMA or EIOPA as lead overseer.

3.4.1 The architecture of the European oversight framework

First, ICT third-party service providers that are critical for financial entities will be designated by the ESAs. The designation process is regulated in Article 28 DORA and will be based on the systemic impact on the stability of the financial system, continuity or quality of financial services in case the relevant CTPP would face a large-scale operational failure. On that basis it can be assumed that mostly larger ICT service providers will be designated, depending on the number of global systemically important banks and insurances relying on their services.

In a second step, for each designated CTPP a lead overseer will be appointed. Either EBA, ESMA or EIOPA will oversee the identified CTPPs. Instead of having three acting agencies in this new field it might have been advisable to only appoint one European agency as overseeing body.Footnote 53 It will be a challenge to quickly build up competencies and new administrative infrastructures for three agencies. Otherwise, it can probably be assumed that in most cases the EBA will be acting as lead overseer, because banks will be the largest and systemically most relevant group of clients of CTPPs.

3.4.2 The oversight process

The lead overseer will be in the position to request relevant information, conduct general investigations and to address recommendations to the CTPP.Footnote 54 CTPPs need to ensure that they do not pose undue operational risks for the financial sector and comply with basic ICT requirements. CTPPs need among others to ensure the security, availability and continuity of services provided to financial entities.Footnote 55 The lead overseer will also assess the physical security, the risk management process, governance arrangements, mechanisms for data portability and testing programs of ICT systems. Although the powers seem to be extensive the lead overseer could follow a risk-based approach and focus on critical and important functions of CTPPs and evaluate the potential level of systemic risk. Not all outsourced tasks have the same level of risk.Footnote 56

After the assessment the lead overseer will issue recommendations to the CTPP. While recommendations will be issued by a European body, national competent authorities will be responsible for following them up.Footnote 57 The national financial supervisory authorities shall inform relevant financial entities of the risks identified in the recommendations. The competent authorities will also be able to take actions against their supervised financial entities when the recommendations are not endorsed by the CTPP. As a measure of last resort competent authorities will have the right to require the supervised financial entities to temporarily suspend the use or deployment of a service provided by their CTPP until the risks identified have been addressed or where necessary to terminate their contracts with the CTPP concerned.Footnote 58

Although the regulatory supervisory intervention in relation to CTPPs still takes place indirectly through the regulated financial entities using their services, the oversight regime is a big step forward to better monitor potential risks stemming from BigTechs, including potential concentration and contagion risks that could impact the financial system.

4 Conclusion

The timing for DORA could not be better. The cyber threat situation is alarming, not only for the financial sector. DORA’s main emphasis is to prevent or at least to better mitigate rising cyber threats in the financial sector. To achieve this goal the DORA framework sets the right priorities on ICT governance, reporting and testing. Although some parts of DORA are quite prescriptive, the risk-based approach of DORA will lead to a balanced application of the requirements. Some parts of the regulatory framework, such as incident reporting deadlines have still to be developed by the ESAs in the form of common regulatory technical standards. These standards should put emphasis on providing better guidance for financial institutes. The European oversight framework on critical ICT third-party service providers is the right answer to the ongoing trend of financial entities to outsource their IT infrastructure. If this oversight model is successful, it could have a pioneering role for other sectors.