A vulnerability in your product is public, and your customers are asking.
A researcher, a disclosure programme or a national authority has published. Your customers read the advisory before you finished writing the answer. What happens in the next two weeks decides whether this costs you a patch or a contract.
- Indicative range
- Quoted on the day — this one does not wait for a proposal
- Shape
- Days, remote, starting immediately.
What you are already seeing
- A coordinated disclosure has landed and the clock started without you.
- Support is receiving the same customer question in twelve different wordings.
- Engineering is arguing about severity while customers wait for a version number.
- Nobody is certain which customers run the affected version.
What gets examined
- 01
What is actually exploitable in your deployments, as opposed to in the abstract.
- 02
What the fix requires, and what can ship before it.
- 03
Which customers are affected, and what each of them needs to hear.
- 04
What the applicable reporting obligation requires, and by when.
What you are left holding
- 01
A customer communication that answers the question instead of deflecting it.
- 02
A remediation scope with a version and a date you can hold to.
- 03
A reporting record that satisfies the obligation without over-disclosing.
- 04
A disclosure process that works the next time, because there will be one.
Before you send anything
Plain language is enough — the system, who owns the outcome, and the date that matters. Keep confidential reports, credentials and production data out of a first message; a secure exchange route is agreed before any of it moves. Indicative ranges are exactly that: the scope, exclusions and price are confirmed in a written proposal before work starts.