The 72-hour flaw notice adds to the early warning with facts then known. Article 14 lists its main parts. Give broad facts about the product, flaw, and attack. State fixes or ways to cut risk that are in place. Add steps users can take and mark secret facts when needed.

Give each part its own proof-backed section. This keeps product facts apart from attack facts. It also keeps a planned user step from looking like a fix already in place.

Show the state of each fact

For each part, mark the facts as:

  • seen and checked;
  • reported by a named outside party;
  • a view drawn from the proof;
  • an act done;
  • an act planned; or
  • an open point with an owner.

The words “as available” do not allow made-up detail. They mean the notice may have gaps while the review goes on.

Assign one owner per evidence section

Give product name and versions to the product owner. Give flaw and attack proof to the security lead. Give fixes to the fix owner and user steps to support or message staff. Give secret-data review to the approved reviewer.

The filing person joins these parts. They must not settle clashes with no record.

Each owner should give a result, source proof, check time, known limits, and next update. A blank field is not the same as a stated unknown. The latter shows that the team looked, what is missing, and who owns the work.

Separate four measure states

Mark each fix as planned, approved, in place, or ready for users. Each state may have a different date and scope. Link it to the product versions it covers. Do not call a partial roll out complete for all users.

For a user step, keep the approved words and planned user group. If it needs a setup or release, name that need. Do not give a broad step that users cannot take.

Reconcile with the early warning

Carry stable IDs forward and explain large changes. If the version range shrinks, keep the first range and proof for the fix. If a risk step changes, state which users got which words and when.

Before handoff to the filing person, check the pack for clashes. A short table can compare the 24-hour and 72-hour facts. Check awareness times, product names, scope, and tracks.

Explain each large mismatch. Some changes follow from new proof. Others show that teams may be describing two cases. Save the approved 72-hour pack and proof of filing. Then open a new work copy for the final report.

If a fact is still in dispute at the due time, state both views and their proof. Do not choose the view that makes the form easy. A later stage can resolve it with a clear change trail.

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