zero-day customer communication template

zero-day customer communication template

TL;DR

Tell customers what happened, who is affected, what you know, what you are doing, and when the next update lands. Do not speculate, do not assign blame, and do not promise timelines you cannot keep. One honest update on a schedule beats three polished ones that arrive late.

zero-day customer communication template

Use this when

• A zero-day vulnerability affects your product, service, or a dependency you ship
• Customers are asking whether they are affected and you need one consistent answer
• You are drafting the notification email or status page post
• Legal or leadership needs to approve the message and you want a solid first draft

Not for this skill when

• The communication is internal only (different audience, different template)
• Nothing is confirmed yet and you are still investigating (use a holding statement, not this)
• It is a routine patch with no zero-day character (release notes suffice)

Steps

1. Confirm the facts before writing a word

Lock down: which product and versions are affected, whether exploitation has been observed, and what the remediation is. Every sentence in the message traces back to a confirmed fact.

Expected: a fact sheet with sources. If a fact is not confirmed, it goes in the "what we do not know yet" section or stays out entirely.

2. Draft from the template

Adapt the template below. Keep it short; customers skim during incidents.

Subject: Security update: [product] [versions] - action required

What happened: A zero-day vulnerability ([CVE ID if assigned]) was
disclosed in [component]. It allows [concrete impact].

Who is affected: Customers running [product] [affected versions].
[How to check your version.]

What we know: [Confirmed facts only. Whether exploitation has been
observed, in plain words.]

What we do not know yet: [Open questions, stated plainly.]

What we are doing: [Patch status and timeline, or mitigation now
plus patch timeline.]

What you should do: [Numbered actions: upgrade to version X, apply
the workaround, rotate credentials if relevant.]

Next update: [Date and time, and where it will be posted.]

Contact: [Security contact for questions.]

Expected: a draft under one page where every claim is backed by the fact sheet. If legal needs review, this draft is what they review; do not send first and reconcile later.

3. Set the update cadence and keep it

Promise the next update time in the message, then hit it even if the update is "still working on it." Silence during a zero-day reads as hiding.

Expected: updates posted on schedule at the promised place (status page, email thread, or both). Missed cadence does more reputational damage than bad news.

4. Publish through the right channels

Status page for the broad notice, direct email for affected customers, and your security contact for follow-ups. Keep the message identical across channels.

Expected: one consistent message everywhere. Divergent versions across channels create confusion and support tickets.

5. Close the loop after remediation

Send the all-clear: what was fixed, in which version, what customers should verify, and a brief timeline of the response. Then run the internal retro.

Expected: a final message plus an internal retro document. The retro is where the process improves; the all-clear is where customer trust is restored.

Variant: holding statement while investigating

"We are aware of reports of [issue] affecting [product]. We are investigating and will update by [time] at [location]." Send this within the first hour rather than waiting for full facts.

Variant: the zero-day is in a third-party dependency

Name the dependency, state your exposure plainly, and give your own patch timeline rather than pointing customers at the upstream advisory alone. They bought your product, not the dependency.

Why this happens

Customers find out about zero-days from the news, not from you, and the gap between their discovery and your message fills with speculation. A fast, factual, scheduled communication program closes that gap and keeps you as the trusted source.

Edge cases and pitfalls

• Speculating about exploitation or impact: if it is not confirmed, label it unknown.
• Promising a patch time you cannot keep: give the next update time instead of a fix time.
• Blaming the upstream vendor or the reporter: it reads as deflection, own your response.
• Forgetting less-technical customers: include the "how to check your version" line, not everyone knows.
• No security contact listed: every message needs a place for questions, or support drowns.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Nz1TsryoFiRutY2f5TzfyA