Update Data Protection No. 132
Digital Operational Resilience Act and Cyber Resilience Act: New EU requirements for cybersecurity
Currently, stakeholders at all levels are warning of the significant increase in the risk of cyberattacks. There is also an increase in the risk of cyberattacks on critical infrastructures such as the financial sector due to the changed political situation caused by the war in Ukraine.
Therefore, it is not surprising that the NIS2 Directive—which came into force only a few weeks ago—is followed by other EU legislative proposals aimed at enhancing security in the digital space by means of networked components.
Bellow we examine two of the most recent EU legislative proposals in more detail. On the one hand, this concerns the importance of the EU Digital Operational ResilienceAct for finance and insurance companies, which only recently came into force. On the other hand, bellow we will examine the EU Cyber Resilience Act—still in the voting stage—the draft of which was published only in September of last year and which imposes significant requirements on all manufacturers, importers and dealers of products with digital elements.
In principle, as regulations, the two regulatory acts no longer need to be transposed in national law.
A. Digital Operational Resilience Act (DORA)
The European Regulation on digital operational resilience for the financial sector (Digital Operational Resilience Act, DORA) came into force on January 17, 2023. Since this concerns a regulation, DORA applies directly in Member States without requiring transposition acts. However, a transposition period of 24 months is provided, so the DORA obligations must be implemented by all bodies concerned only as of January 17, 2025.
It is the aim of the Regulation to meet the growing IT security and cyber risks in the financial sector and the insurance industry. The Regulation is part of a package of measures aimed at guiding and supporting the digitization of the financial sector. DORA Regulation defines uniform requirements for operational resilience and security of network and information systems in the financial sector, which also extends to critical third-party service providers in ICT sector (ICT - Information and Communication Technology) and should reduce the risks of and through cyberattacks. The focus of DORA Regulation is the ICT sector, since the importance of this sector in the course of digitization has increased significantly. In addition, obligations in terms of regular review and testing are expanded significantly.
The DORA Regulation supplements the NIS2 Directive which must be transposed in national law by October 2024, and also provides for higher requirements for cybersecurity in critical sectors such as lex specialis for strengthening IT security in the financial sector.
1. Who must act?
In accordance with Art. 2(1), the DORA Regulation applies, in principle, for all financial entities which are part of credit, payment and e-money institutes, but also for investment companies as well as insurance and reinsurance companies and for ICT service providers.
Which requirements are to be implemented in accordance with the DORA Regulation depends above all on the size of the respective company:
2. What`s new?
The DORA Regulation contains supplementary requirements for the internal governance, the ICT risk management, the handling of ICT security incidents, ensuring digital operational resilience as well as the monitoring and risk control at ICT third-party providers.
Art. 40 of the DORA Regulation simplifies the exchange of information and knowledge on cyber threats by financial entities.
In addition, for the first time, the supervisory authorities also receive the authority to monitor ICT third-party providers.
With regard to the ICT risk management, articles 5-14 contain comprehensive obligations for ensuring the resilience of the ICT systems and instruments including in threat situations. In accordance with Art. 5(2), the ICT Risk Management Framework must also extend to the physical infrastructure such as computer hardware, server, the relevant premises and computer centers.
Causes of risks must be documented and eliminated as soon as possible. Moreover, protection and prevention measures must be taken and recovery plans must be prepared. Provided the financial entities in question are not micro-enterprises, they must use and regularly inspect a system for control of the information security and ensure a reasonable separation of ICT management functions, monitoring functions and internal inspection functions. The DORA, on the other hand, does not prescribe any other requirements for the standardization of these measures and plans. Financial entities, however, are well-advised to comply with existing recognized technical standards. Requirements and recommendations of the supervisory authorities can also provide guidance in the future.
All measures taken must be documented in the ICT Risk Management Framework and regularly reviewed by the ICT auditor with appropriate expertise (Art. 5(1, 6) DORA Regulation).
In addition, companies particularly at risk must perform threat-led penetration testing every three years in accordance with Art. 23. The scope of this penetration test is determined by the finance company and approved by the responsible authorises. Since ICT systems are associated with higher testing costs, it is important to identify these critical components and thereby optimize the implementation costs.
In addition, Art. 27 contains comprehensive requirements for contractual minimum content which, in addition to the performance description with quantitative and qualitative performance targets, provisions on accessibility, availability, integrity, security, etc. also includes access rights, reporting obligations of ICT third-party providers or rights of inspection and audit of financial entities as well as special exit strategies. In the future, these mandatory contents must be provided with standard contractual clauses.
Stricter requirements apply in case of outsourcing to critical third-party providers designated by EBA (European Banking Authority), ESMA (European Securities and Markets Authority) and EIOPA (European Insurance and Occupational Pensions Authority), see Art. 28. In particular, there is a reporting obligation in this case. Relative for the classification as critical ICT provider include the systematic character of the finance company, the independence of the finance company from the services of the ICT third-party provider, the level of the substitutability or the number of relevant Member States. A list of ICT third-party providers classified as critical must be published and annually upgraded.
3. Summary and checklist
A number of requirements of the DORA Regulation are already known from other regulations and guidelines such as the German Minimum Requirements for Risk Management [MaRisk] or the German Banking Supervisory Requirements for IT [BAIT] and a higher level of compliance with other requirements also helps with the implementation of DORA Regulation. Nevertheless, deviating or more detailed regulations make adjustment necessary, partly to a significant extent. The latter concerns above all larger companies in the relevant sectors. There is relief from the fact that, for example, the BaFin circular letter on the Bank Supervisory Requirements for IT (BAIT) and Insurance Supervisory Requirements for IT (VAIT) on a national level already anticipate some of the requirements of the DORA, but these need to be adapted.
Otherwise, the following checklist provides a brief overview of the required measures:
B. Cyber Resilience Act (CRA)
In contrast with the DORA Regulation, the Cyber Resilience Act (EU 2019/1020, CRA) has not come into force yet. A first draft was published on September 15, 2022 (as reported by Heuking). The scope of application of the CRA is significantly wider than that of the DORA Regulation and provides for comprehensive obligations for manufacturers, dealers and importers of products with digital elements. The Regulation is aimed at ensuring the cybersecurity of products with digital elements and maintaining it for the entire life cycle of the product. In addition, the users should obtain better information to be able to make informed decisions taking into account the cybersecurity features of a product. Moreover, the CRA contains regulations for market monitoring and for the implementation of rules for cybersecurity contained within.
Through the minimization of gateways for malware or hacker attacks, the estimated costs of cyber criminality should finally be reduced, which the EU Commission most recently quantified as EUR 5.5 trillion annually.
1. Products with digital elements
Everything in CRA concerns products with digital elements. This broad term should cover both software as well as hardware, on which access to a product or network is made possible. In contrast, digital services, such as cloud-services or SaaS, as well as open-source-software which is developed outside a business activity, are not covered. Products with digital elements include e.g. sensors, cameras, routers, intelligent speakers, hard drives or mobile terminal devices.
The products with digital elements from the CRA must not be confused with goods with digital elements introduced with the latest law of obligations reform in Section 475a et seqq. German Civil Code (Bürgerliches Gesetzbuch, BGB). In contrast with the regulations in the BGB, the CRA isnot a consumer law. Rather, the legal framework for all networked products with regards the cybersecurity should be standardized. Moreover, the definition of products with digital elements is also much broader and the CRA also covers simple software components.
2. What`s new?
Art. 10 et seqq. CRA Draft specifies comprehensive obligations for products with digital elements and provides for ongoing assessment of cybersecurity risks as well as their documentation and minimization. Even after these products are brought to the market, the assessment of risks must be part of the technical documentation. A "reasonable" minimum level of security must be reached, which in any case includes the following requirements:
Should cybersecurity risks or vulnerabilities occur during the life cycle of the products, the manufacturer must eliminate these and provide automatic free security updates. The update period, however, is limited to a maximum of five years.
In addition, the manufacturer must determine vulnerabilities in its products according to the current draft text through regular testing and eliminate them immediately as needed. If an incident has already occurred which can impact the security of the product, or if vulnerabilities have been exploited, the manufacturer must report this immediately to the competent supervisory authority, but no later than within 24 hours of becoming known. The competent authority for the reporting of cybersecurity incidents is ENISA — the European Union Agency for Cybersecurity. If this also concerns a security incident as defined under the GDPR or other laws, additional reporting to the competent data protection authorities or the BSI (German Federal Office for Information Security) may also be necessary.
The manufacturers must ensure the conformity of their products either by means of internal control procedures, an EU type-testing or through a conformity assessment based on a comprehensive quality assurance (EU Declaration of Conformity). Specifics apply for products with digital elements in which the Commission sees a particular risk (critical products), because the potential cybersecurity gaps of these products due to their cybersecurity function or their proper use can have serious consequences. These products must go through stricter procedures, where the specific requirements are based on the classification of the respective product:
For critical products of Class I, a trustworthiness test is also required. In case of the products of Class II, a third-party expert must always be involved in the assessment of conformity.
In addition to the manufacturers, the importers that import products with digital elements of manufacturers outside EU and dealers of products with digital elements are also obligated, if they bring these on the market in the EU. The importers or dealers are only those who bring the product on the market in the name of another party. However, if they do this in their own name they are considered as manufacturer as defined under CRA.
Importers must ensure that the manufacturer conducts an appropriate conformity procedure and prepares the technical documentation. In addition, both the importers as well as dealers must ensure that the product bears the CE marking and contains all required information and the instructions for use. The importers must attach the contact information on the product or on the packaging; the dealers must check whether the importer has done this.
The monitoring of implementation must be carried out by the Member States. If the newly established national market monitoring bodies consider a product as not compliant, they can, in three steps:
2) restrict or prohibit the provision of the product on the market;
3) order a product recall.
If a manufacturer, importer or dealer fails to meet its obligations under the CRA, the draft regulation prescribes a fine of up to EUR 15 million or 2.5% of global annual revenues (of the Group, if applicable).
3. Summary and checklist
Even if the CRA is yet to be approved by the Council of Ministers and adopted by the European Parliament before coming into force, followed by an expected 24-month implementation period, we recommend manufacturers, dealers and importers to prepare themselves now for the planned regulations due to often long product development cycles (Security by Design, attention already in development stage). In addition, the reporting obligations for security incidents must already be implemented 12 months after entry into force.
Affected companies must therefore carefully follow the legislative process and prepare themselves now for the CRA:
Obligations of importers:
Obligations of dealers:
|For inquiries or when in need of assistance, please contact a member of our Taskforce Cybersecurity.|