Regulating Data: EU Data Act & More - March 2026 Edition

Welcome to the seventh edition of Regulating Data: EU Data Act & More.

Europe’s digital and cybersecurity rulebook continues to evolve at pace. The coming years will be shaped by how organisations operationalise new frameworks such as the Cyber Resilience Act, the Data Act and NIS 2 in practice, particularly in relation to cloud based services and software driven products. This edition of our newsletter highlights three recent developments that are particularly relevant for organisations planning or refining their data and cybersecurity compliance programmes:

• Digital Omnibus – ECB perspective on Data Act changes: the ECB’s main comments on the proposed “Digital Omnibus” Regulation are summarised, with a focus on the planned amendments to the Data Act, including simplification of G2B/B2G data sharing, legal consolidation and safeguards around official statistics.
• Cyber Resilience Act – Commission draft guidance: key elements of the EU Commission’s draft CRA guidance are set out, including how it sharpens core concepts such as scope, clarifies the treatment of free and open-source software, and explains when changes qualify as “substantial modifications” and how support periods should be determined.
• Germany’s NIS 2 regime – first indications after the registration deadline: an update is provided on the initial registration figures, expected further guidance by the BSI and emerging signals on enforcement practice following the 6 March 2026 deadline.

For further context, including previous analyses of the Digital Omnibus Proposal and Germany’s NIS 2 Implementation Act, please refer to earlier editions of our newsletter.

1. ECB comments on Digital Omnibus: Data Act changes in the spotlight

In its opinion from 10 March 2026 on the EU Commission’s “Digital Omnibus” proposal (we reported in detail in our November edition), the European Central Bank (“ECB”) focuses in part on the planned amendments to the EU Data Act. Against this background, the ECB highlights several key points in relation to the Data Act:

• The ECB welcomes the intention to simplify G2B and B2G data‑sharing arrangements and the rules on processing personal data under the Data Act. It notes that this is particularly relevant given its extensive role in collecting, developing, producing and disseminating data for the performance of its tasks. At the same time, the ECB expresses concern that, in specific cases, the proposal may not fully deliver on the simplification objective because it does not actually ease regulatory compliance burdens for businesses and public authorities.
• Furthermore, the ECB welcomes the European Commission’s plan to evaluate the main chapters of the Data Act by September 2028 and the new chapters within five years of the Digital Omnibus entering into force. The bank also stresses the importance of keeping the existing review clause in Article 58 DORA – which requires the Commission to carry out a review and to submit a report on the functioning of many aspects of DORA – ensuring an assessment of how that framework functions.
• The ECB explicitly supports consolidating the rules on re‑use of protected data (currently in the Data Governance Act) with the rules on re‑use of public‑sector documents (in the Open Data Directive) within the Data Act, combined with repealing outdated rules such as the Free Flow of Non‑Personal Data Regulation. In its view, this creates a more coherent structure and more consistent definitions of key terms.

Overall, the ECB’s opinion signals broad support for the Data Act’s consolidation and simplification agenda, while calling for careful technical fine tuning to ensure that the new framework genuinely reduces compliance burdens.

2. Cyber Resilience Act: Commission Consults on Draft Guidance to Support CRA Implementation

On 3 March 2026, the European Commission published for feedback draft guidance to assist companies in applying the Cyber Resilience Act (“CRA”), which mainly lays down cybersecurity requirements for products with digital elements. The CRA (Regulation (EU) 2024/2847) aims to strengthen the EU’s approach to cybersecurity, address cyber resilience at EU level and improve the functioning of the internal market. The newly published guidance is intended to support economic operators and authorities in applying and to promote a consistent, risk‑based implementation of the CRA across the EU.

2.1 Key issues highlighted by the draft guidance

The draft guidance explains how the CRA should apply in practice across very different product types and business models. It focuses on several terms and provisions of the CRA that leave room for interpretation.

• (A) Remote data processing solutions (RDPS)
  Article 3(1) of the CRA defines a “product with digital elements” as
  “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately”.
  It is therefore crucial to determine whether a product has RDPS as set out in the CRA and how to meet the corresponding compliance obligations.
  • Definition: Article 3(2) of the CRA defines “remote data processing” as
    “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”.
    The draft guidance clarifies that RDPS are software elements of data processing at a distance, not the hardware that remote data processing may rely upon.
    According to the EU Commission, the assessment for data processing “at a distance” needs to be done case-by-case. However, cloud computing, including edge computing, is a typical example of data processing taking place “at a distance”.
  • How to assess compliance: The CRA requires a risk-based approach to compliance.
    According to the draft guidance, this practically means documenting in the technical file where RDPS and third party cloud solutions are used and delineating which parts of the overall system fall within the CRA conformity assessment scope and assessing risks related to RDPS, to reliance on third party cloud solutions and to the product environment, and implementing security controls on the product to mitigate them.
    As part of conformity assessment and due diligence, manufacturers may re use existing evidence such as CE marked components, NIS 2/DORA compliance, EU cybersecurity certifications and ISO/IEC 27017:2015 or ISO/IEC 27001:2022 conformity.
    Finally, manufacturers must implement appropriate security measures. Mitigation should focus on implementing security controls at product level and verifying third party providers’ security measures through due diligence, including by embedding clear security guarantees in service level agreements with those providers.
• (B) Other issues covered by the draft guidance
  • Scope: The draft guidance sharpens key concepts determining when the CRA applies. It clarifies when products with digital elements are placed on the market. For example, digitally provided standalone software, which should be considered “placed on the market” once its manufacturing phase is complete and that software is first supplied for distribution or use on the EU market in the course of a commercial activity. The draft further distinguishes products with “data connections”, which fall under the CRA due to their inherent cybersecurity risk from products that merely use electrical signals. Furthermore, the draft suggests that products designed before the CRA applies remain within scope, but compliance is assessed on a risk based basis and does not automatically require redesign.
  • Free and open source software (FOSS): The draft guidance also clarifies when FOSS will be regarded as being “placed on the market” for CRA purposes. In essence, openly published FOSS that is not monetised by its publisher remains outside the CRA’s scope, whereas FOSS is considered placed on the market where the publisher supplies it in the course of a commercial activity. The guidance further distinguishes between manufacturers, open source stewards and mere contributors.
  • Substantial modifications: The Commission explains when changes to a product will qualify as “substantial modifications” under the CRA. The notion of substantial modification is central because a person who modifies a product may be treated as its manufacturer (see Articles 21, 22 and 69(2) CRA). In broad terms, a change is substantial where it affects compliance with the essential cybersecurity requirements under the CRA or alters the intended purpose for which the product was originally assessed; routine repairs and identical spare parts will generally not be substantial, while certain software updates can be. The details hereto are laid out in pages 26-34 of the draft.
  • Support period: The guidance makes clear that the five year support period in Article 13(8) CRA operates only as a safeguard, ensuring that vulnerabilities are handled for a sufficiently long period, while allowing manufacturers to take into account products with genuinely shorter expected use times. Consequently, products reasonably expected to remain in use for longer than five years are to be given correspondingly longer support periods.
  • Further clarifications: The draft guidance also provides clarification on a range of other CRA concepts and requirements, including the classification of “important” and critical products” and the conduct of cybersecurity risk assessments and integration of components.

2.2 Next steps

The draft guidance is open for stakeholder feedback until 31 March 2026. Once adopted, it is expected to steer national authorities’ enforcement approaches and serve as the de facto benchmark for CRA compliance. In the meantime, companies should use the draft as a practical roadmap: mapping which products with digital elements fall in scope and when they are placed on the market, reassessing how they publish and integrate FOSS and what role they play in each project, aligning repair, update and release practices with the CRA concepts of substantial modification and product specific support periods, and embedding CRA style cybersecurity risk assessments, component due diligence and remote data processing solutions into their existing product governance frameworks.

3. NIS 2 registration in Germany: first indications after the 6 March deadline

Germany’s implementation of the EU NIS 2 Directive mainly via the amended BSI Act (“BSIG”) has substantially tightened the national cybersecurity regime for around 29,500 entities, including cloud computing service providers, as highlighted in our December 2025 edition. This update focuses on what is known so far about the situation after the registration deadline of 6 March 2026 (as reported in our February 2026 edition).

3.1 First numbers: around 11,500 entities registered

According to several German media reports, around 11,500 entities had completed their NIS 2 / BSIG registration with the Federal Office for Information Security (“BSI”) by the end of the deadline. This marks roughly 39% of the 29,500 entities that according to the BSI likely fall within the scope of the German NIS 2 / BSIG regime.

3.2 Further guidance expected on group registrations and critical components

The media reports also indicate that the BSI plans to publish additional guidance, in particular on group registrations and the registration of critical components. This additional guidance is expected to provide further practical orientation for organisations as they refine their NIS 2 compliance programmes.

3.3 Enforcement: press reports of no immediate fines, but on very thin footing

The more sensitive question is how the BSI will react to entities that missed the registration deadline.

• While the available information is fragile, one article reports that the BSI is, for the time being, refraining from imposing fines for missed registrations and is instead relying on companies’ willingness to comply. According to that article, the immediate focus is said to be on bringing entities into the system rather than on sanctions.
• Legally, the statutory registration obligation and the BSI’s sanctioning powers remain fully in force.
• Companies should not assume an amnesty or a safe period, even if the BSI is, in practice, taking a pragmatic approach in the short term, late or missing registrations can still be fined where the legal conditions are met.

3.4 What companies should do now

Against that background, organisations should:

• Unregistered but in scope: treat the registration as a priority and do not hesitate to ask us for advice.
• Uncertain scope: contact us to carry out and document a structured scope assessment; a well‑reasoned analysis will be important if your status is questioned at a later stage.
• Already registered: verify that your registration data is accurate and ensure that your internal governance and security measures are being aligned with the NIS 2 requirements.

Taken together, these early signals underline that registration under the BSIG is only the starting point: NIS 2 will remain a live supervisory topic, and entities in scope should treat both registration and the progressive build out of their cybersecurity governance as a continuing priority rather than a one off exercise.