Your Disclosure Clock: A 90 Day Calendar for Fixing a Reported Flaw

Google Project Zero's policy, read on 18 October 2026, says a vendor has 90 days after notification to make a patch available. If the patch ships within 90 days, details are published 30 days after the patch is available. If not, details are published at the end of the 90 days. This is the 90+30 model, and many researchers and projects use something close to it.

Since 29 July 2025 there is a second step. Project Zero's Reporting Transparency trial says that within about a week of reporting, it will publicly share the vendor or project, the affected product, the report date and the date the 90 day deadline expires. Plan for your clock to be visible from day 7.

What's affected

Any vendor or maintainer that might receive a report from a researcher who follows Project Zero style timelines. Other numbers you will see:

• Project Zero's grace period: vendors that cannot patch within 90 days but will patch within 104 days can ask for one, and Project Zero "may grant" it, with publication then at day 120.
• CISA BOD 20-01 footnotes recommend acknowledging within 3 business days and resolving within 90 days, and say these are not mandatory dates.
• Django promises an acknowledgment within 3 working days, aims to resolve every report within 90 days, and notifies downstream distributors about a week before disclosure, shortened if there is an exploit in the wild.

How to check if you're exposed

Look at your last report and write down: the date it arrived, the date you replied, the date you confirmed it, the date the fix shipped. If you cannot fill in all four from your tracker, you cannot defend a deadline.

import csv, datetime as dt
# reports.csv columns: id,received,acked,fixed  (dates as YYYY-MM-DD)
for r in csv.DictReader(open("reports.csv")):
    d = lambda k: dt.date.fromisoformat(r[k])
    print(r["id"], (d("acked") - d("received")).days, "days to ack,",
          (d("fixed") - d("received")).days, "days to fix")

The point is to measure, whatever tracker you use.

What to do now

1. Put the clock in your policy. A table like this is realistic for a small team. It is a suggestion built on the numbers above, not a rule.

2. Treat day 7 as public. If the researcher follows the Project Zero model, expect your name and the deadline to appear. Have a one line holding statement ready.
3. Ask for an extension early. Do it by day 30, with a reason and a date you will keep, not on day 89.
4. Ship the fix before the advisory. After release, publish within a day, since the researcher's own clock keeps running.
5. If you cannot meet 90 days, say so in writing and offer a mitigation to customers meanwhile.
6. Record the outcome, then change the process for the next report.

How to avoid this trap

1. Do not start the clock at triage. It starts when the report reaches you, so assign an owner on day 0.
2. Do not let one person hold both the code fix and the communication. Split them.
3. Do not wait for the perfect patch if a mitigation exists. Publish the workaround first.
4. Keep a short list of downstream parties you will notify, so you are not building it on day 75.

Why it matters

A published deadline is a forcing function. Project Zero's stated goal for the transparency trial is to shrink the "upstream patch gap," the delay between an upstream fix and downstream users getting it. That gap is where customers get hurt, and it is also the part a small vendor can control by telling people sooner.

A calendar you can show a customer is also evidence of a working process. It turns "we take security seriously" into dates.

Try it yourself

Take your last three reports and place them on the calendar above. Mark where each one slipped, then walk through a postmortem on one of them.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Google Project Zero: Vulnerability Disclosure Policy
• Google Project Zero: Reporting Transparency (29 July 2025)
• CISA BOD 20-01
• Django security policy