The final-report period for this track does not start at awareness. It does not start with the 72-hour notice either. It starts when a corrective or mitigating measure becomes available. The final report is due no later than 14 days after that event.

Teams need a controlled record of availability. “The patch was ready sometime Tuesday” is not precise enough.

Define the candidate measure

Describe what the measure does. Name the products, versions, settings, and users it covers.

State what kind of measure it is. It may be a security update or a settings change. It may be a service-side control, a new component, or a disabled feature. A written workaround can also be a measure.

Say whether it fixes the flaw. If not, explain how it limits exploitation or impact.

An internal prototype is not available just because a developer built it. But do not ignore a useful mitigation while waiting for the ideal permanent fix.

Record every important limit. Note any prerequisite and deployment risk. List incompatible versions and required privileges. Explain any loss of function. Name users for whom the measure will not work.

Test availability as a delivery fact

Use a release checklist. Record approval and the signed file or controlled instructions. Name the delivery destination and access rules. Record the publication state. Test that a user can retrieve the measure through the intended path.

A partner may deliver the release. Record when that partner received the approved package. Also record what must still happen before users can get it.

Base the availability decision on product facts. Use criteria approved by counsel.

The same build may reach different groups at different times. Keep those facts. Do not choose the latest date without analysis.

Approve the timestamp

Product security should decide whether the measure is technically sound. Release operations should own proof of delivery. Legal should approve the reporting-trigger decision.

Record the time and time zone. Link the evidence and state the product scope. Name the decision owner. Keep any dissent.

Start the final-report control from the approved event. Do not move it because users adopt the fix slowly. A better later patch does not silently reset it either.

Keep later measures linked

Track every later patch. Record wider version coverage, corrected instructions, and withdrawn mitigations. Explain how each change relates to the first availability decision.

A later improvement may change what users should do. It does not erase the first measure that started the reporting period.

Compare the user notice, advisory, 72-hour report, and final report. Product names and affected versions should agree. So should the limits and dates. Explain any difference.

Exercise the ambiguous case

Test a case where administrators get a workaround before an automatic patch. Ask the team to find the affected users and test the workaround. Then decide whether it became available and at what time. Start the deadline and prepare the final-report evidence.

An independent reviewer should be able to rebuild the decision. The record should show the measure, audience, delivery, approval, and exact trigger time. It should not depend on chat history or memory.

Continue this workflow with the vulnerability final-report workflow and the stage-handoff packet.