Coordinated Disclosure Timelines: What to Promise and What to Ship
Where the 90 day disclosure default came from, what to put in your policy, handling CVEs and extension requests, and what to do when a researcher publishes early.
Ninety days is the number everyone recites and almost nobody has thought about. It appears in program policies as if handed down, gets treated as both a promise and a threat, and then the first time a researcher actually asks to disclose, half the organization discovers the policy means nothing operationally: nobody owns the decision, legal wants to review the blog post, and engineering hasn't shipped the fix. Disclosure timelines are commitments you either build the machinery to honor or shouldn't publish.
Where the 90-day default actually came from
The number has a lineage worth knowing, because researchers know it and will cite it at you.
CERT/CC set the earliest widely-adopted norm in 2000: 45 days from report to publication, fix or no fix. It was aggressive for its era and mostly honored in the breach. The modern default arrived in 2014 when Google's Project Zero adopted a hard 90-day deadline, applied uniformly to every vendor including Google itself, with the explicit argument that indefinite non-disclosure protects vendors' schedules rather than users. They added a 14-day grace period in 2015 for vendors with a fix scheduled just past the deadline, and in 2021 moved to "90 days plus 30 for patch adoption" to give users time to update before technical details dropped. ZDI runs 120 days. CISA's own vulnerability disclosure playbook for federal agencies orbits the same range.
Three things follow from this history. The 90-day norm was designed by finders, for products with slow patch pipelines, and it stuck because it worked: Project Zero's own published data showed the share of bugs fixed inside deadline climbing into the high 90s as vendors adapted. It is a ceiling on silence, and no researcher owes it to you by default; absent an agreement, they can publish on day one. And for a SaaS program that can deploy a fix in hours, hiding behind a timeline built for operating system release cycles reads as exactly what it is.
What your policy should promise
Your disclosure clause lives in your program policy next to safe harbor and scope, and it needs to answer five questions concretely. The broader policy structure is covered in our vulnerability disclosure policy guide; the disclosure-specific parts:
- The default timeline and what starts the clock. "Coordinated disclosure 90 days after report submission, or 30 days after fix deployment, whichever is sooner" is a clean formulation. Clock-from-submission keeps you honest; clock-from-fix with no backstop lets an unfixed bug stay secret forever, and researchers read that clause the way you'd read a contract with no termination date.
- Who can publish what. Full technical writeup? Redacted advisory? Can the researcher name you? Say it now, in policy, rather than negotiating from scratch on a live report.
- The request process. On HackerOne, the built-in flow defaults to publication 30 days after a disclosure request on a resolved report unless the program acts; know your platform's mechanics before a request arrives, because the defaults run whether you're paying attention or not.
- The extension process. State that you may request extensions, that you'll give a reason and a date, and roughly what circumstances qualify.
- What disclosure never covers: other users' data that surfaced during testing, credentials, and anything from other researchers' reports.
Promise only what your slowest quarter can deliver. A policy that says "we support disclosure" above a track record of stalling every request is worse than a policy that honestly says "case by case," because researchers screenshot the gap.
Requests on fixed bugs: say yes, quickly
A researcher asking to disclose a fixed bug is asking to advertise for you. The writeup says your program pays, your team fixes, and your process works, in the one channel (researcher-to-researcher) your recruiting can't reach. Public programs with a healthy disclosed-report page get measurably better inbound, for the same reason response-time stats drive researcher targeting: it's verifiable evidence of how you behave.
The workable process is a five-business-day review with exactly three legitimate edits: live secrets or internal hostnames that leaked into screenshots, other customers' data, and details of a different, still-open vulnerability that the writeup would reveal. Impact is not on that list. Asking a researcher to soften "full account takeover" to "a session handling issue" is asking them to lie about their own work, and they will either refuse or comply once and never hunt you again.
Requests on unfixed bugs: the honest middle
This is where programs earn or torch their reputation. A researcher asking about disclosure on an unfixed bug at day 75 is usually not threatening you; they're telling you your silence has made them doubt the fix is coming. Look at your own thread first: in most of these cases the last program update was weeks ago.
The response that works is plain status plus a real date: "Fix is in the current sprint, deploys by March 6, we'll confirm and would support full disclosure 14 days after." What doesn't work is the reflex most programs have, which is restating the policy clause without any information. The researcher can read; what they lack is evidence you're doing anything.
If the fix really is far away (architectural, dependent on a vendor), say that, and offer partial disclosure as the bridge: the researcher publishes the vulnerability class and impact without the exploitation specifics, users get warned, and the full writeup follows the fix. Most researchers accept this readily when it's offered before they had to fight for it.
Partial disclosure and CVE assignment
If you ship software that other people run (on-prem, libraries, appliances, mobile apps with vulnerable client logic), CVEs stop being optional. Your customers' vulnerability scanners, their patch prioritization, and their compliance obligations all key off CVE IDs. The clean setup for a vendor with steady volume is becoming a CNA (CVE Numbering Authority), which costs staff time rather than money and lets you assign IDs on your own schedule; lower-volume vendors can request IDs through MITRE or a root CNA per advisory.
Fighting a researcher over whether a bug "deserves" a CVE is a losing move on every axis: if you refuse, researchers can request one anyway, and the public record will then show the ID arriving over your objection. Assign it, credit the researcher by name in the advisory (this costs nothing and is half of what most researchers want), and publish a vendor advisory with affected versions and fixed versions even if you keep exploitation details thin.
Pure SaaS programs mostly live outside CVE-land, since there's no customer-side patching to coordinate. The exception is anything customers integrate or self-host: SDKs, agents, CLI tools. Inventory those before a researcher forces the question.
When extensions are reasonable
Extensions are legitimate. The norm-setters all built them in, and researchers grant reasonable ones routinely. What makes an extension reasonable is specificity:
| Situation | Reasonable ask | Unreasonable ask |
|---|---|---|
| Fix requires architectural change | 30–60 extra days with milestones | "When it's fixed" |
| Multi-vendor coordination | Align on the lead vendor's date | Serial extensions as each vendor stalls |
| On-prem customers need patch window | 30 days post-patch-release | Silence until every customer upgrades |
| Fix shipped, verifying rollout | 7–14 days | Another 90 |
The pattern in the left column: a date, a reason, and an endpoint. The pattern in the right column: open-ended silence with a policy citation attached. Researchers grant the first and publish through the second. One extension asked early, with candor, almost always lands; a second extension requested at day 88 of the first one almost never does, because at that point your dates have stopped meaning anything.
When a researcher publishes anyway
It will happen eventually: a researcher blogs an unfixed or barely-fixed bug, on their timeline rather than yours. The next 48 hours are about your users, and nothing else.
Verify what's actually exposed and ship the fix or mitigation first; every hour spent drafting statements before the patch exists is misallocated. Then respond publicly with the same register you'd want applied to you: confirm, state the fix status, credit the finder's technical work even while noting the timeline wasn't coordinated. Companies that handle uncoordinated disclosure calmly take almost no lasting reputation damage from the bug itself; companies that respond with legal threats become the story, and the story gets a name like "vendor threatens researcher," which outlives any vulnerability.
Afterwards, audit your own thread before assigning blame. In our experience the large majority of "rogue" disclosures follow weeks of program silence, a blown date, or a dispute handled with boilerplate. Researchers who received honest updates and real dates almost never publish early, because they have nothing to force. Ban a researcher for extortion or fabrication; if you ban one for publishing after you went dark at day 100, every researcher who reads the disclosed thread will conclude the timeline only ever bound them, and treat your entire researcher relationship accordingly.
Keep legal out of the first response
Legal belongs in disclosure exactly twice: writing the safe-harbor and disclosure clauses in your policy, and reviewing your public advisories for regulatory exposure. Legal does not belong in the reply-to field of a researcher thread.
A first response drafted by counsel is slower by days, reads as threat regardless of content, and converts a technical negotiation into an adversarial one that the researcher will screenshot. The empirical record on cease-and-desist letters to researchers is unambiguous: the letter becomes the headline, the vulnerability details spread further than they otherwise would have (the Streisand mechanics are reliable), and your program's submission quality drops as word circulates. If a disclosure situation has escalated to the point where counsel must be involved, have them advise the security team privately while a named human on the security side keeps writing the actual messages. The researcher should never learn from tone that lawyers arrived.
Disclosure conversations go wrong at day 80 because triage went quiet at day 10: a researcher with regular, honest updates rarely reaches for a deadline. TRIAGERS™ keeps report threads moving, with same-day first response and per-report pricing, so your disclosure policy describes something that actually happens. Get in touch if your queue has gone quieter than your policy promises.