For an actively exploited vulnerability, the final-report deadline is tied to the availability of a corrective or mitigating measure. Article 14 requires the report no later than 14 days after that measure is available.

The date therefore needs evidence. Record what the measure was, the affected product and version, the approval state, where it was made available, and the earliest time an intended recipient could obtain or apply it. Do not use an undocumented release date added during final-report preparation.

Make availability a reviewed event

Create a candidate event when engineering says a measure is technically complete. Ask the release owner to record approvals, distribution channel, intended recipients, affected releases, prerequisites, and the first successful availability evidence. Ask the reporting reviewer to approve or reject the candidate as the clock trigger and explain why.

Do not collapse code completion, release approval, publication, staged rollout, and customer eligibility into one timestamp. Preserve each event and identify which one the organisation relied on. If different user groups receive the measure at different times, record the cohorts and escalate the deadline analysis rather than selecting a convenient average.

Assemble the final account

The final report includes a description of the vulnerability with severity and impact, available information about a malicious actor, and details of the security update or other corrective measures made available.

Build that account from versioned evidence:

  • the confirmed affected product range;
  • the exploitation evidence and its provenance;
  • the final impact and severity assessment;
  • the correction or mitigation and its release evidence;
  • user-facing measures and distribution evidence; and
  • changes from the 72-hour notification.

Assign an owner and evidence reference to every section. The final report should show the confirmed scope and the limits of the investigation, not merely collect the most recent draft text. Where malicious-actor information remains unavailable, preserve the work performed and the unresolved status.

Close discrepancies, not history

Resolve contradictions where the evidence permits. Where it does not, state the uncertainty and the competing evidence. Preserve the 24-hour and 72-hour submissions beside the final report so a reviewer can understand how the assessment developed.

Reconcile the awareness decision, affected versions, exploitation basis, measures, user actions, and availability trigger against those earlier snapshots. Explain each material correction. A final conclusion should close an uncertainty with evidence or retain it honestly; it should not erase it.

After filing, retain the final approved packet, filed snapshot, receipt, and the evidence for the trigger date together. Continuing remediation can remain in the operational record without altering the historical submission.

The deadline wording is specific, but deciding when a measure is legally “available” can depend on the facts. Obtain legal review for ambiguous release arrangements.

Continue this workflow with the 72-hour vulnerability packet and the measure-availability timestamp.