The 72-hour vulnerability notification develops the early warning with the information then available. Article 14 names general information about the product, the general nature of the exploit and vulnerability, corrective or mitigating measures taken, measures users can take, and the manufacturer’s view of information sensitivity where applicable.

Organise those elements as separate evidence-backed sections. That prevents a product description from being mistaken for an exploit description and keeps a proposed user action from being recorded as a measure already deployed.

Show the state of each fact

For every section, distinguish:

  • observed and verified information;
  • information reported by a named third party;
  • an assessment or inference;
  • an action completed;
  • an action proposed; and
  • an unresolved question with an owner.

The words “as available” do not license invented detail. They recognise that the notification may remain incomplete while the investigation continues.

Assign one owner per evidence section

Give product identity and affected versions to the product owner; exploitation and vulnerability evidence to the security investigator; corrective or mitigating measures to the remediation owner; user measures to the communications or support owner; and sensitivity to the authorised disclosure reviewer. The reporter integrates those contributions but should not silently resolve their conflicts.

Ask each owner to provide a conclusion, its source records, checked time, known limits, and next expected update. A blank section and an explicit unknown are different states. The latter explains that the team looked, what remains unavailable, and who continues the work.

Separate four measure states

Record whether a measure is proposed, approved, deployed, or available to users. Those states may have different dates and scopes. Link each state to the product versions it covers and avoid describing a partial rollout as universal.

For user action, preserve the approved instruction and the audience expected to use it. If the action depends on a configuration or release, name that dependency rather than offering a generic direction that cannot be executed.

Reconcile with the early warning

Carry forward stable identifiers and explain material changes. If the affected version range narrowed, preserve both the earlier range and the evidence that justified the correction. If a mitigation changed, identify which users received which instruction and when.

Before handoff to the authorised filer, review the packet for internal contradictions. A compact table comparing the 24-hour entry with the 72-hour entry can surface mismatched awareness times, product names, scope, and reporting tracks.

Require an explanation for every material mismatch. Some differences are legitimate results of a developing investigation; others indicate that two teams are describing different cases. Freeze the approved 72-hour packet and its filed evidence, then open a new working version for final-report development.

Where a fact remains disputed at the deadline, state the competing positions and the evidence available rather than selecting the version that makes the form easiest to complete. The later stage can resolve it with a traceable change.

Continue this workflow with the early-warning packet and the vulnerability final-report trigger.