A product attack can expose personal data. That does not turn the CRA and GDPR into one test.

The CRA asks a product security question. Does the maker have an Article 14 reporting trigger? GDPR asks a data question. Did a personal data breach occur, and what risk does it pose to people?

Use one fact review for the event. Make a separate legal choice for each law.

Build the shared fact layer

Start with facts that both teams can use. Record:

  • the event timeline;
  • the systems and product versions at issue;
  • the data flows;
  • the people and customers that may be affected;
  • proof of access and data loss;
  • steps taken to contain the event; and
  • who may have received the data.

Keep the source evidence. Mark facts that are not yet known.

Name each legal entity at the start. The CRA maker may not be the GDPR controller. A processor may also have to alert a controller under its contract. It may have that duty even if the controller must decide whether to alert an authority.

Run the CRA track

Link the event to a product with digital elements. Then apply the CRA test for an actively used flaw or a severe event.

Record the maker’s awareness time. Record the chosen CSIRT route and the products in scope. Assess harm to users. Set out the report stages and due times.

Personal data in the event does not prove that it is severe under the CRA. Show how it affects the product’s security controls. If harmful code is at issue, show how that part of the test applies.

Run the GDPR track

Ask if there was a breach of security. Did it cause personal data to be lost, changed, destroyed, exposed, or accessed without leave?

Name the controller, each processor, and the right data authority. List the types of data and rough counts. Record the likely harm and the steps taken.

Use the known facts to assess risk to people’s rights and freedoms. GDPR Article 33 can require notice to the authority. The controller must act without undue delay and, where it can, within 72 hours after awareness. The duty does not apply if the breach is unlikely to pose such a risk.

Make a separate choice about notice to the affected people. Apply the GDPR rules for that choice.

Reconcile without copying blindly

Use one timeline, but assess awareness under each law. Keep product names, dates, response steps, and impact facts in sync.

Explain why the scope may differ. A CRA report may cover product versions used by many customers. A GDPR record may cover people linked to a given use of their data.

Do not add personal data to a CRA report unless it is needed. Do not leave out product security facts just because the GDPR draft uses other terms. Check that each report gives its reader only what that reader needs.

Close both records explicitly

Keep a clear record for each law. It should state:

  • the result of the legal test;
  • the entity that owns the duty;
  • the person who approved the choice;
  • the due time and recipient;
  • the choice about user notice;
  • the final filed copy; and
  • the facts that would reopen the review.

Link all related records. These may include processor alerts, receipts from an authority, user notes, and product notices. No one item proves that every duty was met.

This method lets legal, privacy, and product security teams share facts. It also keeps one completed review from being mistaken for the other.

Continue this workflow with the product-security boundary and the CRA and NIS2 triage.