Start with the trigger
What happened?
A few focused answers are enough to map the likely CRA reporting path. You can revise anything later.
Reporting trigger
Has exploitation been observed or credibly suspected?
This distinction matters. Article 14’s mandatory vulnerability workflow is tied to actively exploited vulnerabilities.
Reporting trigger
Does the incident have a severe impact on product security?
Use your best current assessment. CRA Report will flag uncertainty rather than pretending the answer is settled.
Closest current path
Which description is closer?
Pick the best fit now. The result will preserve the uncertainty and tell you what still needs review.
Build the timeline
How did you first learn about it?
This gives the incident pack a clear discovery trail and helps keep the chronology consistent.
Start the clock
When did your organisation become aware?
This timestamp drives the 24-hour and 72-hour countdowns. Use the exact awareness time from your incident record.
Browser timezone: . Confirm this timestamp before relying on a calculated deadline.
Check market scope
Is the affected product made available in the EU?
This is a key scope signal because CRA reporting concerns products with digital elements made available on the Union market.
Identify the product
What kind of product is affected?
Choose the closest category. This keeps the working pack concrete without forcing a premature legal classification.
Confirm your role
What is your organisation’s role for this product?
Article 14 is framed around manufacturer reporting duties. If your role differs or is unclear, the result will flag that for review.
Response status
How far has the response progressed?
Last question. This helps the incident pack focus the next reporting work on what you are most likely to be missing.