Search results for: Cyber Resilience Act

Conceptually, you think of IoT devices, but the CRA has a far broader scope of application. In this article we examine one of the tricky nuances – distinguishing between a digital product and SaaS under the CRA.

The EU’s Cyber Resilience Act (CRA) looks to reshape product cybersecurity by imposing uniform baseline requirements on “products with digital elements” placed on the EU market. The CRA forms part of the EU’s wider Digital Decade architecture, which includes other cyber security laws such as NIS2 and DORA. One of the key scoping assessments for technology providers/users is the treatment of software delivered as a product, versus software delivered as a service (SaaS). In broad terms, the CRA targets hardware and software made available as products, including embedded and on‑premise software. Pure cloud‑native SaaS is generally excluded unless it is part of, or necessary for, the product’s core functionality. This distinction drives design choices, go‑to‑market models, contractual allocations and compliance strategies.

The Cyber Resilience Act at a glance

The CRA introduces essential cybersecurity requirements for products with digital elements throughout their lifecycle. The CRA aims to reduce products vulnerabilities, ensure manufacturers remain responsible throughout the product lifecycle, improve transparency, and strengthen cybersecurity standards. Manufacturers must implement the familiar-sounding secure‑by‑design and secure‑by‑default development processes, conduct risk assessments; maintain technical documentation; perform conformity assessments and, if approved, affix CE markings. There are requirements on vulnerability handling and incident reporting. Further, manufacturers should determine a product support period and clearly set out the end of that period. Importers and distributors assume due‑diligence and reporting obligations as part of their roles. Critical products face stricter assessment, including the involvement of regulatory bodies and other EU agencies. Enforcement powers, in the event of failings, include market surveillance, corrective measures and penalties.

The CRA entered into force on 10 December 2024 and applies, in full, from 11 December 2027. Transitional periods apply, with rules for managing and reporting vulnerabilities handling obligations coming into effect on the 11 September 2026.

The CRA’s centre of gravity is “products with digital elements” i.e. hardware or software products with a direct or indirect data connection to a device or network. The concept of ‘digital element’ and the requirement for a ‘connection’ to a device or network should be interpreted broadly. A connection can take various formats – physical or logical, direct or indirect – and a product may have multiple forms of connection simultaneously. For CRA purposes, our view is that what matters is whether the product has any such connection, rather than the specific technical mechanism involved.

Finding the line: SaaS vs SaaP(roduct)

The decisive question is not whether something is “software,” but whether it is made available as a product placed on the market (this is not limited to physical products), as opposed to a service. That framing has practical consequences for cloud‑first businesses.

At one end of the spectrum, embedded firmware, endpoint agents, operating systems, network equipment and IoT devices will ordinarily be within CRA scope. They are marketed and supplied as discrete products, typically licensed or sold, installed or embedded, and updated via supplier channels.

At the other end, pure SaaS offerings i.e., cloud‑hosted applications consumed via the internet without local installation and not presented to the market as a distinct product, are distinguishable as services rather than products. These may then be excluded from the reach of the CRA. Those services are already addressed by adjacent cyber security regimes, notably NIS2 which includes digital service providers and DORA, specifically for financial services ICT.

The challenge with this distinction is that the CRA does capture “remote data processing” within its scope when it is essential to the product’s core functions. While that does not transform every remote capability into a CRA‑regulated product, it does mean an assessment should be carried out as to whether the remote component is part of the product itself and necessary for its intended functionality, and not an ancillary cloud feature. For example, the Commission’s FAQs outline that standalone software that can be downloaded and installed on a device, e.g. a mobile app from an app store or program downloadable from a website will be caught.[1] It could, based on other examples, be argued conversely that an online chat function to help with financial interrogation is not, as it is likely to be ancillary. Of course, legal analysis based on the facts is always required. 

The question of what is “essential” to a product lies on a complex middle ground, where scoping turns on architecture, packaging and commercial presentation. For example:

  • Software “plus cloud” bundles. If a vendor supplies an endpoint agent or on‑premise component that only functions with the vendor’s back‑end, the combined system may be treated as a product with digital elements whose core functionality depends on remote processing. In this case, the on‑premise component would likely fall under the CRA, and the remote component may also be captured if it is necessary for the product to operate as intended.
  • Feature‑gated SaaS reliance. Where a locally installed product functions offline but there is gate access to cloud based advanced features, CRA may apply if those features are needed for the product’s main use. Where the offline baseline is genuinely complete and the cloud features are optional add‑ons, the remote service may be considered outside the CRA’s scope. This should be carefully considered and clearly documented.
  • Cloud‑delivered software that behaves like a product. Some providers “stream” applications or deliver packaged workloads into the customer environment under a subscription. If the delivered component runs in the customer’s environment and is marketed as software, it may fall within CRA scope, notwithstanding a subscription based hosted arrangement.

These considerations have strategic implications. Shifting capability from an on‑premise component to a purely remote feature may reduce CRA exposure, only to push it into the reach of other EU cyber-security rules, such as NIS2. Conversely, integrating core functionality into a product can help demonstrate CRA compliance but requires robust development practices, vulnerability disclosure processes, technical documentation and conformity assessments.

Practical implications for product strategy and compliance

For manufacturers and software publishers, the SaaS versus product boundary should ideally be a design‑stage decision, though we recognise this may be unrealistic in practice.  Where legal and compliance teams are tasked with understanding the CRA’s application, a mapping exercise of the organisation’s core offerings should be performed and documented findings where assessments around CRA application are made. This position should be kept under review as regulatory guidance evolves.

Pure SaaS providers, while generally out of scope of the CRA, should not assume a free pass. Cyber security outcomes will still be required up and down the supply chain. Customers will increasingly calibrate their procurement against CRA‑like requirements, when assessing resilience. Convergence around secure‑by‑design, vulnerability handling and coordinated disclosure is likely, regardless of the formal scoping outcome.

Key takeaways for the SaaS vs product boundary

In some cases, the distinction will be clear, but with the advanced functionality of online technologies, the use of SaaS terminology may be misleading. The CRA’s scoping turns on how functionality is delivered and how the offering is placed on the market.

Lastly, the CRA should also not be assessed in isolation as it rubs shoulders with many other EU digital and product laws, such as NIS2, DORA, GDPR, the AI Act and the Data Act to name but a few. For more information on that, keep up to date here: Navigating the EU Digital Decade | DLA Piper

For any questions relating to the CRA or other digital and data laws, reach out to the authors: Linzi Penman, Ryan Wheatley, Shervin Nahid, and Lorcan Burke.

[1] We have considered the CRA FAQs released at the end of last year and updated this year (available here), and the concept of remote data processing is expected to form part of separate guidance from the Commission.

First introduced in December 2020 by the European Commission, the European Cyber Resilience Act (“ CRA”) regulation was published in the Official Journal on November 20th. It will come into force on December 10, 2024, but will not be immediately applicable. Most obligations will only apply as from December 2027, with the exception, for example, of serious incident notification obligations, which will apply from September 2026. The CRA will apply to all member states and the companies operating in them.

The official regulation is available here: Regulation – 2024/2847 – EN – EUR-Lex

The purpose of this regulation is to reinforce the cybersecurity of “products with digital components”. This includes connected devices (watches, connected toys, voice assistants etc.) and certain software (operating systems, firewalls, etc.), whether or not they are integrated into physical devices. Software made available in SaaS mode is excluded from the CRA in certain cases.

The CRA imposes new obligations not only on manufacturers, but also on all those involved in the design, development and sale of a product containing digital elements. For example, manufacturers must ensure that vulnerabilities in their products are dealt with for at least 5 years (unless the product’s lifespan is shorter), while importers and distributors of digitally-enabled products must check the conformity of documentation provided upstream of the production chain. Certain products (such as smart cards, connected toys or security software) are subject to specific reinforced measures due to their criticality.

DLA Piper’s team of intellectual property, data protection & cybersecurity and technology lawyers will publish articles to help you understand these new regulations. Don’t hesitate to follow us so you don’t miss them or contact us if you have any questions! 

The proposed Cyber Resilience Act seeks to establish fundamental requirements for all products with digital elements and thereby ensure greater cybersecurity

On 15 September 2022, the European Commission presented its proposal for the Cyber Resilience Act (Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on horizontal cybersecurity requirements for products with digital elements and amending Regulation (EU) 2019/1020, the “Draft CRA“).

In this article we summarise the essential contents of the Draft CRA.

Background

In September 2021, the European Commission announced the proposed legislation. The rationale behind the proposal was that increasingly frequent cyber-attacks are causing immense financial damage as well as compromising the security of both companies and citizens based in the European Union.

The Draft CRA sets out certain conditions that will apply to products with digital elements and will require such products to meet cybersecurity requirements throughout their product lifecycle. In addition, increased transparency requirements are intended to ensure that user groups take cybersecurity characteristics into account when selecting and using products and therefore be better protected against cyberattacks.

Scope of the Draft CRA

The material scope of the Draft CRA is broad and covers all products with digital elements whose intended or foreseeable use is to establish a direct and/or indirect link of any kind to a device and/or network. According to the proposed definition, all software and hardware products and their related data processing operations are covered.

The products in scope are also divided into two categories, based on predicted levels of cybersecurity risk for the product in question. Stricter requirements apply to products that are deemed more critical.

The Draft CRA does not explicitly stipulate a territorial scope of application, and the recitals do not provide any information in this regard either. This creates a fair degree of uncertainty as to whether or not companies outside the European Union would be required to comply with its provisions and, if so, which ones. Nevertheless, the Draft CRA appears to indicate that extraterritorial applicability is intended.

In addition, products that are already the subject of other European legislation, such as medical devices, are explicitly excluded from the scope of the Draft CRA. With regard to those products, the European Commission assumes that the requirements of the Draft CRA are already sufficiently included in the specific legislation applicable to them.

Obligations of economic operators

The Draft CRA lays out different obligations for entities depending on their classification as either a manufacturer, importer or distributor.

However, the fundamental objective remains the same for all three types of entity: namely that the relevant products comply with the “essential cybersecurity requirements and obligations“, which are primarily set forth in Annex 1 of the Draft CRA. These include, in particular, the development, production and placing on the market of the products concerned in accordance with certain legal and technical parameters, as well as effective vulnerability handling mechanisms. For the most part, the obligations are not only to be complied with on a one-off basis, but over a period of up to five years, starting with the placing on the market of a product.

For the implementation of these requirements, the Draft CRA provides for a transition period of 24 months (and in some parts of just 12 months), which would commence when the finalised Cyber Resilience Act comes into force. This is likely to present significant challenges for many companies given that product development and manufacturing cycles are planned over a significantly longer period. Changing product development plans is likely to be costly and may also disrupt the release dates of new products.

Conformity of the products with digital elements

Products subject to the Draft CRA are required to meet certain cybersecurity characteristics. However, in line with the harmonisation efforts of European legislation, it may be possible to rely on existing European standards for this purpose. If the products meet the characteristics specified in such existing standards, it is presumed that they also meet the characteristics of the Draft CRA, although presumptions of this kind may be disputed at any time. In the absence of such standards, the European Commission may elect to adopt such standards itself.

To demonstrate compliance with their obligations, manufacturers are required to conduct a so-called conformity assessment. Depending on the risk classification of the product in question there are different procedures and methods that may be applied, with products considered to be of particular high risk being subject to stricter requirements. The procedures range from internal control measures to full quality assurance. For each of these procedures, the Draft CRA contains checklists with specifications that must all be met in order to successfully pass.

Competent bodies and regulatory powers

The Draft CRA also provides for extensive participation by public authorities. Accordingly, the European Commission, ENISA (European Union Agency for Cybersecurity) and national authorities are granted comprehensive market monitoring, investigative and regulatory powers. For cross-border matters, the Draft CRA also addresses the different procedures and principles for these authorities to cooperate with each other if disagreements arise in the interpretation and application of the law.

Authorities are also provided with the power to carry out so-called “sweeps”, which appear to be particularly striking and drastic. Sweeps are unannounced and coordinated, involving area-wide monitoring and control measures that are intended to provide information as to whether or not the requirements of the Draft CRA are being complied with. It is particularly important to note that sweeps may apparently be carried out simultaneously by several authorities in close coordination, thus enabling the investigation of cross-border matters. It is unclear how the rights and freedoms of citizens who own products that are the subject of a sweep and are actively using them will be protected in the process.

Risks of administrative fines

The Draft CRA provides for a phased concept of administrative fines for non-compliance with certain legal requirements, which follows the model of recent European legislation and is intended primarily as a deterrent. Administrative fines for violations of the Draft CRA can reach a maximum amount of either EUR 15 million or 2.5 % of the total worldwide annual turnover for the preceding financial year – whichever is higher.

In this context, significant legal uncertainties are likely to arise, mainly because the methods for imposing administrative fines will be left to Member States to implement. Although the Draft CRA specifies certain parameters, in particular criteria for the calculation of administrative fines, the proposed regulation raises considerable concerns with regard to the uniform interpretation and application of the rules on administrative fines throughout the EU.

Summary

The Draft CRA is a part of a series of previously enacted European legislation and proposed legislation that follows on from the European Commission’s digitalisation strategy.

Due to the recognised and steadily growing importance of cybersecurity and increasing public attention being given to this topic, the regulatory approach set out in the Draft CRA is certainly to be welcomed. Nevertheless, the Draft CRA in its current version presents considerable challenges to numerous market stakeholders and has the potential to cause uncertainties should it become law in its current form.  Many of the provisions are vague and open to a wide range of different interpretation and many also risk significant interference with the freedom of market stakeholders to conduct a business.

Given the potentially profound implications for product design and development, organisations will need to keep a close eye on progress of the draft CRA and may also want to consider advocacy to the European Commission in relation to any specific concerns through relevant trade bodies and associations.

The KRITIS Umbrella Act (Dachgesetz zur Stärkung der physischen Resilienz kritischer Anlagen – KRITISDachG) has been in effect since March 17, 2026. For operators of critical infrastructure in Germany, this means: new obligations, tight deadlines, and hefty fines require swift action. For the first time, the law establishes a cross-sector legal framework to strengthen physical resilience and applies to operators of critical facilities across ten sectors – ranging from telecommunications, energy, and transportation to healthcare and space. In this article, you’ll learn who is affected, what obligations exist, how regulatory responsibilities are distributed, and what penalties apply for violations.

  1. The five most important takeaways for your company
  • The registration requirement takes effect on July 17, 2026 – affected operators must register with the Federal Office of Civil Protection and Disaster Assistance (Bundesamt für Bevölkerungsschutz und Katastrophenhilfe – BBK)/Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik – BSI) within three months of being identified as a critical infrastructure. Attention: Immediate action required – those who fail to act now risk fines.
  • Broad scope of application: The law addresses operators of critical infrastructure in ten sectors.
  • Comprehensive operator obligations: The list of obligations follows a comprehensive all-hazards approach.
  • Significant risk of fines: Violations of key operator obligations may result in fines of up to EUR 1,000,000.
  • Personal responsibility of management: Management is personally responsible for approving and monitoring resilience measures (Sec. 20 KRITISDachG).
  • Background and Objectives of the KRITISDachG

The KRITISDachG serves to implement the CER Directive on the resilience of critical entities (Directive (EU) 2022/2557). The objective is to ensure the maintenance of key economic and societal functions in the event of natural disasters, technical failures, sabotage, or other hybrid threats, specifically through cross-sectoral minimum standards for the physical protection of critical infrastructure. It thus supplements existing regulations on IT security – particularly the amended national BSI Act (BSIG) as the central implementing instrument of the NIS2 Directive (Directive (EU) 2022/2555) – with a physical component.

  • Sectors Affected

The law applies to operators of critical facilities, i.e., natural or legal persons as well as other organizational units that have a decisive influence on facilities that are essential for the provision of critical services (see Sec. 2 nos. 1 – 4 KRITISDachG).

The law defines ten sectors in Sec. 4 (1) KRITISDachG: information technology and telecommunications, energy, transport and traffic, finance, social security services and basic income support for job seekers, healthcare, water, food, space, and municipal waste management.

Which services are to be classified as critical within the individual sectors and the criteria according to which facilities are considered significant for the provision of critical services will be determined separately by a statutory ordinance issued by the Federal Ministry of the Interior (Bundesministerium des Innern – BMI) (Sec. 4 (3) and 5 (1) KRITISDachG). Facilities that meet these criteria are considered critical facilities.

“Criticality” is therefore presumed to exist if a facility is necessary to provide a critical service and exceeds a threshold value specified in the statutory ordinance (Sec. 5 (1) sentence 1 no. 2 KRITISDachG). The threshold is determined based on the population to be served, with a population of 500,000 generally serving as the basis (Sec. 5 (2) sentence 2 KRITISDachG).

A state-level exemption clause allows the federal states to classify regionally significant facilities below the threshold as critical (Sec. 5 (7) KRITISDachG) – such as a hospital indispensable to the region or a water supply system.

Affected companies typically include energy suppliers, telecommunications providers, network operators, municipal utilities, airports, ports, and railway hubs, hospitals and pharmaceutical companies, water suppliers, data centers, and large food producers and logistics providers.

Federal government agencies that perform exclusively national security, defense, or law enforcement functions are largely exempt (Sec. 7 (1) no. 2 and (2) sentence 2 KRITISDachG).

  • Key Obligations and Sector Exemptions

A defining feature of the new legal framework is a multi-tiered resilience system that links government risk analyses with comprehensive operator obligations. In doing so, the law adopts a so-called all-hazards approach: every risk – from natural disasters to sabotage and terrorist attacks to human error – must be included in the risk analysis.  

An overview of the core provisions:

  • Cross-sectoral risk analyses by federal and state ministries for critical services (Sec. 11 KRITISDachG),
  • Registration with the BBK/BSI within three months of identification as a critical facility, no earlier than July 17, 2026 (Sec. 8 (1) KRITISDachG),
  • Risk analysis (Sec. 12 KRITISDachG) for the first time no later than nine months after registration (Sec. 8 (7) KRITISDachG), thereafter as needed, but at least every four years,
  • Resilience measures and resilience plan (Sec. 13 KRITISDachG) for the first time no later than ten months after registration (Sec. 8 (7) KRITISDachG), including emergency response teams, physical security, access controls, emergency power supply, and staff training,  
  • Reporting obligations: Upon request, evidence of compliance with these obligations must be provided (Sec. 16 KRITISDachG), and incidents must be reported immediately, no later than 24 hours after becoming known (Sec. 18 (1) KRITISDachG),
  • Personal responsibility of management for approving and monitoring resilience measures (Sec. 20 KRITISDachG).

The core of these requirements consists of resilience obligations under Sec. 13 KRITISDachG. To specify these obligations, the BMI may establish cross-sectoral minimum requirements (Sec. 14 (1) KRITISDachG). In addition, operators or their industry associations have the option of proposing industry-specific resilience standards (Sec. 14 (2) KRITISDachG). Sector-specific requirements issued by federal ministries or state governments are only permissible on a subsidiary basis and in agreement with the BMI (Sec. 14 (3) and (4) KRITISDachG). The provisions on sector-specific requirements will not take effect until January 1, 2030, in order to give priority to the development of industry-specific standards (see Sec. 14 (2) KRITISDachG).

Furthermore, the law provides for sector-specific exemptions to avoid double regulation (Sec. 4 (2) nos. 1 – 3 KRITISDachG):

  • These apply to operators in the financial sector who are already subject to the Digital Operational Resilience Act (DORA) (Regulation (EU) 2022/2554), as well as operators in the IT and telecommunications sector for whom a resilience and security regime exists under the NIS2 Directive and its national implementation in the BSIG. In these areas, key operator obligations – such as risk analysis and risk assessment (Sec. 12 KRITISDachG), ensuring resilience (Sec. 13 KRITISDachG), and providing evidence (Sec. 16 KRITISDachG) – are exempted, while the registration requirement (Sec. 8 KRITISDachG) and provisions regarding national risk analyses and assessments (Sec. 11 KRITISDachG) continue to apply.
  • Similar exemptions apply to operators of critical facilities in municipal waste management and in the social security/basic income support sector, although risk analysis and assessment obligations (Sec. 12 KRITISDachG) expressly remain in effect.
  • Penalties for Violations

Violations of key operator obligations may result in fines of up to EUR 1,000,000 as well as administrative orders. The graduated fine scale depends on the nature and severity of the violation. It has been increased from a maximum of EUR 500,000 to EUR 1,000,000 compared to the government draft (as of November 2025).

If managers violate their duty to approve the specific resilience measures to be taken pursuant to Sec. 13 (1) KRITISDachG as appropriate and to continuously monitor their implementation (Sec. 20 (1) KRITISDachG), they are liable to their organization for damages caused through negligence (Sec. 20 (2) KRITISDachG); the governing body remains ultimately responsible.

  • Competencies of the Authorities

Responsibility for critical services lies with different federal (Sec. 3 (2) nos. 1 – 12 KRITISDachG) or state authorities (Sec. 3 (6) KRITISDachG), depending on the sector, such as the BMI (for critical services provided by federal administrative bodies) and the Federal Network Agency (Bundesnetzagentur – BNetzA) (e.g., for critical telecommunications services).

The central contact point for ensuring cross-border cooperation with contact points in other Member States (Art. 9 (2) CER Directive) is the BBK, Sec. 3 (1) KRITISDachG.

The BBK is the competent authority for imposing administrative fines for violations of registration requirements; in all other cases, the competent (sector-specific) authority pursuant to Sec. 3 (2) sentence 1 KRITISDachG (Sec. 24 (3) KRITISDachG) is responsible.

  • Conclusion and Outlook

With the KRITISDachG, the national legislature supplements existing resilience requirements – which until now have been primarily focused on cyber and information security – with physical security requirements. Within the framework of a risk-based “all-hazards approach,” the KRITISDachG establishes continuous and comprehensive resilience management for operators; at the same time, sector-specific exemptions consider the goal of avoiding double regulation.

Even though critical services, resilience obligations, and minimum standards are yet to be specified by statutory ordinance (upon whose entry into force the previously applicable BSI-Kritisverordnung will be repealed), it is advisable for the affected sectors to review the new legal requirements at an early stage, especially since the KRITISDachG provides for substantial fines for violations.

On 10 February 2026, the Federal Government adopted its official government draft (Regierungsentwurf) for the AI Market Surveillance and Innovation Promotion Act (KI-Marktüberwachungs- und Innovationsförderungs-Gesetz – KI-MIG), setting out Germany’s supervisory architecture, enforcement powers, and penalty regime for AI systems under the EU AI Act (Regulation (EU) 2024/1689).

In our earlier overview of EU AI Act implementation across key Member States, we noted that Germany’s national implementation remained underway, with a ministerial draft (Referentenentwurf) dated 11 September 2025. The new government draft is an update of the earlier ministerial draft – especially in relation to competent authorities and administrative fines – and marks the official start of the legislative process.

Supervisory Architecture

Germany has opted for a hybrid supervisory model: no new agency, but a strong central authority supplemented by sector-specific regulators.

BNetzA as central authority: The German Federal Network Agency (Bundesnetzagentur – BNetzA) will be the default market surveillance authority (Sec. 2 (1) KI-MIG), the single point of contact for the EU AI Office (Sec. 6 KI-MIG) and the central complaints office (Sec. 8 KI-MIG). BNetzA will also operate at least one AI regulatory sandbox with priority access for SMEs, start-ups, and research institutions (Sec. 13 KI-MIG).

Coordination and Competence Centre (KoKIVO): Established within the BNetzA (Sec. 5 KI-MIG), KoKIVO pools AI expertise centrally and makes it available to other competent authorities. For companies, this means interpretive guidance will largely flow from one hub, even where a sector-specific regulator is appointed.

Sector-specific authorities: Existing regulators responsible for harmonised EU product legislation (such as medical devices, machinery, radio equipment) will retain competence for AI systems related to those products (Sec. 2 (2) KI-MIG).

Media service providers: There is a notable exception for the media sector. AI systems used by media service providers (as defined in the European Media Freedom Act, Regulation (EU) 2024/1083 – EMFA) for journalistic or advertising purposes are supervised by the “responsibility of the competent authorities under state law”; these are the state media authorities (Landesmedienanstalten) rather than BNetzA (Sec. 2 (8) KI-MIG). This division of responsibilities ensures compliance with the constitutional requirement of state neutrality in media supervision.  The German federal states intend to lay down the relevant supervisory and competence rules for the state media authorities in the planned State Treaty on Digital Media (Digitale-Medien-Staatsvertrag).

BaFin for financial services: The Federal Financial Supervisory Authority (Bundesanstalt für Finanzdienstleistungsaufsicht – BaFin) will receive a broad mandate to supervise AI systems connected to regulated financial activities (Sec. 2 (3) KI-MIG). Supervised entities include credit institutions and insurers, as well as crypto-asset service providers and pension funds (among others). BaFin will develop its own cybersecurity testing guidelines for high-risk AI systems, in agreement with BNetzA and the market surveillance authority under the Cyber Resilience Act (Regulation (EU) 2024/2847) (Sec. 10 (2) KI-MIG). This ensures the EU DORA Regulation (Regulation (EU) 2022/2554) remains the lex specialis, exempting these entities from the standard joint cybersecurity guidelines developed by BNetzA and the federal cybersecurity authority, the Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik – BSI). BSI will exercise this role on a transitional basis until a dedicated market surveillance authority is formally designated under the Cyber Resilience Act (Sec. 10 (4) KI-MIG).

Independent AI Market Surveillance Chamber: For certain sensitive high-risk AI systems an independent three-member chamber (KI-Marktüberwachungskammer) is created within BNetzA (Sec. 2 (5) and 4 KI-MIG), namely

  • biometric AI systems (Annex III No. 1) when used for law enforcement, border management, or justice/democratic processes,
  • as well as all high-risk AI systems in the areas of
    • law enforcement (Annex III No. 6),
    • migration, asylum and border control (Annex III No. 7),
    • and justice and democratic processes (Annex III No. 8).

The KI-Marktüberwachungskammer operates with complete independence and reports annually to the Bundestag. The draft explains why DPAs were not chosen: divergent interpretations, jurisdictional fragmentation, and competition for scarce AI specialists. The chamber’s mandate does not extend to reviewing individual deployment orders (e.g., judicial authorisations for real-time biometric identification) – only to market surveillance of the systems themselves (Sec. 4 (5) KI-MIG).

Federal states carve-out: Where public bodies of the Federal states place AI systems on the market, put them into service or use them, market surveillance will fall to the authorities designated under the respective state law, not to BNetzA (Sec. 2 (6) KI-MIG). This constitutionally required allocation (Eigenstaatlichkeit der Länder) means that companies supplying AI systems to state-level government clients – such as state police forces, courts, or social welfare offices – might need to also engage with the relevant state authority rather than BNetzA.

Investigative and Enforcement Powers

International companies should be aware of the robust enforcement toolkit granted to authorities under the draft law.

Extensive Inter-Agency Information Sharing: German market surveillance authorities are explicitly permitted to exchange information with each other, including personal data and business and trade secrets, if strictly necessary to fulfill their tasks (Sec. 9 KI-MIG) . While bound by confidentiality, this creates a highly networked environment where findings can be seamlessly shared between authorities like the BNetzA, the Data Protection Authorities (DPAs) or the Federal Cartel Office (Bundeskartellamt).

Remote Access and External Experts: Authorities can exercise their investigative powers remotely via Application Programming Interfaces (APIs) or other technical means. They are also permitted to hire external third-party experts (Verwaltungshelfer) to assist with technical processes and investigations (Sec. 11 (2) KI-MIG).

Unannounced Inspections: Inspections of premises and vehicles can be conducted unannounced during regular business hours, and even outside these hours to prevent urgent threats to public safety and order (Sec. 11 (3) KI-MIG).

Immediate Enforcement: Legal challenges (objections and lawsuits) against decisions made by BaFin, or decisions regarding specific products like medical devices and radio equipment, have no suspensive effect (keine aufschiebende Wirkung) (Sec. 11 (7) KI-MIG). This means companies must comply with the regulatory order immediately, even while appealing it.

Enforcement Tactics: The explanatory memorandum highlights that authorities will proactively police the market through anonymous test purchases (mystery shopping) in e-commerce and physical stores, and by cooperating closely with customs authorities and online platforms.

Administrative Fines

EU AI Act fines apply directly. But German administrative offence procedures will apply (Sec. 16 KI-MIG), displacing Sec. 17 and Sec. 30 (1) and (2) of the German Administrative Offences Act (Ordnungswidrigkeitengesetz).

The KI-MIG will also add supplementary national fines of up to EUR 50,000 for violations not covered by Art. 99 of the AI Act, including failures related to information transmission (Art. 21), fundamental rights impact assessments (Art. 27), duties of notified bodies (Art. 45) and explanations to affected persons (Art. 86 (1)) (Sec. 15 KI-MIG).

Strict Obligations Upon Ceasing Business (Liquidation)

For international companies setting up German subsidiaries or appointing a German authorised representative (Bevollmächtigter), the draft contains requirements regarding the end of a business lifecycle. If the provider or the authorised representative ceases its business activities, the legal obligation to retain all AI Act-related documentation automatically transfers to the person responsible for the liquidation or the insolvency administrator (Sec. 18 KI-MIG).

Whistleblower Protection

The government draft will also amend Germany’s Whistleblower Protection Act (Hinweisgeberschutzgesetz) to explicitly cover violations of the EU AI Act (Art. 2 of the draft). This means that persons who report AI Act violations will benefit from the full protections against retaliation available under German whistleblower law, implementing Art. 87 of the EU AI Act.

Innovation Promotion

BNetzA will operate an AI Service Desk (which it has already started to establish), deliver awareness and training programmes (especially for SMEs), and advise public-sector bodies on AI system classification (Sec. 12 KI-MIG). The AI regulatory sandbox extends priority access to research institutions and universities (Sec. 13 KI-MIG). For real-world testing of high-risk AI outside sandboxes, a tacit approval mechanism applies: if the authority does not respond within 30 days, the test is deemed approved (Sec. 14 (2) KI-MIG).

Next steps

The adoption of this government draft marks the official start of the legislative process. Although this is not yet the final law, the government has signaled a clear intent to fast-track proceedings given that the EU AI Act’s implementation deadline of 2 August 2025 has already been missed.

We expect the Bundestag to debate the draft in the coming weeks. Stakeholders should pay close attention to potential amendments, particularly regarding the exact delineation of powers between the BNetzA and other authorities as well as the entry-into-force date after enactment.

In a significant stride toward strengthening digital stability in Europe’s financial sector, the European Supervisory Authorities (EBA, EIOPA, and ESMA) have, today, published the list of critical ICT third‑party service providers under the Digital Operational Resilience Act (DORA). This move gives the ESAs direct oversight of some of the most pivotal vendors supporting financial institutions with a presence in the EU with digital and data services provided via information communications and technology systems.

Why this matters:
Financial entities across the EU rely heavily on digital platforms and infrastructure, from cloud computing, data centres, data analytics, cybersecurity and communications. With systemic cyber risk on the rise, DORA’s oversight framework aims to ensure that designated providers maintain robust risk management. Those designated can now face direct audits/governance reviews, incident-reporting mandates, and potentially onsite inspections. The focus is on ensuring that steps are being taken to prevent service disruptions that could ripple through the financial sector.

Next steps:

  • Financial firms, caught by DORA, should review the list and align sourcing agreements and third-party risk frameworks accordingly.
  • The designated critical ICT providers should audit internal policies and procedures against DORA’s requirements to ensure readiness for direct ESA oversight.

To access the list of designated critical ICT providers, see here:

The European Supervisory Authorities designate critical ICT third-party providers under the Digital Operational Resilience Act | European Banking Authority

You can view our latest DORA content at Application of the Digital Operational Resilience Act (DORA): Key considerations | DLA Piper

First Glance at the 2025 Draft

On 25 June 2025, the European Commission has proposed the draft of the EU Space Act.

This proposed new law is intended to provide a harmonised regulatory framework at European level from 2030 to ensure safety, resilience, and environmental responsibility across the EU, while helping space tech companies grow and scale across borders.

Safety, resilience and sustainability

The three main pillars of the EU Space Act are safety, resilience and sustainability:

  • Safety: The proposed EU Space Act, if adopted, will introduce measures to improve the tracking of space objects including collision avoidance services and limit new debris, including requirements for safe satellite disposal at the end of their operational life.
  • Resilience: The proposed EU Space Act, if adopted, will require all space operators to conduct thorough risk assessments throughout a satellite’s lifecycle, applying cybersecurity rules and incident reporting tailored to the space sector. 
  • Sustainability: The proposed EU Space Act, if adopted, will set common rules for life cycle assessment and a shared database to ensure consistent verified data and encourage innovation in areas such as in-space servicing to extend satellite life and reduce debris.

In a nutshell:

The proposed EU Space Act aims to:

  • Establish a Union legal framework for the provision of space-based data and services by Union space operators to foster innovation and create a stable. predictable, and competitive business environment (level playing field).
  • Ensure the trackability of space objects and reduce the generation of space debris, thereby enhancing the safety of space activities.
  • Create a risk assessment framework tailored to the specific cybersecurity needs of space infrastructure, enhancing the resilience of space activities.
  • Create a common method for calculating the environmental impact of space activities in the Union, enhancing sustainability.

Key take aways

The draft comprises 119 articles with many details, but there are a number of requirements that immediately stand out:

  • Union space operators will need authorisation for providing space services. This will be a licence from one EU member state that will be accepted by all the other EU member states.
  • The draft also includes requirements for third country (= not EU) space operators.
  • The UK will be treated as a “third country” for the purposes of the Act. 
  • The European Union Agency for the Space Programme (EUSPA) will be given significant new tasks and responsibilities, including conducting technical assessments to assist the authorization and supervision of Union-owned assets and third-country operators, managing the Union Register of Space Objects (URSO), and issuing e-certificates to attest compliance. The EUSA also establishes the Union Space Resilience Network (EUSRN) for enhanced cooperation on cybersecurity incidents.
  • The EU Commission and the Agency will have far-reaching powers, including “on-site inspections” and imposing fines of up to 2 % of the total worldwide annual turnover. The proposed EU Space Act complements existing laws like the NIS 2 Directive on cybersecurity and the CER Directive on physical resilience of critical entities, by filling gaps specific to space infrastructure and ensuring a tailored resilience baseline for the sector.
  • The proposal suggests a common method for calculating the environmental footprint of space activities, including design, manufacturing, operations, and end-of-life stages, to promote greener technologies and align with EU Green Deal objective.

Further information

The European Commission has identified the space economy and the EU Space Act as a key priority and has published additional documentation with the draft:

Application and next steps

The EU Space Act is intended to apply to both EU and national space assets, as well as to non-EU operators offering services in Europe.

At the moment, it is still a draft proposal that is subject to negotiations in the European Parliament and in the Council, under the ordinary legislative procedure.

After being officially adopted, the EU Space Act will be a regulation applicable and binding in all EU member states. The draft provides for application from 1 January 2030 with a transitional period of 2 years.

In a recent webinar forming part of DLA Piper’s ‘Digital Evolution in conversation with’ series, Kristof de Vulder caught up with Alessandro Ferrari, Linzi Penman and Conor McEneaney to discuss the scope and impact of the upcoming Digital Operational Resilience Act (DORA). They offered practical guidance to organisations dealing with one of the most comprehensive gap analysis and remediation exercises to face the EU financial services sector in recent years.  The date for compliance is 17 January 2025 so read below for a summary of their insights.   

The main impact of DORA  

DORA is bringing a significant shift to the financial services sector in terms of how organisations must manage operational risk and ensure they can continue to deliver critical operations during a disruption. The regulatory focus has moved from protection to ‘resilience’. This is a much broader concept that encompasses preventing disruption, mitigation of an incident, and how to address the consequences of, and recover from, a disruptive event. 

For financial entities, DORA introduces a structured set of requirements that will force organisations to re-evaluate: 

  • Data, cyber and contractual governance; 
  • risk management policies and processes;  
  • technology estates and testing approaches;  
  • incident management framework; and  
  • tech and data contracts.  

These organisations are subject to extensive regulation already but DORA’s new requirements will bring yet more scrutiny and operational adjustment, adding another layer of rigour and cost. DORA also has a wide reach, applying to both intra-group and external ICT service providers and creating a dual-compliance requirement. The principle of proportionality, which is central to DORA, allows financial entities to adapt their compliance programmes according to the criticality and risk level of their services. 

However, compliance strategies must be actively assessed to demonstrate that proportional measures are appropriate. To meet these requirements, some uplifts with be legal (e.g. contract risk tolerance and scope). Others will be operational (e.g. policy, procedure and risk and resilience). This will involve strategically prioritising critical functions and leveraging existing controls and processes where possible. 

Firms in violation of DORA may face fines of up to 2% of their total annual worldwide turnover. 

Certain ICT service providers to the sector will be designated as critical. They will be subject to direct scrutiny and oversight by financial regulators for the first time, which could involve onsite supervision, being directed to take remedial action, and potential direct regulatory penalties for non-compliance. This will be a huge shift from a governance and control perspective. DORA will still impact other ICT service providers and their supply chains, through the DORA-mandated contract clauses.   

The impact on contractual arrangements 

There is a lot of focus in the market now on the contractual requirements provisions of DORA.  We are actively advising both financial entities and service providers in the review and negotiation of DORA addenda to remedy DORA compliance gaps that have been identified from a contractual requirements perspective.   

We are seeing several different approaches in the market. At one end of the spectrum, there are all-encompassing projects where a gap analysis due diligence exercise is carried out and then, based on the output of that, tailored addenda for each in-scope contract are prepared. At the other end of the spectrum, a ‘one size fits all’ addendum is being rolled out to the market.  Those that have been through similar contract remediation exercises such as for the EBA Guidelines on Outsourcing or for the GDPR will be familiar with the common negotiation issues we are seeing in the market. For example, whether suppliers can charge for assistance provided to customers and whether the use of endeavours qualifications are acceptable.   

We are also seeing some customers look for additional contractual commitments from their suppliers beyond those expressly called out as contractual requirements in Articles 28(7) and 30 of DORA. An example of this is the confidentiality implications of sharing cyber threat information with peers under Article 45 with some customers looking for express carves out from their confidentiality commitments for such sharing.  

There are a number of supply chain practical considerations for services providers in relation to how they respond to DORA’s contractual requirements. This includes the need to flow-down specific contractual provisions to sub-contractors for critical or important functions.  

There is no transitional period under DORA for the remediation of existing contracts and this poses a major bandwidth and volume challenge for financial entities. In our experience, most larger organisations have started their DORA ‘repapering’ projects already. Some customer side entities are opting to remediate contracts for all ICT services now, while others are prioritising those services supporting critical or important functions, given the volume of affected contracts and the resource commitment involved. DORA defines ICT services broadly and includes services that were previously excluded from regulatory requirements or guidance (such as data analytics and data feeds), often necessitating a more nuanced exercise to determine which services are in scope. For regulatory purposes, financial entities will want to document how they arrived at their definition and determination of in-scope ICT services. This should be reflected in their ICT risk management processes for on-going adherence.    

Except for large cloud service providers, our experience is that suppliers are generally not as far forward. We see some suppliers communicating to customers that they are not engaging with customers on contract remediation until all of the regulatory technical standards under DORA have been adopted. This could begin to hinder sales.  

Preparing for 17 January 2025 – key takeaways 

For financial entities: 

  • If you have not yet started thinking about DORA compliance, there is still time to remediate your contracts for DORA but the time for action is now. Regulatory authorities are already starting to investigate levels of compliance by financial entities with DORA. 
  • Initiate a comprehensive DORA applicability assessment and gap analysis – including a review of existing processes, risk management and operational structures (including roles and responsibilities), and especially ICT contracts. Document your plan to translate that analysis into action. Focus on services that support critical and important functions and have third party dependencies, as that will help you to identify elements needing the most attention. Regulators will be looking to see what steps you have taken towards compliance and your analysis of priority areas. 
  • Do not assume that your ICT contracts will be DORA compliant if they comply with the EBA’s outsourcing guidelines. DORA is broader in scope and, while not everything in DORA is new, it does introduce new requirements and these are often detailed. Every financial entity will have to do a gap analysis of its ICT contracts against DORA.   

For service providers:  

  • There is no escape from DORA, even for large service providers to the sector who are used to operating on their standard terms. Certain contract provisions must be included for in-scope services to financial services clients. Taking a proactive approach, by integrating minimum DORA requirements into contract terms and producing contract playbooks, will help to put you on the front foot. Failure to comply could be a revenue blocker, especially at contract renewal phases or during due diligence onboarding. 
  • Look at what remediation exercise is needed with your own suppliers and supply contracts, to ensure that all links in the supply chain are aligned with DORA requirements and adequately prepared. Consider stress testing service levels to check if the current levels and performance standards are equipped to withstand the increased scrutiny from financial entities. 
  • You may already have (some) security and incident management structures including disaster recovery planning, penetration testing and vulnerability assessments. These should be revisited to confirm that your operational processes map to what you commit to contractually.  
  • DORA introduces new requirements that may bring additional cost and complexity for your wider organisation (such as additional processes and controls, participation in training and change, and testing services). Consider what the costs to you might be during the contract term, so that you are not caught out.  

DORA’s extensive scope can seem daunting, with significant changes needed for compliance, even applying the proportionality principle. Enforcement is looming in just a few months. Our view is that responding to DORA can be targeted, and defensible compliance is possible before enforcement commences. DLA Piper offers integrated advice and implementation support to define and meet a proportionate level of compliance. We can help you comply without overextending resources or changing excessively to address gaps and emerging issues to meet DORA obligations quickly. 

If you missed the webinar, you can view the recording and find out more about our upcoming events in the series here: Digital Evolution in conversation with | DLA Piper 

BACKGROUND

The PRA, FCA and the Bank of England (the Regulators) have identified, for some time, the growing dependency of the UK finance sector on critical third parties who supply services to the finance sector (CTPs), including, in particular, the largest cloud service providers. The Regulators have identified that this reliance on certain CTPs, without due oversight and controls, could pose a systemic threat to the stability of the UK financial system.

The same risk has been identified by regulatory authorities in Europe, who have legislated to try to mitigate the exposure, including the implementation of the EU Digital Operational Resilience Act (DORA), which has passed in to law and will apply from 17 January 2025 in EU Member States.

    On 7 December 2023, the Regulators published a Consultation Paper (CP26/23) that sets out the UK Regulator’s response to this risk area and the proposed requirements for CTPs to the UK finance sector (Proposed CTP Regulations).

    EXECUTIVE SUMMARY

    The Proposed CTP Regulations include guidance as to how third parties will be designated as CTPs and a series of proposed obligations on CTPs with a view to managing potential risks to the stability of the UK financial system that may arise due to a failure in, or disruption to, the services that a CTP provides to financial entities (firms) and financial market infrastructure entities (FMIs).

    The proposed obligations on CTPs include rules in relation to risk and resilience management, management of supply chain, management of cyber risk, incident management, continuity of service for service recipients (on termination), scenario testing, notifications to service recipients and Regulators, record keeping and cooperation with Regulators.

    The Proposed CTP Regulations are a further step towards recognising the importance of service providers themselves, as opposed to simply requiring the firms and FMIs to take appropriate actions in relation to their use of their services (whether via their contract terms or otherwise). Firms and FMIs should benefit from the scrutiny and direct oversight by the Regulators of the CTPs, and the imposition of additional and direct obligations on CTPs to help manage security, supply chain risk and business continuity risks.

    Whilst the Proposed CTP Regulations align with DORA in creating a new regime for CTPs, we note that, in contrast to DORA, the Proposed CTP Regulations have a less broad scope than some of the standards set out in DORA and in particular do not include obligations on the CTPs to include particular contractual provisions or undertakings in their contracts with their customers in the financial services sector. For example, where DORA requires service providers to include certain termination rights and service levels for the benefit of the service recipients, there are no such requirements included in the UK regime. Equally, the Proposed CTP Regulations, unlike DORA, do not contemplate the application of rules to any other providers of information technology service providers that are not designated as CTPs, but that nonetheless provide services that might relate to the critical or important functions of the financial entity.

    WHAT ARE CTPS & HOW WILL THEY BE IDENTIFIED?

    HM Treasury (HMT), in consultation with the Regulators, will have the power to designate certain third parties that provide services to firms or FMIs as a CTP.

    The key consideration for HMT is whether it believes that a failure in or disruption to the services provided by the third party in question could threaten the stability of, or confidence in, the UK financial system.

    HMT must bear in mind the following two high-level criteria when making a CTP designation:

    • the materiality of the services that the third party provides to firms and FMIs to the delivery of essential activities, services, or operations; and
    • the number and type of firms and FMIs to which the person provides services.

    Regulators could also consider the potential impact of the failure or disruption of services provided by third parties, taking into account possible factors such as substitutability of their services (and the lack of viable alternative). Regulators will also have regard to reports from firms and FMIs regarding third party support for their “Important Business Services” as defined under the Regulators other operational resilience policies / rules (including, for example, PRA SS 1/21).

    The third parties likely to be identified are those whose failure/disruption could have an impact on the supervisory authorities’ objectives, including UK financial stability, market integrity and consumer protection. A key point is recognition is that the impact must be likely to be systemic, not just impactful, for a particular FMI or firm. Accordingly, CTPs are expected to account for a very small number and percentage of those third parties providing services to firms and FMIs. They will also not include service providers who are already subject to other regulatory regimes which are likely to provide the same or similar levels of comfort to that which the Proposed CTP Regulations seek to provide.

    We note three developing areas are identified where the designation is likely to become increasingly important: the widespread use of AI, quantum computing and hyper-scale cloud.

    SCOPE OF APPLICATION OF THE PROPOSED RULES

    It is proposed that the rules will apply to CTPs in relation to their provision of services to firms and FMIs (in the UK) and will be agnostic as to the location of a CTP. Accordingly, for example, US domiciled services providers (such as the main hyperscale IaaS organisations) will fall within the ambit of the rules.

    However, the regulators propose to apply their most granular proposed requirements and expectations only to CTP’s material services to firms and FMIs.

    WHAT ARE THE PROPOSED RULES / REQUIREMENTS?

    In summary, the obligations placed on CTPs include the following key elements:

    Fundamental Rules

    CTPs will be required to comply with certain” fundamental rules” under the oversight regime. These rules are set out at a high level, and will likely provide the regulators with a broad scope for interpretation (especially with the benefit of hindsight!). The Fundamental Rules are that a CTP must:

    • Conduct its business with integrity.
    • Conduct its business with due skill, care and diligence.
    • Act in a prudent manner.
    • Have effective risk strategies and risk management systems.
    • Organise and control its affairs responsibly and effectively.
    • Deal with the regulators in an open and cooperative manner, and disclose appropriately anything relating to the CTP of which the regulators would “reasonably expect” notice.

    These are widely stated obligations (effectively the proactive notification requirement) and will likely operate to in effect create a de facto presumption of breach in any circumstance where a major incident or outage has caused disruption to the financial services system.

    Operational Risk and Resilience Requirements

    CTPs will be required, in relation to material services, to comply with eight broad requirements including the following:

    • Governance – Establish clear governance in relation to responding to events that cause disruption to services, including the appointment of a central point of contract for the Regulators.
    • Risk Management – Set up risk management processes and frameworks, including in relation to supply chain, cyber, data and financial risks, to be updated on an ongoing basis.
    • Supply Chain – Manage risk to its supply chain, including managing “Nth party” service provider risk, and making third parties aware of and ensure they facilitate the CTP’s regulatory requirements, including permitting access to regulators to oversee the CTP’s operations. CTP’s should test supply chain disruption in its internal audit process.   
    • Technology and Cyber Resilience – Ensure the resilience of any technology that supports a service, including by having technology and cyber risk management and operational resilience measures and regular testing of those measures.
    • Change Management – Ensure that it has effective approach to dealing with changes to a material service, including changes to the processes or technologies used to support a material service.
    • Mapping – Identify resources, including technology, used to deliver, support, and maintain each material service it provides.
    • Incident Management – Manage incidents that may affect the delivery of a material service, including by implementing appropriate measures to respond and recover from incidents in a way that minimises their impact, including documenting tolerance levels for disruption to services, business continuity plans and maintaining a financial sector incident management playbook.
    • Termination – Put in place measures to respond to a termination of any of its material services, including arrangements to support the orderly and timely termination of those services, including (if applicable) their transfer to another person, and provision for ensuring access, recovery, and return of any relevant assets (including data) to the firms or FMI service recipients.
    Information-gathering, Self-assessment and Testing
    • Information-gathering – CTP’s must be able to evidence compliance with the rules on an annual basis and upon request.
    • Self-assessment – CTP’s will be required to submit a balanced and thorough self-assessment of compliance with the rules, including areas for improvements.
    • Testing – CTP must carry out regular scenario testing of its ability to continue providing each of its material services within its maximum tolerable level of disruption in the event of disruption to its operations. CTP must also test the measures in its financial sector incident management playbook annually.
    • Sharing of assurance and testing information with firms and FMIs – CTPs must ensure sufficient and timely information is given to firms and FMIs it provides services to in order to enable them to manage risks related to their use of the CTP’s service.
    Notifications
    • Incident Notifications – The incident notification requirements apply to an incident (planned or unplanned) that actually or has the potential to seriously disrupt the delivery of a material service; or seriously and adversely impact the availability, authenticity, integrity, or confidentiality of assets relating to the firms.
    • Notification to firms, FMIs and regulators – CTPs must provide to the firms, FMIs and regulators an initial incident notification, one or more intermediate incident notifications and a final incident notification. The notifications must provide sufficient information in relation to the details of the incident, including the services impacted, the cause, the steps taken to restore the service, the anticipated recovery time and, once a relevant incident has been resolved, identified areas for improvement.
    • Other Notification Requirements – CTPs must also notify regulators in circumstances where they are (i) involved in disputes or proceedings that pose a significant threat to its reputation or ability to provide any material service, (ii) subject to criminal proceedings or sanctions, or (iii) subject to financial difficulty and considering entering into an insolvency proceeding or restructuring plan.
    Record Keeping

    Orderly Records – CTP must arrange for orderly records to be kept of its business in so far as it concerns the provision of services to firms or FMIs. These records must be sufficient to enable each Regulator to perform its oversight functions and ascertain whether or not the CTP has complied with its duties.

    CONCLUSION

    The Proposed CTP Regulations are significant to those service providers that may be designated to be CTP and who have not historically have been subject to direct oversight from the Regulators.

    Firms and FMIs should benefit from the scrutiny and direct oversight by the Regulators of the CTPs, and the imposition of obligations on CTPs, including in relation to information sharing, security, supply chain management and business continuity.

    We note, however, the Proposed CTP Regulations are less comprehensive than DORA. In contrast to DORA, the proposed regime falls short of including obligations on the CTPs to include particular contractual provisions or undertakings in their contracts with service recipients. For example, where DORA requires service providers to include certain termination rights and service levels for the benefit of the service recipient, there are no such requirements included in the UK regime. Equally, the Proposed CTP Regulations, unlike DORA, does not contemplate the application of rules to any other providers of information technology service providers, that are not designated as CTPs, but that nonetheless provide services that might relate to the critical or important functions of the financial entity.

    For more information regarding DORA and how it will affect your business, please contact either Kit Burden, Duncan Pithouse or David Ossack.

    The arrival of NIS2 is only one year away. With significantly enhanced requirements around cybersecurity management extending across the supply chain, increased reporting obligations in the case of cyber breach, and personal liability for senior management, working out whether or not an organisation will be in scope for NIS2 will be an important question, instigating possible months of preparations if the answer is yes. NIS2 has increased the number and type of sectors to which former NIS1 rules will apply, but the question of NIS2’s application will also depend on an organisation’s size and where it offers its services.

    Unpacking the scope and territoriality rules under the NIS2 Directive

    One year from now – on 17 October 2024 – the implementation deadline of the second Network and Information Systems (“NIS2”) Directive will be upon us. As the countdown to that deadline begins, many organisations will be looking to determine the all-important question: Are we caught by NIS2?

    Having substantially enhanced the cybersecurity obligations on in-scope entities from those found under the first NIS Directive, including enhanced reporting obligations, personal liability for management bodies and broad supply chain impacts, being caught by NIS2 is not a something an organisation can take lightly. For those in scope, preparation will be key to ensuring cyber standards are up to scratch, supply chains are ready and an organisation’s executive can stand by their cybersecurity measures.

    What is NIS2?

    Part of the EU’s Cybersecurity Strategy, NIS2 repeals and replaces the original NIS Directive which entered into force in 2016 (with Member State implementation by 9 May 2018). Much like its predecessor, it establishes measures for a common level of cybersecurity for critical services and infrastructure across the EU. Recognising the ever-growing threat which cyber-crime poses for the economic and societal stability of the Union, NIS2 aims to harmonise cyber-resilience through the following obligations:

    • Ensuring appropriate and proportionate cybersecurity risk management measures are in place following an “all-hazards” approach which is proportionate to risk, entity size, the likelihood of a security incident and the severity of economic/social impact were it to happen. Notably, and unlike its NIS1 predecessor, the cost of implementation can be taken into account when determining what measures are appropriate and proportionate.
    • Supply chain diligence – as part of assessing its own cybersecurity measures, an in-scope organisation must now assess and assure the cybersecurity practices of its supply chain including how cybersecurity obligations are driven by contractual mechanisms.
    • Three-stage reporting obligations upon the occurrence of a “significant incident”[1] – the first report required will be an early warning within 24 hours of first awareness. This should be followed by a second, more comprehensive notification within 72 hours, and a more detailed report within one month of the initial notification.
    • Executive approval and oversight – management bodies of in-scope entities must both approve and oversee the implementation of its cybersecurity risk management measures. They will be personally liable to any fines which might result from a breach. NIS2 also gives supervisory authorities the power to suspend relevant management functions pending implementation of measures to address any breach. Management bodies are also required to undertake and follow training on cybersecurity measures, and offer similar training to their employees on a regular basis.
    • Enhanced supervision and enforcement – these can be grouped into powers of audit and inspection, enforcement and temporary suspension of management obligations/ relevant security certifications. The award of fines will be in addition to other enforcement measures, and can reach a maximum €10 million/ 2% of total global annual turnover for Essential Entities, and €7 million/ 1% for Important Entities.

    Who is in scope for NIS2? Unpacking the three-limbed criteria

    The reach of NIS2 is significantly wider than its predecessor. No longer applying solely to “Operators of Essential Services” and “Digital Service Providers”, NIS2 has been expanded to include a greater number of named sectors including: managed service providers, social media, waste management, medical device manufacturers, postal services, food, space (as in rockets, not storage), chemical distribution and public administration services.

    The main determining factor of whether an entity is in scope will be whether it falls within those sectors specifically called out in the Directive. But that may not be determinate, as a listed entity must also meet a size threshold and be providing services or carrying out activities in the EU for NIS2 to apply.

    There are consequently three criteria determining whether or not an entity is in scope for NIS2:

    1. Entity is a sector listed in Annexes I and II
    2. Entity meets or exceeds the definition of Medium Sized Enterprise or is otherwise in scope regardless of size
    3. Entity provides services or carries out activities in the EU

    Does my organisation fall within a sector listed in Annex I or II?

    NIS2 will only apply to those entities falling within Annexes I and II of the Directive. Annex I lists those entities characterised as “Sectors of High Criticality” while Annex II lists “Other Critical Sectors”. The distinction between Annexes has less impact than the further classification of in-scope entities into “Essential Entities” and “Important Entities”. It is this latter distinction which will then determine the level of supervision and enforcement which will apply to the relevant entity. For example, enforcement measures are applied ex post or “after the event” with respect to Important Entity breaches, while for Essential Entities, supervisory and enforcement measures are expected to be more proactive.

    The general rule however is that Annex I sectors will tend to be “Essential Entities” and Annex II will be “Important Entities”. However, the correlation is not always true. For example, Member States have the power to characterise sectors in both Annexes I and II as either “Essential” or “Important” regardless of their size, and government public administration will always be regarded as “Essential”. What becomes clear, therefore, is the importance of Member States, not only in their implementation of the Directive, but also in determining which entities will be in-scope, and how they are classified.

    The Annex I sectors can be broadly described as those providing services in: energy; transport; banking; financial market infrastructure; healthcare providers (including manufacture of basic pharmaceutical products and manufacturing medical devices considered critical during a health emergency); drinking water; waste water; digital infrastructure; IT service management (B2B); public administration; and space.

    Annex II entities are those providing: postal courier services; waste management; manufacture, production and distribution of chemicals; production, processing and distribution of food; and the manufacturing of medical devices, computer, electronic and optical products, electrical equipment, machinery, motor vehicles and other transport equipment (all as defined in section C of NACE).

    Does my organisation meet or exceed the size threshold?

    In order to be considered in scope for NIS2, an entity must meet or exceed the ceilings for medium-sized enterprises (“MSE”) as defined under Recommendation 2003/361/EC.

    Article 2 of the Annex to that Recommendation defines “MSE” as enterprises “which employ fewer than 250 persons and which have an annual turnover not exceeding EUR 50 million, and/or an annual balance sheet total not exceeding EUR 43 million” (emphasis added). In order to qualify as a MSE, a relevant organisation must therefore satisfy both the staff number criteria and the turnover criteria. There is  intentional flexibility built in around whether the turnover or the balance sheet is seen as the indicator of status, but that one such financial indicator should always be combined with the staff criterion.           

    The Recommendation also takes into account an organisation’s relationship with certain “linked” or “partner” enterprises for the purposes of assessing the MSE status (see Article 3 of the Annex to the Recommendation and recital 9 in particular). Therefore, if a small organisation, which otherwise falls below the staff and turnover/ balance sheet criteria is nevertheless linked to another organisation by virtue of factors such as parent company or joint shareholder voting rights, or the exercise of dominant influence over a linked or partner enterprise, it may  qualify as a MSE for NIS2 purposes.

    Does my organisation provide services or undertake activities in the EU?

    Under the final limb of the scope criteria, NIS2 will apply only to those entities who provide services or undertake activities in the EU. This is a narrower test than GDPR, which can catch organisations by virtue of establishment alone, irrespective of whether the target activity – in that case processing of personal data – takes place in the Union or not.

    The outcome of this narrower scope appears to mean that in a model where a global organisation has a parent company outside of Europe and subsidiaries within the EU, only the individual entity physically providing services or undertaking activities in the EU will be caught. However, cyber risk management requirements will apply to the entire supply chain as part of the broader obligations on in-scope entities. As a result, parent companies outside of the EU may still be caught.

    It is also worth noting the rules on jurisdiction and territoriality contained in Article 26. These rules deal with establishment but only for the purposes of determining under which Member State jurisdiction an in-scope entity will fall. This could be important, especially since Member States may interpret and implement the Directive differently, and indeed are permitted to exceed its baseline standards when implementing NIS obligations into Member State law. Member States will also be key to determining which entities will be in scope for NIS2 within their jurisdictions and therefore who will be under the watchful eye of their regulators.

    Is there a materiality criteria for the application of NIS2?

    One final factor to consider is whether or not the services caught by NIS2 are sufficient to trigger application of the Directive when they constitute a minor part of an organisation’s overall offerings. For example, if 95% of an organisation’s services are not listed in Annex I or II of the Directive (or are otherwise not provided within Europe), but 5% of its services are of a nature that they are caught by Annex I or II (or provided within Europe), will that 5% be sufficient to bring the whole organisation into the scope of NIS2?

    The simple answer is that there doesn’t appear to be a materiality criteria for the application of NIS2. The scope of the Directive is determined by the three factors stated above. While the size of the entity is therefore a factor, the proportion of its business activities, in so far as there are various, does not appear to be relevant. Rather this is something of an all or nothing question: If, as an entity, you distribute chemicals as listed in Annex II, you are an entity in scope for NIS2 (assuming the MSE and EU activities criteria are also passed).

    The result is that this will invariably come down to a risk assessment, by an organisation, around the applicability of NIS2. If a mere 5% of its business is in scope, is that enough to attract the attention of a Member State regulator if NIS2 is not being complied with?

    Here, it is important to remember that under Article 3(3), it is Member States who will ultimately have the final say over which organisations they will include on a Member State’s list of Essential and Important entities falling within their jurisdiction. This list must be provided to the EU Commission by 17 April 2025.

    We do not yet know how each Member State will come to pull this list together, and guidance around Article 3 NIS2 published by the EU Commission on 13 September 2023[2] did little to clarify the matter. There is of course the very high possibility that Member States will interpret NIS2 differently, resulting in lists which look very different from one jurisdiction to another. The result is that to some extent, the decision of applicability may be outside of an organisation’s control, and it will be interesting to see whether any form of appeals process may be put in place where an organisation does not agree with a Member State’s determination.

    Direct and indirect application

    For entities that do not directly fall within the scope of NIS2, the application of NIS2 to an in-scope entity’s supply chains may  mean that an organisation finds itself indirectly impacted by the legislation in a way which is almost as significant as being directly in scope. This might be the case, for example, for organisations in the UK who do not provide services within the EU but are nevertheless in the supply chain or businesses who do. It could equally be the case for a small SME who has otherwise fallen outside of NIS2 by virtue of the size criterion mentioned above.

    Under NIS2, in-scope entities must now assure the cyber-reliance of its supply chain when implementing its own cybersecurity risk management measures. The Directive does not provide a lot of detail on how this translates into practical assurance measures, although reference is made to the contractual mechanisms used to obtain legally enforceable guarantees of a supplier’s cybersecurity measures. Supply chain organisations might therefore expect to see enhanced contractual obligations relating to their security stance, but also increased rights of due diligence and audit in favour of the customer/ in-scope organisation.

    Additionally, since supply chain organisations might also be key to facilitating the in-scope entity’s compliance with NIS2 reporting requirements, we are also expecting to see more exacting requirements making their way into contracts which require supply chain businesses to provide timely and detailed reporting, together with ongoing assistance, with respect to security incidents meeting the reporting threshold. While these obligations may not be novel in the age of GDPR security reporting, it should be remembered that NIS2 reporting will apply to cyber incidents more broadly, and not just those impacting on personal data.

    Conclusion – Is an organisation in scope for NIS2? Member States may yet have the final word

    The scope of NIS2 is far from straightforward, and for any organisations left pondering the application of NIS2 to their businesses, clarity is likely to come when Member States get involved.

    Not only will Member States have until 17 October 2024 to transpose the Directive into their national law, but as discussed above, they are also required to produce a list of Essential and Important entities to whom they consider NIS2 applies. However, the deadline for doing so is 17 April 2025, some 6 months after the implementation deadline, which could mean further uncertainty for those organisations unclear on the application of NIS2 when it first becomes national law.

    There is however likely to be a degree of consultation between in-scope organisations and Member States – Article 3(4) NIS2 for example recommends Member States operate a self-registration portal for those entities who believe they are in scope, and suggests that a degree of consultation between Member States and target entities will be likely. It isn’t however clear whether Member States will offer an appeals process for entities who do not agree with a Member State’s determination that they are in scope for NIS2. There is also every possibility that an organisation operating across multiple Member States could find themselves in scope of NIS2 in one Member State, and not in another.

    All this means that for organisations on the fringes of NIS2, the question of its application remains unclear. In such circumstances, organisations should consider preparing as though NIS2 will apply –  in addition to the risks of fines and enforcement under NIS2, taking pre-emptive action by, for example, improving cyber security management, and the awareness of cyber risks at a senior management levels is an opportunity for organisations to build customer trust, strengthen market position and minimise the risks of cyber-attacks occurring.

    For advice on whether or not your organisation is likely to fall under NIS2, please contact the author or your usual DLA Piper contact.

     
     

    [1] Defined as an incident “causing or being capable of causing severe operational disruption of services or financial loss or has affected or is capable of affecting natural or legal persons by causing considerable material or non-material damage”.

    [2] Commission Guidelines on the application of Article 3(4) of Directive (EU) 2022/25555, C(2023) 6070, 13 September 2023