Article 14 has two reporting tracks: actively exploited vulnerabilities and severe incidents affecting product security. They share early-warning and 72-hour stages, but their final-report deadlines and required content differ.
Do not force every case into a single “CRA reportable” field. A case can require assessment under both tests, and each conclusion needs its own evidence and accountable decision.
Use a two-column triage record
For the vulnerability track, record whether the product contains the vulnerability and whether reliable evidence establishes active exploitation by a malicious actor without permission. For the incident track, apply both severe-incident tests to the product-security effects.
Give each track one of four states: assessment open, trigger met, trigger not met, or unable to conclude. Add the decision time, reviewer, evidence, and next review condition. Avoid a generic closed state that conceals which test was resolved.
Share evidence without merging decisions
Use one event anchor and evidence index, then give each track a separate decision worksheet. A product map, timeline, or technical observation may support both worksheets. Its relevance and conclusion still need to be stated independently for each trigger.
If reliable evidence shows malicious exploitation of a product vulnerability, record that result in the vulnerability column. Separately test whether the same event satisfies either severe-incident test. If the incident test is not met, preserve the negative reasoning rather than assuming the first reportable track made it unnecessary.
The reverse also applies. A qualifying severe incident does not by itself establish the reliable-evidence elements of the actively exploited vulnerability definition. Keep the vulnerability assessment open, negative, or positive according to its own evidence.
Keep the deadlines attached to the track
Once a trigger is met, create its staged obligations from the recorded awareness time. The vulnerability final report is connected to availability of a corrective or mitigating measure. The severe-incident final report is connected to the 72-hour submission.
A shared case record can hold both tracks, but the facts, decisions, deadlines, and submissions must remain distinguishable. That structure also makes later corrections easier to explain.
Design the handoff for dual outcomes
The incident manager should see two owners, two trigger states, two awareness decisions where they differ, and two sets of later-stage work. The reporter should see exactly which approved facts belong in each submission and which evidence is shared.
Before closing triage, test three failure cases: one track was never assessed; a deadline from one track was copied to the other; or a new fact changed only one conclusion but updated both. Record reopening conditions so later product or exploitation evidence reaches the correct worksheet.
The point is not duplicate investigation. It is one evidence collection process feeding two explicit legal decisions, each with a traceable clock and final-report path.
Review the complete Article 14 reporting sequence, or continue this workflow with the actively exploited vulnerability test and the severe-incident test.