CRA reporting is staged, but the case should remain auditable as the investigation changes. A handoff packet lets the next reporter see which evidence was available, which statement was approved, and what was actually filed at each stage. It does not depend on any platform automatically copying fields forward.
Anchor the packet in the governing sequence
Both Article 14 tracks begin with an early warning without undue delay and, in any event, within 24 hours of awareness, followed by a fuller notification without undue delay and, in any event, within 72 hours. The final trigger differs by track.
For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure is available. For a severe incident affecting product security, it is due no later than one month after the 72-hour notification is submitted.
Record the selected track, awareness basis, clock calculation, and decision owner at the top of the packet. If the track remains disputed, preserve both analyses and the escalation owner rather than hiding the uncertainty in free text.
Freeze the early-warning basis
Keep the manufacturer identity, product identity, event summary, Member State analysis, sensitivity decision, known mitigation, unknowns, source evidence, and approved wording together. Mark each substantive value as observed, inferred, or unresolved.
After filing, attach the submission evidence and lock that snapshot. Continue the technical investigation in a separate working record. A later discovery should create a traceable correction or expansion, not rewrite what the organisation knew at the earlier deadline.
Review changes at the 72-hour handoff
Display the current value beside the earlier approved value. Use a small set of dispositions such as confirmed, corrected, expanded, or unresolved. Require a source and owner for each material change.
For the vulnerability track, assemble the available product, exploitation, vulnerability, and measure information. For the severe-incident track, assemble the available incident nature, initial assessment, product-security impact, and measures. Do not force certainty where the investigation does not support it. State what remains unknown and when it will be revisited.
Make the final trigger visible
The vulnerability packet needs evidence for when a corrective or mitigating measure became available, because that event starts the 14-day final period. The severe-incident packet needs the filed time of the 72-hour notification, because the one-month final period runs from that submission.
The final review should reconcile root-cause findings, affected product scope, corrective action, earlier statements, and any user measure. List resolved uncertainties and any material point that remains open.
Preserve candidate, approved, and filed states
Keep three distinct states for every stage. The candidate packet shows the investigation at handoff. The approved packet shows the statement the organisation authorised. The filed snapshot and receipt show what entered the external reporting process.
Use one internal case anchor across all states. If an authority requests a correction, retain it as a new authorised event linked to the filed snapshot. The resulting record should show, without reconstructing chat or email, what changed, why it changed, who approved it, and which evidence proves each handoff.
Continue this workflow with the 72-hour vulnerability workflow and the 72-hour incident workflow.