What is the CRA?

The CRA is a harmonising EU regulation, the first of its kind focusing on safeguarding consumers and businesses from cybersecurity threats.  It is a key element of the EU’s Cybersecurity Strategy for the Digital Decade.

The CRA is designed to fulfil a perceived gap in EU regulation and sets uniform cybersecurity standards for the design, development and production of hardware and software products with digital elements (PDEs) placed on the EU market – introducing mandatory requirements (e.g. relating to security vulnerabilities, and addressing transparency) for manufacturers and retailers, extending throughout the product lifecycle.  With few exceptions for specific categories, the CRA covers all products connected directly or indirectly to other devices or networks.

Scope of the CRA

The CRA applies to all economic operators of PDEs made available on the EU market. This includes:

• manufacturers (and their authorised representatives);
  
• importers;
  
• distributors; and
  
• any other natural or legal person subject to obligations in relation to the manufacture of PDEs or making them available on the market (including retailers).

The reach of the proposed CRA is broad, covering all PDEs whose intended and reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

A PDE is defined as “any software or hardware product and its remote data processing solutions, including software or hardware components to be placed on the market separately” (Article 3(1) CRA).

Remote data processing is defined as “any data processing at a distance for which the software is designed and developed by the manufacturer or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions” (Article 3(2) CRA).

Whilst the usual example of in-scope products is smart devices, such as smartphones, this is complicated in respect of software products involving remote data processing solutions: the CRA supporting FAQ indicates that software which forms part of a service rather than a product is not intended to be covered.

It is therefore important to identify how products are provided – as software products with remote data solutions, or software which is part of a service. This analysis will need to take into account how the various ‘features’ making up each product are provided.

Manufacturers are broadly defined as “any natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under his or her name or trademark, whether for payment or free of charge” (Article 3(13) CRA).

Exceptions:

The CRA excludes from its scope a limited number of products and/or fields which are considered to be already sufficiently regulated, including:

• Products which are in conformity with harmonised standards and products certified under an EU cybersecurity scheme; and
  
• Medical devices, aviation devices, and certain motor vehicle systems/components/technical units, to which existing certification regimes apply.

Obligations of economic operators

The primary objective of the CRA is to address a perception at EU institutional level of a poor level of cybersecurity and vulnerabilities in many software and hardware products on the market. The CRA also aims to address the lack of comprehensive information on the cybersecurity properties of digital products to enable consumers to make more informed choices when buying products. With this in mind, the CRA imposes a large number of obligations upon relevant economic operators, with the majority of obligations falling on “manufacturers” of PDEs.

Key obligations on manufactures under the CRA include:

• When placing a PDE on the EU market, ensuring that it has been designed, developed and produced in accordance with the essential requirements set out in Section 1 of Annex I CRA. The high level requirements set out in Annex 1, Part 1 CRA, include that products with digital elements “shall be designed, developed and produced in such way that they ensure an appropriate level of cybersecurity”, to ensure protection from unauthorised access by appropriate control mechanisms, and protect the confidentiality and integrity of stored, transmitted or otherwise processed data; to be designed, developed and produced to limit attack surface, including external interfaces. These requirements may be clarified as the European Commission is authorised to adopt implementing acts establishing common specifications covering technical requirements that provide a means to comply with the essential requirements set out in Annex 1 CRA;
  
• Undertake an assessment of the cybersecurity risks associated with a PDE, taking the outcome of that assessment into account during the planning, design, development, production, delivery and maintenance phases of the PDE, with a view to minimising cybersecurity risks, preventing security incidents and minimising the impacts of such incidents, including in relation to the health and safety of users;
  
• Document and update the assessment of the cybersecurity risks associated with a PDE and take the outcome of that assessment into account during the planning, design, development, production, delivery and maintenance phases of the product with digital elements;
  
• Exercise due diligence when integrating components sourced from third parties in PDEs and ensure that such components do not compromise the security of the PDE;
  
• Document relevant cybersecurity aspects concerning the PDE, including vulnerabilities and any relevant information provided by third parties, and, where applicable, update the risk assessment of the product;
  
• Put in place compliant vulnerability handling processes, including providing relevant security updates, for the duration of the support period (of, in principle, five years);
  
• Report actively exploited vulnerabilities to the relevant Computer Security Incident Response Team (CSIRT) and the EU Agency for Cybersecurity (ENISA) without undue delay and in any event within 24 hours of becoming aware. The manufacturer must also inform the impacted users of the PDE (and, where appropriate, all users) in a timely manner about an actively exploited vulnerability or a severe incident and, where necessary, about risk mitigation and any corrective measures that they might deploy to mitigate the impact;
  
• Perform (or have performed) a conformity assessment for PDEs to demonstrate compliance with obligations. 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, with more stringent provisions introduced for products deemed “critical”, such as web browsers, firewalls, password managers (designated class I) and operating systems, CPUs (designated class II). These products will have to undergo specific conformity assessment procedures carried out by notified third-party bodies. For each of these procedures, the CRA contains checklists with specifications that must all be met in order to successfully pass. Manufactures must also draw up an EU declaration of conformity and affix a CE marking to the product; and
  
• Ensure that PDEs are accompanied by information, such as the manufacturer’s details and point of contact where vulnerabilities can be reported, and detailed instructions for users including how security updates can be installed and how the product can be securely decommissioned.

Importers and Distributors

The above obligations primarily fall upon manufacturers. However importers and distributors of these products are subject to related obligations regarding those processes, including, only placing on the market PDEs that comply with the essential requirements set out under the law; ensuring that the manufacturer has carried out the appropriate conformity assessment procedures and drawn up the required technical documentation; and that PEDs bear the CE marking and is accompanied by required information for users. Where an importer or distributor identifies a vulnerability in a PDE, it must inform the manufacturer without undue delay, and must immediately inform market surveillance authorities where a PDE presents a “significant cybersecurity risk.”

Overlap with other EU Legislation

The CRA FAQ states that the Act aims to “harmonise the EU regulatory landscape by introducing cybersecurity requirements for products with digital elements and avoid overlapping requirements stemming from different pieces of legislation”. The application of the CRA is subject to certain exclusions where relevant PDEs are already covered by certain regulations – such as the NIS2 Directive and the AI Act (which are considered lex specialis to the CRA as lex generalis). In relation to high-risk AI systems, for example, the CRA explicitly provides that PDEs that also qualify as high-risk AI systems under the AI Act will be deemed in compliance with the AI Act’s cybersecurity requirements where they fulfil the corresponding requirements of the CRA. The listed regulations do not include DORA (Regulation 2022/2554), so there is the potential for overlap for those caught by DORA.

However, Article 2(4) CRA indicates that the application of the CRA may be limited or excluded where PDEs are covered by other Union rules laying down requirements addressing some or all of the risk covered by the essential requirements set out in Annex 1 CRA, in a manner consistent with the applicable regulatory framework, and where the sectoral rules achieve the same or a higher level of protection as that provided under the CRA.

The European Commission may also use its powers to adopt delegated acts in order to further clarify such limitations or exclusions, but in the absence of such delegated acts, the scope is somewhat unclear in respect of financial services entities, given the overlap with DORA.

Enforcement

The CRA provides for extensive participation by public authorities. Accordingly, the European Commission, ENISA and national authorities are granted comprehensive market monitoring, investigative and regulatory powers. For cross-border matters, the 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”. Sweeps will be 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 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.

The 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:

• Breaches of the essential cybersecurity requirements, conformity assessment and reporting obligations may result in administrative fines of up to EUR 15 million or up to 2.5% of annual global turnover, whichever is higher.

• Breaches of the other CRA rules, including requirements to appoint an authorised representative, obligations applicable to importers or distributors, and certain requirements for the EU declaration of conformity, technical documentation and CE marking, may result in administrative fines of up to EUR 10 million or up to 2% of annual global turnover, whichever is higher.

• Organisations which provide incorrect, incomplete or misleading information face administrative fines of up to EUR 5 million or, if the offender is an undertaking, up to 1% of annual turnover.

When deciding on the amount of the administrative fine in each individual case, all relevant circumstances of the specific situation should be taken into account, including the size and market share of the operator committing the infringement.

Non-compliance with CRA requirements may also result in corrective or restrictive measures, including the Market Surveillance Authorities or the Commission recalling or withdrawing products from the EU market.

As the methods for imposing administrative fines will be left to Member States to implement, there is the risk of significant legal uncertainty in relation to enforcement. Although the CRA specifies certain parameters, in particular criteria for the calculation of administrative fines, the proposed regulation raises concerns with regard to the uniform interpretation and application of the rules on administrative fines throughout the EU.

Next procedural steps

The CRA provides for a phased transition period, with the provisions on notification of conformity assessment bodies (Chapter VI) applying from 11 June 2026, and the reporting obligations for manufacturers taking effect from 11 September 2026. The remaining obligations will come into effect on 11 December 2027.  

The CRA is likely to present significant challenges for many companies. It is important that those entities falling within the scope of the CRA start preparing for its implementation. Manufacturers should assess current cybersecurity measures against the upcoming requirements to identify potential compliance gaps and start planning compliance strategies early, including understanding the requirements relating to conformity assessments; technical documentation; and new incident reporting requirements.

Please reach out to your usual DLA Piper contact if you would like to discuss further.

This article provides an overview of the framework for accessing health data for secondary use under the EHDS. It is based on the compromise text of the EHDS published by the Council of the European Union in March 2024.  

Improving access to health data for the purposes of supporting research and innovation activities is one of the key pillars of the EHDS and offers a potentially significant benefit for life sciences and healthcare companies who are looking for improved access to high-quality secondary use data.

By way of reminder, in general terms the EHDS creates a regime under which organisations may apply to a health data access body (“HDAB“) for access to electronic health data held by a third party, for one of a number of permitted secondary use purposes.  When required to do so by the HDAB, the company holding the health data (the health data holder) must then provide the data to the HDAB in order to satisfy the access request. The EHDS provides for safeguards to protect intellectual property rights and trade secrets, and there is some scope for health data holders to recover costs incurred in making data available.  

In more detail, the process operates as follows:

1. Access to secondary health data

The EHDS stipulates a specific process as well as certain requirements for the access to secondary health data.

In order to get access to secondary health data under the EHDS, the applicant must submit a data access application to the health data access body (“HDAB”). Each Member State must designate an HDAB which is, inter alia, responsible for deciding on data access applications, authorizing and issuing data permits, providing access to electronic health data and monitoring and supervising compliance with the requirements under the EHDS.

Further, the HDAB is responsible for ensuring that data that are adequate, relevant and limited to what is necessary in relation to the purpose of processing indicated in the data access application. The default position is that data will be provided in an anonymized format. However, if the applicant can demonstrate that the purpose of processing cannot be achieved with anonymized data, the HDAB may provide access to the electronic health data in a pseudonymised format.

The data access application must include at least the following:

• The applicant’s identity, description of professional functions and operations, including the identity of the natural persons who will have access to electronic health data;

• Which purposes the access is sought for including a detailed explanation of the intended use and expected benefit related to the use (e.g., protection against serious cross-border threats to health in the public interest, scientific research related to health or care sectors to ensure high levels of quality and safety of health care or medicinal products/devices with the aim of benefitting the end-users, including development and innovation activities for products and services);

• A description of the requested electronic health data, including their scope and time range, format and data sources, where possible, including geographical coverage where data is request from health data holders in several member states;

• A description whether electronic health data need to be made available in a pseudonymised or anonymized format, in case of pseudonymised format, a justification why the processing cannot be pursued using anonymized data. Further, where the applicant seeks to access the personal electronic health data in a pseudonymised format, the compliance with applicable data protection laws shall be demonstrated;

• A description of the safeguards, proportionate to the risks, planned to prevent any misuse of the electronic health data as well as to protect the rights and interests of the health data holder and of the natural persons concerned, including to prevent any re-identification of natural persons in the dataset;

• A justified indication of the period during which the electronic health data is needed for processing in a secure processing environment;

• A description of the tools and computing resources needed for a secure processing environment and, where applicable, information on the assessment of ethical aspects

Where an applicant seeks access to electronic health data from health data holders established in more than one Member State, the applicant must submit a single data access application to the HDAB of the main establishment of the applicant which shall be automatically forwarded to other relevant HDABs.

Also, there is the option to only apply for access to health data in anonymized statistical format with less formal requirements as well as a simplified procedure for trusted health data holders. The European Commission is responsible for creating templates for the data access applications.

• Requirements for the technical infrastructure

The HDAB shall only provide access to electronic health data pursuant to a data permit through a secure processing environment. The secure processing environment shall comply with the following security measures:

• Access to the data must be restricted to the natural persons listed in the data access application;

• Implementation of state-of-the-art technical and organisational measures to minimize the risk of unauthorized processing of electronic health data;

• Limitation of the input of electronic health data and the inspection, modification or deletion of electronic health data to a limited number of authorized persons;

• Ensure that access is only granted to electronic health data covered by the data access application;

• Keeping identifiable logs of access to and activities in the secure processing environment for not shorter than one year to verify and audit all processing operations;

• Monitoring compliance and security measures to mitigate potential security threats.

The HDAB shall ensure regular audits, including by third parties, of the secure processing environments and, if necessary, take corrective actions for any shortcomings or vulnerabilities identified.

• Data protection roles

From a data protection law perspective, the health data holder shall be deemed controller for the disclosure of the requested electronic health data to the HDAB pursuant to Art. 4 No. 1 GDPR. When fulfilling its tasks under the EHDS, the HDAB shall be deemed controller for the processing of personal electronic health data. However, where the HDAB provides electronic health data to a health data user pursuant to a data access application, the HDAB shall be deemed to act as processor on behalf of the health data user. The EU Commission may establish a template for controller to processor agreements in those cases.

• Fees for the access to health data for secondary use

The HDAB may charge fees for making electronic health data available for secondary use. Such fees shall cover all or part of costs related to the procedure for assessing a data access application and granting, refusing or amending a data permit, including the costs related to the consolidation, preparation, anonymization, pseudonymization and provisioning of electronic health data. The fees further include compensation for the costs incurred by the health data holder for compiling and preparing the electronic health data to be made available for secondary use. The health data holder shall provide an estimate of such costs to the HDAB.

Conclusion

The access to electronic health data for secondary use is a big opportunity especially for companies operating in the life science and healthcare sectors to get access to potentially large volumes of high-quality electronic health data for research and product development purposes. Although Chapter IV of the EHDS, which deals with the secondary use of electronic health data, will become applicable 4 years after the EHDS enters into force, companies are well-advised to begin preparation to gain access to electronic health data for secondary use at an early stage in order to gain a competitive advantage and to ensure that they are able to make direct use of the opportunities granted by the EHDS. Such preparation includes, inter alia, the early determination of the specific electronic health data required for the specific purpose the company wants to achieve as well as the set up of an infrastructure which meets the requirements under the

1. supply chain mapping;
2. verifying compliance with flow-down obligations.

For many financial institutions, the emphasis on these obligations should not come as a surprise. However, there are some nuanced clarifications in the opinion which could have an impact on general vendor management in the financial services sector. We have summarised the key takeaways below.

Supply Chain Mapping

Controllers should always be able to identify the processing supply chain. This means knowing all processors, and their subprocessors, for all third-party engagements – and not just their identity. The EDPB’s opinion clarifies that controllers should know:

• the legal entity name, address and information for a contact person for each processor/subprocessor;
• the data processed by each processor/subprocessor and why; and
• the delimitation of roles where several subprocessors are engaged by the primary processor.

This may seem excessive. However, the practical benefit of knowing this information stems beyond Article 28 compliance. It is also required to discharge transparency obligations under Articles 13 and 14 and to respond to data subject requests (e.g. of access under Article 15 or erasure under Article 19).

How is this achieved in reality? Vendor engagement can be tedious. While many financial institutions have sophisticated vendor onboarding processes, data protection is often an afterthought, addressed after commercials are finalised.

So, what should you do as a data controller? Revisit your contracts to ensure your processors are obliged to provide the above information proactively. At a frequency and in the format you require.   

Verification of Compliance

Controllers should be able to verify and document the sufficiency of safeguards implemented by processors and subprocessors to comply with data laws. In other words, controllers must be able to evidence a processor’s compliance with key obligations e.g.:

• making sure personal data is secure; and
• ensuring data is transferred or accessed internationally in line with the requirements of Chapter V.

The nature of this verification and documentation will vary depending on the risk associated with the processing activity. A low-risk vendor, from a commercial business perspective, may provide a service involving high-risk data processing. In this case, verification might involve seeking a copy of the subprocessor contract to review it. For lower-risk processing, verification could be limited to confirming a subprocessor contract is in place.

The EDPB suggests controllers can rely on information received from their processor and build on it. For example, through diligence questionnaires, publicly available information, certifications, and audit reports.

Where the primary processor is also an exporter of personal data outside the EEA, the EDPB clarified that the obligation is on the exporting processor to ensure there is an appropriate transfer mechanism in place with the importing subprocessor and to ensure a transfer impact assessment has been carried out. The controller should verify the transfer impact assessment and make amends if necessary. Otherwise, controllers can rely on the exporting processor’s transfer impact assessment if deemed adequate. The verification required here will depend on whether it is an initial or onward transfer, and what lawful basis is used for the transfer. This does not impact the controller’s obligation to carry out transfer mapping where it engages primary processors themselves located outside the EEA.

In that regard, the EDPB clarified a subtle but often debated provision of Article 28. The opinion notes that the wording “unless required to do so by law or binding order of a governmental body”, is unlikely to be compliant where data is transferred outside the EEA. It is therefore highly recommended to include the wording:

“unless required to [process] by Union or Member State law to which the processor is subject.”

Either verbatim or in very similar terms. This is particularly relevant in the context of transfer mapping and impact assessments. Regulated entities should be vigilant for third-party contracts which appear to meet the obligations set out in Article 28(3) with respect to the processing data for purposes outside of the controller’s instructions, but are, as confirmed by the EDPB, actually non-compliant.

What steps should you take now then?

The opinion clarifies that controllers can rely on a sample selection of subprocessor contracts to verify downstream compliance and we suggest you do so.

But when?

Regulated entities, particularly in the financial services industry, are facing a swathe of regulations that impact vendor engagement. The Digital Operational Resilience Act and NIS 2 Directive (EU) (2022/2555) require financial institutions to maintain a register of all contractual arrangements with vendors and ensure third-party service providers comply with cybersecurity standards. Effectively, these are enhancements to existing processor requirements under the GDPR. The reality is, however, that many controllers are only now firming up supply chain management to cover key data protection and cyber risks.

We recommend controllers use the clarifications in the EDPB’s opinion to improve negotiations when separately looking at uplifts required by DORA which takes effect on 17 January 2025. The clock is ticking.

Please reach out to your usual DLA Piper contact if you would like to discuss further, including if you are struggling to map these requirements against other emerging laws i.e. DORA or NIS2. We can provide assistance with the data and cyber contractual commitments in your contracts.

NIS2 is part of the EU’s Cybersecurity Strategy and 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 and also aims to respond to perceived weakness of NIS1 regime and the needs of increasing digital change. NIS2 establishes harmonised cybersecurity risk management measures and reporting requirements for highly critical sectors. It has a much wider scope than its predecessor – many sectors come under NIS2 for the first time.

Although some Member States such as Croatia, Hungary and Belgium have transposed the directive into national legislation, as the map below demonstrates, the majority of EU countries do not yet have the relevant implementing legislation in place, even less so the broader frameworks and guidance that would equip organisations with the necessary tools to achieve compliance. This will pose difficulties for organisations, especially those with in-scope operations in multiple EU jurisdictions, as they evaluate the scope of their exposure and work towards compliance.

Visit our EU Digital Decade topic hub for further information on NIS2 and the EU’s Cybersecurity Strategy. If you have any questions, please get in touch with your usual DLA contact.

But in the UK, we are not alone in recognising cyber as one of the most significant threats of our age. In the recitals to NIS2, the EU Commission notes that the “number, magnitude, sophistication, frequency and impact of incidents are increasing and present a major threat to the functioning of network and information systems” with the result that they “impede the pursuit of economic activities in the internal market, generate financial loss, undermine user confidence and cause major damage to the Union’s economy and society“. The EU’s response was to enact a bolstered NIS2 which significantly expands the number of entities directly in scope; includes a focus on supply chains; enhances the powers of enforcement and supervision available to local authorities; steps up incident reporting obligations; and imposes ultimate responsibility for compliance at a senior management level. With DORA, the EU adds another layer of regulation, trumping the requirements of NIS2 for the financial services sector.

So how will the UK’s new Bill compare? Our article looking at the initial indications released by Government to try and answer that question is available here.

Our article providing a summary of the key takeaways from the FAQs is available here.

For more information on how DLA Piper can support with the Data Act and other recent EU digital regulations, please refer to our EU Digital Decade website.

In order to capture the benefits of data-driven innovation, the EU and the UK are taking action to facilitate data sharing across various industries.

In the EU, the European Commission is investing €2 billion to foster the development of so-called “common European data spaces” and the associated digital infrastructure. The UK government has announced similar, mainly policy, initiatives regarding the establishment of data-sharing frameworks, referred to as smart data schemes.

Despite the shared objectives, differences emerge between the EU and UK approaches, raising questions about alignment, implementation efficiency and market dynamics.

In this article, DLA Piper:

• Explores the concepts of data spaces and data schemes, and the policy objectives behind them.
• Gives an overview of the emerging rules that will be part of the foundation of these data-sharing frameworks in the EU and the UK.
• Examines what can be expected from these initiatives and what hurdles still need to be overcome in order to secure successful implementation.

The article is available here.