The vulnerability final-report period does not run from awareness or from the 72-hour notification. It runs from when a corrective or mitigating measure becomes available, and the final report is due no later than 14 days after that event.
Teams therefore need a controlled availability record. “The patch was ready sometime Tuesday” is not a sufficient operational trigger.
Define the candidate measure
Describe what the measure does and which affected products, versions, configurations, and users it covers. Distinguish a security update, configuration change, service-side control, component replacement, feature disablement, or documented workaround.
State whether the measure corrects the vulnerability or mitigates exploitation or impact. Do not call an internal prototype available merely because a developer built it. Equally, do not ignore a usable mitigation while waiting for a preferred permanent fix.
Record limitations: prerequisites, deployment risk, incompatible versions, required privileges, affected functionality, and users for whom the measure is not effective.
Test availability as a delivery fact
Create a release checklist that identifies approval, signed artefact or controlled instructions, distribution destination, access permissions, publication state, and successful retrieval from a user-relevant path. For a partner-mediated release, capture when the partner received the approved package and what remains before users can obtain it.
Choose the availability conclusion from product facts and counsel-approved criteria. The same build may become available to different populations at different times; preserve that complexity rather than selecting the latest date without analysis.
Approve the timestamp
Give product security responsibility for technical sufficiency, release operations responsibility for distribution evidence, and legal responsibility for the reporting-trigger conclusion. Record the timestamp with timezone, evidence links, product scope, decision owner, and any dissent.
Start the final-report deadline control from the approved event. Do not silently move it when adoption is slower than expected or when a better patch follows.
Keep later measures linked
Track superseding patches, expanded version coverage, corrected instructions, and withdrawn mitigations. Explain how each relates to the original availability decision. A later improvement can change what users should do without erasing the first measure that started the reporting period.
Reconcile the user notice, advisory, 72-hour report, and final report. Product names, affected versions, measure limitations, and dates should agree or contain an explicit reason for the difference.
Exercise the ambiguous case
Use a scenario with a workaround published to enterprise administrators before an automatic patch is ready. Ask the team to identify affected users, validate the workaround, decide whether and when it became available, start the deadline, and prepare final-report evidence.
The resulting record should let an independent reviewer reconstruct the measure, its audience, distribution, approval, and exact trigger time without relying on chat messages or recollection.
Continue this workflow with the vulnerability final-report workflow and the stage-handoff packet.