DORA - Introduction

Digital Operational Resilience Act

Introduction

(Apology that this article is published on the website betriakvordun.is, but the page secprico.is is still under construction but will be available in the next few months.)

The global financial system is highly interconnected and has many interdependencies.  This increases the possibilities of systemic cyber incidents causing widespread ICT and service failures that would affect the world economy.  Through the years various actions have been taken to strengthen the resilience of the financial system.  Digital Operational Resilience Act (DORA) is the latest step and from January 2025 financial entities better be ready.

The aim of DORA is to consolidate and upgrade ICT risk requirements as part of the operational risk requirements that have been addressed in various regulation and requirement documentation.  This mean setting qualitative rules for the protection, detection, containment, recovery and repair capabilities against ICT-related incidents.  It is the hope that through DORA all provisions addressing digital risk in the financial sector should for the first time be brought together in a consistent manner in one single legislative act. 

Larger financial institutes have for many years been considered critical operation, but with DORA the bar is lowered. In addition scope is widened to import and critical third parties that provide services to these financial entities.

Entities that DORA applies to

According to Article 2 of the DORA regulation, the regulation applies to the following entities:

(a)     credit institutions;

(b)     payment institutions, including payment institutions exempted pursuant to Directive (EU) 2015/2366;

(c)     account information service providers;

(d)     electronic money institutions, including electronic money institutions exempted pursuant to Directive 2009/110/EC; (e)       investment firms;

(f)      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;

(g)     central securities depositories;

(h)     central counterparties;

(i)      trading venues;

(j)      trade repositories;

(k)     managers of alternative investment funds;

(l)      management companies;

(m)   data reporting service providers;

(n)     insurance and reinsurance undertakings;

(o)     insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries;

(p)     institutions for occupational retirement provision;

(q)     credit rating agencies;

(r)      administrators of critical benchmarks;

(s)     crowdfunding service providers;

(t)      securitisation repositories;

(u)     ICT third-party service providers.

DORA main topics

Main purpose of DORA is to address, as the name implies, digital operational resilience of financial entities.  The following requirements are stated in Article 1:

(a)   requirements applicable to financial entities in relation to:

(i)      information and communication technology (ICT) risk management;

(ii)    reporting of major ICT-related incidents and notifying, on a voluntary basis, significant cyber threats to the competent authorities;

(iii)   reporting of major operational or security payment-related incidents to the competent authorities by financial entities referred to in Article 2(1), points (a) to (d);

(iv)   digital operational resilience testing;

(v)    information and intelligence sharing in relation to cyber threats and vulnerabilities;

(vi)   measures for the sound management of ICT third-party risk;

(b)   requirements in relation to the contractual arrangements concluded between ICT third-party service providers and financial entities;

(c)    rules for the establishment and conduct of the Oversight Framework for critical ICT third-party service providers when providing services to financial entities;

(d)   rules on cooperation among competent authorities, and rules on supervision and enforcement by competent authorities in relation to all matters covered by this Regulation.

What is behind these requirements?

At a glance, the requirements mean that a financial entity must implement a management system for risk and security management and monitoring of third-party service providers, as well as share information that it becomes aware of threats in its ICT environment.  ISO/IEC 27001 is an example management system for risk and security management, and the author recommends adding a privacy information management system according to ISO/IEC 27701.  ISO/IEC 27001 provides high-level insight into how risk assessment should be carried out, while the methods of ISO/IEC 27005 and ISO 31000 are more detailed and therefore recommended.

Items (a) (ii) og (iii) add requirements that are not part of the controls in Appendix A of ISO/IEC 27001 (here only referred to the 2022 version) that is reporting to competent authorities.  Control A.5.5 Contact with authorities require exactly that but not that reporting is required. Same applies to controls A.5.24 Information security incident planning and preparation and A.5.26 Response to information security incidents.  Reference may be made to similar clauses 6.2.24 and 6.2.26 of ISO/IEC DIS 27701 on how to modify incident management processes to include notification to competent authorities.

Central Banks in Europe have many been implementing TIBER-EU test (or national versions of this test) that offers financial entities method to test their digital operational resilience against cyberattacks (item (a)(iv) above).  This test needs to be added to other penetration tests already included the organization’s management system. Requirements for penetrations tests can be found in five controls of Appendix A of ISO/IEC 27001. That is A.5.21 Managing information security in the ICT supply chain, A.8.8 Management of technical vulnerabilities, A.8.16 Monitoring activities, A.8.25 Secure development life cycle og A.8.29 Security testing in development and acceptance.  Further information on TIBER-EU can be founded here on the website of the European Central Bank.

In control A.5.7 Threat intelligence of ISO/IEC 27001, Appendix A, requires that information related to information security threats is collected.  In the guidance in ISO/IEC 27002 it is recommended that information and knowledge on threats is shared.  DORA changes that recommendation into a requirement (see (a)(v)).  This is the common practise but too often within small groups with common interest or industry.  Now the requirement is a wider collaboration or public sharing. Threat intelligence is accessible from many websites, where information and knowledge is shared and kept up-to-date.

To get a good understanding and monitoring ICT third party risk (see (a)(vi)) in the ICT supply chain can be complicated and is probably the hardest requirement in the DORA regulation. Most organisations know their service providers but what about sub providers, sub-sub, etc. With DORA organisations are required to have sufficient overview of the supply chain of critical service providers. This is covered in length both in the recitals and the regulation itself. In addition are the requirements of items (b) and (c) on third party contracts and their monitoring.  It is the author’s view that these three items that is (a)(vi), (b) and (c), will end up as the most comprehensive requirements that financial entities have to meet from the regulation.

The last item on the list, (d), is of the concern of the competent authorities.

About the author

The author of the document is Marinó G. Njálsson, a consultant in the field of risk management, information security and privacy. Marinó was the security manager at deCODE Genetic from 1997-2000 and has since worked as a consultant. He has been an information security and privacy consultant for many large companies both in Iceland and around Europe. In Iceland, at VÍS, Landsbanki Íslands, covering all the country's pension funds, for the Ministry of Justice and the National Police Commissioner due to the Schengen information system, Valitor (now Rapyd), covering all elementary schools in the country, covering all kindergartens in the country and with the Commissioner of Police in the capital area. Outside Iceland at APMM (Denmark), Nokia (Finland), BMW for ISO/IEC 27001, TISAX and privacy (Germany) and Økonomistyrelsen for privacy (Denmark), to name a few. 

For more information please send email to security@internet.is or Marino G. Njalsson á LinkedIn

Back to English front page