Europe’s New Data Breach Reporting Rules: The Cyber Resilience Act

The Cyber Resilience Act (Regulation (EU) 2024/2847) (CRA) adds new incident reporting duties to Europe’s growing cybersecurity rulebook. We explain when these new obligations apply, how they intersect with existing regimes and what businesses caught should do now to prepare.

One Incident, Several Reporting Clocks
Businesses operating in the EU face a growing number of cybersecurity reporting requirements. These rules address different risks, from personal data breaches to service disruption and product vulnerabilities, but can apply to the same event.

The latest addition is the CRA. As explained in our earlier alert, it covers a broad range of hardware and software made available in the EU and requires manufacturers to report actively exploited vulnerabilities and severe incidents affecting product security. These reporting duties do not depend on personal data being involved. They took effect on September 11, 2026, ahead of most of the CRA’s product requirements, which apply from December 11, 2027.

A single cyber incident can, therefore, set several reporting clocks running at once. An attack on a software product might expose personal data, disrupt a regulated service and involve an actively exploited vulnerability. Businesses must assess each applicable regime and meet its deadlines, often while still investigating what happened.

For a summary of the different reporting obligations that can apply, depending on the circumstances, see our EU Reporting Rules at a Glance chart. The table sets out the principal EU deadlines. National implementation and additional sectoral rules may affect the respective scope, triggers and deadlines and notifications to affected users, customers, contractual counterparties, insurers, law enforcement or other regulators may also be required depending on the specific facts.

What Makes an Event Reportable Under the CRA?
The CRA establishes two distinct reporting triggers.

An actively exploited vulnerability requires reliable evidence that a malicious actor has exploited a vulnerability in the product without the system owner’s permission. Discovering a vulnerability through testing or responsible disclosure does not, by itself, trigger mandatory reporting.

A severe incident does not require evidence of an actively exploited vulnerability. The test includes incidents that compromise, or could compromise, the product’s ability to protect sensitive or important data or functions. It also includes incidents that have led, or could lead, to malicious code being introduced or executed in the product or a user’s systems.

Manufacturers submit notifications through ENISA’s Single Reporting Platform to the designated national Computer Security Incident Response Team (CSIRT) and ENISA. They must also inform affected users and, where appropriate, all users of the vulnerability or incident and any necessary mitigation or corrective measures. Separate, narrower reporting obligations for open-source software stewards apply from December 11, 2027.

Why One Incident Can Generate Several Reports
Suppose a software manufacturer discovers that an attacker has exploited a vulnerability in its product. The attack also exposes personal data for which the manufacturer is the controller and disrupts an essential service it operates. The manufacturer may need to assess three separate obligations: a CRA report for the exploited vulnerability, a GDPR notification for the personal data breach and, if it is an in-scope entity, a NIS2 notification for the service disruption.

Determining when each reporting clock starts can be as difficult as deciding whether the event is reportable. The regimes use different awareness, detection and classification tests, as well as different thresholds and reporting procedures. A business may need to submit an initial report before it understands the full incident, then provide updates as evidence emerges. Reports should be consistent, but coordination must not delay a required notification.

The obligations do not always accumulate. For covered financial entities, DORA’s ICT incident reporting requirements generally apply in place of the equivalent NIS2 requirements. Businesses should confirm that treatment against their activities and the applicable national legislation.

A Single Entry point, but Not Yet a Single Reporting Rule
The European Commission’s Digital Omnibus proposal (see our earlier post), would establish an ENISA-maintained single entry point for certain reports under NIS2, the GDPR and DORA, as well as other EU digital regulations. It would also raise the GDPR threshold for notifying a supervisory authority to breaches likely to result in a “high risk” to data subjects’ rights and freedoms and extend the GDPR reporting deadline from 72 to 96 hours.

The proposal would also allow a manufacturer’s CRA severe-incident report to satisfy specified NIS2 reporting requirements where the CRA report contains the required information under NIS2. This would address duplicate reporting where both obligations apply; it would not remove other applicable NIS2 duties. The ePrivacy Directive’s separate personal data breach notification provision would also be removed under the proposal.

A single entry point would simplify where organizations submit reports, but it would not turn several reporting regimes into one. The same event could still require separate assessments under the CRA, NIS2, DORA and the GDPR, each with its own trigger, deadline and, in some cases, duty to inform users. Organizations would therefore still need to identify every applicable regime at the outset of an incident and track its requirements separately.

Crucially, the Digital Omnibus changes remain under negotiation and may change before adoption. Until they take effect, organizations must follow the reporting rules currently in force.

What organizations should do now

1. Map applicable requirements. Identify the regimes that apply to each entity, product, service and jurisdiction, including the CRA reporting duties now in force.
2. Create a common escalation process. Bring security, product, privacy and legal teams into the assessment promptly.
3. Track each deadline. Record when the relevant awareness, detection or classification threshold was met, and organize the initial response around the earliest applicable deadline.
4. Prepare coordinated notifications. Develop templates for authorities, customers and users that support consistent reporting as the investigation develops.
5. Document reporting decisions. Record the facts, applicable legal thresholds and evidence supporting any decision not to notify, and revisit that decision as new information emerges.

By taking these steps, businesses can identify reporting obligations early, meet concurrent deadlines and give regulators and affected users consistent information as an investigation develops.