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

What GDPR Articles 33 and 34 actually require

Regulation (EU) 2016/679 Article 33(1) obliges the controller, in the case of a personal data breach, to notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it — unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Late notification must be accompanied by reasons for the delay. Article 33(2) requires a processor to notify the controller without undue delay after becoming aware. Article 33(3) sets minimum content: nature of the breach (categories and approximate numbers of data subjects and records where possible), DPO or contact point, likely consequences, and measures taken or proposed (including mitigation). Information may be provided in phases (Art 33(4)); the controller must document breaches (Art 33(5)).

Article 34(1) separately requires communication to affected data subjects without undue delay when the breach is likely to result in a high risk to rights and freedoms. That communication must describe the nature of the breach in clear and plain language and include at least the Art 33(3)(b)–(d) items. Article 34(3) lists exceptions: effective technical/organisational protection that renders the data unintelligible (for example encryption); subsequent measures that make the high risk no longer likely; or disproportionate effort, replaced by an equally effective public communication. Art 34 is not a second Art 33 clock — it is a different audience and a higher risk threshold.

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.

Article 14 stays on the product / SRP track

CRA Article 14 obliges manufacturers to notify actively exploited vulnerabilities and severe incidents having an impact on the security of the product — early warning within 24 hours of becoming aware, fuller notification within 72 hours, then the final report on its own trigger (14 days after a corrective or mitigating measure is available for an AEV under Art 14(2)(c), or within one month of the 72-hour notification for a severe incident under Art 14(4)(c)) — through ENISA's Single Reporting Platform to the coordinating CSIRT. That duty has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)). Measure-available timing for the AEV final: corrective or mitigating measure. CSIRT routing: which CSIRT applies.

The clocks are not the same “72 hours”

Article 14 runs a three-step cascade from awareness (24h / 72h / final on a separate trigger). 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, and an exception when the breach is unlikely to risk rights and freedoms. 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 — subject to the Art 34(3) exceptions. 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.

The trap: “we already filed the 72-hour GDPR notice”

Two failure modes show up in triage. First: a manufacturer whose product incident also looks like a personal data breach files Article 33 to the DPA and skips the SRP because “privacy already has the 72-hour clock.” Second: counsel or a customer files GDPR while the manufacturer assumes that filing — or the customer's controller status — removes the product-side Article 14 duty. Product SRP reporting and personal-data breach reporting are different jobs for different actors.

Neighbouring traps: NIS2 Article 23 (same 24h/72h/final shape as CRA, still a separate entity filing); DORA Article 19 (financial ICT major-incident track); AI Act Article 73 market-surveillance serious-incident filings; civil Product Liability Directive compensation claims (FAQ 2.3.1 — not an SRP substitute); and Data Act data-access dual scope (FAQ 2.9 — still nests Art 14). 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 a GDPR Article 33 supervisory-authority notification satisfy CRA Article 14?

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.

Are the clocks the same — both say 72 hours?

They share a number, not a calendar. GDPR Article 33(1): without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach (unless the breach is unlikely to result in a risk to natural persons’ rights and freedoms) — one authority-notification deadline, with reasons if you miss 72 hours; no CRA-style 24-hour early warning and no scheduled final-report stage. CRA Article 14: 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 (Art 14(2)(c)), or within one month of the 72-hour notification for a severe incident (Art 14(4)(c)). Matching “72 hours” does not merge the clocks.

What actually triggers each one?

CRA Article 14 is product-centric: an actively exploited vulnerability contained in the product with digital elements, or a severe incident having an impact on that product’s security. GDPR Article 33 is processing-centric: a personal data breach (Art 4(12) — a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed) that is not unlikely 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?

CRA Article 14 goes to your coordinating CSIRT and ENISA via the Single Reporting Platform. GDPR Article 33(1) goes to the supervisory authority competent under Article 55. Article 33(2) separately requires a processor to notify the controller without undue delay after becoming aware — that is not an SRP filing and not a DPA filing. 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.

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(1) 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 (with Art 34(3) exceptions such as effective encryption, subsequent measures that remove the high risk, or disproportionate effort replaced by equally effective public communication). 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). If you are a processor, Article 33(2) still requires you to notify that controller without undue delay. 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.