One event can create more than one regulatory question. For an organisation that is both a CRA manufacturer and an entity within NIS2 as implemented in relevant Member States, a single compromise may need separate product-side and entity-side assessments.
Do not collapse the tests merely because both processes use cybersecurity terminology or similar early reporting rhythms. Link the evidence, then let each regime reach its own conclusion.
Start with one event anchor
Give the underlying event a stable identifier, a verified occurrence timeline, and one evidence index. Preserve source logs, affected assets, product links, service effects, jurisdictions, and decision owners. The shared record prevents responders from collecting the same facts twice.
Keep interpretations in separate sections. A fact such as a compromised signing service may matter to both tracks, but its legal relevance is not identical.
Run the CRA product test
Identify the legal manufacturer and product with digital elements. Ask whether the evidence establishes an actively exploited vulnerability contained in that product or a severe incident having an impact on the product’s security. Record product versions, affected functions, awareness evidence, and the Article 14 track selected.
The product decision should not be based on the organisation’s NIS2 classification or on service disruption alone. State exactly how the event reaches the product boundary.
Run the NIS2 entity test
Identify each potentially in-scope entity, the applicable national transposition, competent authority or CSIRT, covered services, and incident-significance criteria. Assess the effect on service provision and network and information systems using the rules that govern that entity.
Do not use a CRA product conclusion as a shortcut. An event can affect a covered entity without satisfying a CRA product trigger, or reach a CRA product without crossing the NIS2 threshold for that entity.
Coordinate clocks and messages
Create a reporting matrix with regime, legal entity, threshold, awareness or classification time, recipient, deadline, approver, status, and evidence of filing. Share a technical fact base, but tailor each notification to its statutory purpose and recipient.
Before submission, reconcile names, dates, scope, and mitigation descriptions across drafts. Where wording differs, record why. A product version and an affected service are not interchangeable units of scope.
Preserve jurisdictional uncertainty
NIS2 operates through national transposition, so route contested entity, territory, and recipient questions to counsel familiar with the relevant Member State. Keep the assumption and decision date visible. Do not describe a future EU simplification proposal as though it already replaced the current filing route.
The usable output is one event dossier with two explicit decisions and a cross-check showing what was shared, what differed, and how each external obligation was completed.
Continue this workflow with the product-security boundary and the CRA and GDPR triage.