The 72-hour incident notification is an initial assessment, not the final incident history. Article 14 calls for available general information about the incident, an initial assessment, and corrective or mitigating measures taken.
The case record should therefore expose uncertainty without becoming vague. State what happened, what product security property was affected or could be affected, what evidence supports severity, and which measures were actually applied.
Keep three timelines
Maintain separate times for detection, occurrence where known, and awareness of the Article 14 trigger. They answer different questions. If the occurrence time remains a range, preserve the range and the method used to derive it.
The same separation applies to measures. A containment action, a user workaround, and a permanent correction are different states. Record the scope and completion evidence for each.
Describe the incident through the product
Begin with the affected product and versions, then describe the event and the security property or malicious-code path used in the severe-incident analysis. Keep corporate-system effects, customer-service effects, and product-security effects in distinct sections. Join them only where evidence establishes the relationship.
Give every scope statement an evidence reference. If the team has confirmed one product version and is still testing adjacent versions, say so. Do not broaden the filed scope to every product for caution or narrow it to the first confirmed build for convenience.
Build the initial assessment as an argument
List the applicable severe-incident test, supporting evidence, counter-evidence, uncertainty, and reviewer. Then describe the current severity and impact assessment without turning a hypothesis into an observed fact. The report can remain initial while still being specific about the basis for its current conclusion.
Measures should be connected to that assessment. For each action, record the risk or path it addresses, affected release, implementation state, owner, and verification evidence. Keep an action planned for later separate from one already taken.
Make the initial assessment reviewable
An initial assessment should connect evidence to the relevant severe-incident test. List counter-evidence and unresolved alternatives rather than hiding them in a general narrative. Assign each open question to an owner and decide whether it can affect the reporting content before the submission deadline.
Retain the submitted 72-hour version. The final report should extend and correct that version with an explicit change history, not replace it without trace.
Before filing, compare manufacturer name, product identity, reporting track, awareness time, occurrence range, scope, and measure state with the early warning. Resolve clerical mismatches. Explain investigative changes. Escalate legal disagreements rather than editing them away.
The handoff to final-report work should name the unresolved root-cause questions, evidence collection owners, continuing mitigations, and the retained 72-hour submission time that anchors the next stage.
Continue this workflow with the early-warning packet and the incident final-report workflow.