The severe-incident final report follows a different clock from the vulnerability final report. It is due within one month after submission of the 72-hour incident notification.
Anchor the deadline to retained submission evidence, including the exact 72-hour content, submission time, filer, destination, and result. Do not derive it later from an internal draft timestamp.
Open the final-report work at filing
When the 72-hour notification is filed, create the final-report work item from that retained event. Record the calculated limit, accountable owner, internal review dates, open evidence questions, and current mitigation owners. This avoids waiting for the investigation to feel finished before anyone owns the closing report.
Keep the external filing timestamp distinct from drafting, approval, and attempted-submission times. If completion evidence is contested, escalate it immediately because the final-period calculation depends on the filed event.
Move from initial to detailed assessment
The final report includes a detailed description of the incident, its severity and impact, the type of threat or likely root cause, and mitigation measures applied and ongoing. Build each section from identified evidence and give unresolved questions an explicit status.
The root-cause section should not overstate certainty. Separate a confirmed cause, a leading hypothesis, and an excluded hypothesis. Link each conclusion to the evidence reviewed and the person who approved it.
Rebuild the affected product scope from evidence rather than copying the 72-hour value. Mark versions confirmed, removed, added, or unresolved and explain material changes. Apply the same comparison to incident severity, impact, threat description, and mitigations.
Use a discrepancy log during review. Each row should show the earlier statement, final statement, reason for change, evidence, and approver. Clerical corrections and substantive reversals should not look identical.
Preserve continuing work
“Final report” does not mean every remedial activity must be finished. The required content includes ongoing mitigation measures. Record their owner, scope, current state, and the evidence expected at completion.
Before submission, reconcile product identifiers, awareness time, severity reasoning, and measures with the earlier reports. Explain material changes in the final account rather than leaving the reviewer to discover them by comparison.
For an ongoing measure, distinguish what has already been applied from what remains planned, then identify owner, affected scope, and expected completion evidence. Do not call the operational response complete merely because the regulatory report is ready.
Retain the candidate, approved, and filed final versions separately. The completed packet should allow a read-only reviewer to trace the one-month calculation, the development from initial to detailed assessment, and the state of every mitigation without reopening the live incident workspace.
Continue this workflow with the 72-hour incident packet and the stage-handoff record.