A compromised product can expose personal data, but the CRA and GDPR do not merge into one test. The CRA asks whether a manufacturer has an Article 14 product-security trigger. GDPR asks whether a controller or processor has a personal data breach and what risk it creates for natural persons.
The efficient approach is one factual investigation with distinct legal decisions, recipients, and evidence.
Build the shared fact layer
Record the event timeline, systems, product versions, data flows, affected people or customer populations, access evidence, containment, and known recipients of compromised data. Preserve the original evidence and mark uncertainty.
Identify legal entities early. The CRA manufacturer may not be the GDPR controller, and a processor may have contractual notice duties to a controller even when it does not own the authority notification decision.
Run the CRA track
Connect the event to a product with digital elements and apply the actively exploited vulnerability or severe-incident test. Record the manufacturer’s awareness time, coordinating-CSIRT route, product scope, user-impact analysis, and selected reporting sequence.
Do not treat the presence of personal data as proof of CRA severity. Show how the product’s security protections or malicious-code branch is affected.
Run the GDPR track
Determine whether there was a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Identify the controller, processors, supervisory authority, categories and approximate numbers involved, likely consequences, and measures taken.
Assess risk to rights and freedoms using the available facts. GDPR Article 33’s authority notification generally runs without undue delay and, where feasible, within 72 hours after controller awareness unless the low-risk exception applies. Assess any data-subject communication separately under the applicable GDPR rules.
Reconcile without copying blindly
Use one chronology but keep separate awareness analyses. Align product names, incident dates, containment actions, and statements about known impact. Explain differences in scope: a CRA report may cover product versions across several customers, while a GDPR record may cover data subjects tied to particular processing operations.
Do not place unnecessary personal data into a CRA report or omit product-security detail from it merely because the GDPR draft uses different language. Apply data minimisation and recipient-specific review.
Close both records explicitly
For each regime, retain the threshold decision, responsible entity, approver, deadline, recipient, communication decision, filed version, and reopen condition. Link processor notices, authority acknowledgements, user messages, and product advisories without treating any one item as proof that all duties were met.
This structure lets legal, privacy, and product-security teams collaborate on evidence while making it impossible to mistake one completed assessment for the other.
Continue this workflow with the product-security boundary and the CRA and NIS2 triage.