CRA Article 14 vs GDPR breach notification: do you file twice?

What FAQ 2.8.1 actually says

Commission CRA implementation FAQ entry 2.8.1 asks about the interplay between the CRA and the General Data Protection Regulation. The answer: the two instruments are of a different nature and there is no legal overlap. The CRA sets obligations for economic operators making products with digital elements available on the market; the GDPR sets rules for natural and legal persons acting as controllers or processors of personal data.

The same FAQ notes they can complement each other — CRA Annex I cybersecurity requirements (confidentiality and integrity of data, secure-by-default, vulnerability handling) can support personal-data protection, and GDPR principles (including Articles 5, 25, 32 and the personal-data-breach notification in Article 33) can support product cybersecurity — but manufacturer CRA compliance has no formal impact on the tools controllers or processors use to demonstrate GDPR compliance (codes of conduct, certification schemes, and the like). Complementary is not substitutable.

Two triggers, two front doors

CRA Article 14 is product-centric: notify an actively exploited vulnerability contained in the product, or a severe incident having an impact on the security of the product, simultaneously to the coordinating CSIRT and ENISA through the Single Reporting Platform. GDPR Article 33 is processing-centric: the controller notifies the competent supervisory authority of a personal data breach without undue delay and, where feasible, not later than 72 hours after becoming aware. Submitting through the SRP does not put your report in front of a data-protection authority, and a DPA notification does not appear in ENISA's CRA workflow. CSIRT routing for the CRA side: which CSIRT applies.

The clocks are not the same “72 hours”

Article 14 runs early warning within 24 hours of becoming aware, a fuller notification within 72 hours, then a final report timed from a corrective or mitigating measure (AEV) or from the 72-hour notification (severe incident). GDPR Article 33 has a single authority-notification deadline — without undue delay and, where feasible, within 72 hours — with reasons required if you miss that window. There is no CRA-style 24-hour early warning and no CRA-style scheduled final report under Article 33. Sharing an internal awareness timestamp helps both processes; sharing one external filing does not. Clock overview: Article 14 reporting deadlines; awareness timing: when the 24-hour clock starts.

Article 14(8) users vs GDPR Article 34 data subjects

After awareness of an AEV or severe incident, Article 14(8) requires the manufacturer to inform impacted users — and where appropriate all users — about the vulnerability or incident and, where necessary, mitigation they can deploy (see informing users under Article 14(8)). GDPR Article 34 separately requires the controller to communicate a personal data breach to affected data subjects without undue delay when the breach is likely to result in a high risk to their rights and freedoms. Same customer list can appear in both audiences; the legal tests, wording, and who must send the message still differ. Do not treat a security advisory as automatic Article 34 compliance, or a privacy notice as automatic Article 14(8) compliance, without counsel.

If CRA, GDPR and NIS2 all look relevant

Run each regime's own trigger test and file to each regime's own recipient. CRA vs NIS2 is already covered separately — CRA Article 14 vs NIS2 — because those two share a 24h/72h/final shape that teams confuse. GDPR does not share that shape; the trap is assuming the CRA or NIS2 filing “covers privacy” because personal data was involved. For connected health hardware, also check whether the product is outside the CRA under the MDR/IVDR exclusion before you open an SRP case — Article 14 for medical devices. Keep one internal timeline of what you knew and when (the evidence log), then fork the external notifications.

Questions people ask

Does an Article 14 SRP filing satisfy GDPR Article 33?

No. Commission FAQ 2.8.1 says the CRA and the GDPR are of a different nature and there is no legal overlap: CRA binds economic operators for products with digital elements; GDPR binds controllers and processors for personal-data processing. Nothing in Article 14 treats a personal-data-breach notification as meeting a CRA duty, and FAQ 2.8.1 adds that CRA product compliance has no formal impact on the tools controllers use to demonstrate GDPR compliance. File each regime to its own recipient unless counsel confirms otherwise for your case.

When can the same event trigger both?

When the facts meet both tests. CRA Article 14 needs an actively exploited vulnerability in your product with digital elements, or a severe incident with impact on that product’s security. GDPR Article 33 needs a personal data breach — a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data — that is likely to result in a risk to natural persons’ rights and freedoms. A compromised device that also exposes customer personal data can trip both; a product-security event with no personal data may be CRA-only; a controller-side database leak with no product-security impact may be GDPR-only.

Who receives each report, and what are the clocks?

CRA Article 14 goes to your coordinating CSIRT and ENISA via the Single Reporting Platform: early warning within 24 hours of becoming aware, fuller notification within 72 hours, then a final report (14 days after a corrective or mitigating measure is available for an AEV, or one month after the 72-hour notification for a severe incident). GDPR Article 33 goes to the competent supervisory authority: without undue delay and, where feasible, not later than 72 hours after becoming aware — there is no CRA-style 24-hour early warning or scheduled final-report stage. Matching “72 hours” is not the same clock.

Is CRA Article 14(8) user notice the same as GDPR Article 34?

No. Article 14(8) is a manufacturer duty to inform impacted users (and where appropriate all users) about the vulnerability or incident and, where necessary, mitigation they can deploy — including, where appropriate, in a structured machine-readable format. GDPR Article 34 is a controller duty to communicate a personal data breach to affected data subjects without undue delay when the breach is likely to result in a high risk to their rights and freedoms. Different actor roles, different risk tests, different audiences. One notice rarely drafts the other without counsel review.

We manufacture the product but a customer is the GDPR controller — who files what?

You still own CRA Article 14 as manufacturer when the product-side trigger is met. GDPR Article 33 sits with whoever is the controller for the processing that was breached — often the customer for their end-user data, and you for processing you control (support logs, accounts, telemetry you determine the purposes of). FAQ 2.8.1’s “no legal overlap” point means your CRA filing does not absolve a controller’s Article 33 duty, and a controller’s DPA notification does not close your SRP chain. Map roles before the incident, not during the 24-hour window.

Does this interact with NIS2 as well?

Possibly — three separate regimes. CRA is product reporting; GDPR is personal-data breach reporting; NIS2 Article 23 is entity-level significant-incident reporting for in-scope sectors. None of those filings substitutes for the others by default. See our CRA vs NIS2 guide for the product/entity split, then run GDPR on its own controller test.