How to write a first incident update before every fact is known
Share
Published
A first incident update should tell its audience what is confirmed, what is being checked and what happens next. It should not fill gaps with a confident explanation merely because people want an immediate answer.
This is a template for a controlled status message. It is not a universal regulator notification, customer breach notice or statement of legal compliance. Determine the audience, purpose and applicable requirements before using it.
Start with the evidence log
Ask the incident lead to identify the facts that can be supported now. Use the incident evidence log to keep those facts separate from a staff report or an initial interpretation.
Agree who approves the message and who may release it. A draft prepared for an internal response team should not be copied into a public post without another review.
A first-update structure
Incident reference: [reference]. Update issued: [date, time and time zone].
We are investigating [brief description supported by current evidence]. We became aware of it at [confirmed time or clearly described estimate].
What we have confirmed: [specific facts].
What we are checking: [material questions still open].
Actions underway: [approved actions and responsible team].
What this audience should do now: [clear, appropriate instruction, or state that no action is currently requested].
Our next update is planned for [time or defined trigger]. The responsible contact is [approved route].
The bracketed fields are prompts, not text to publish unchanged. Remove anything that does not apply. Keep supporting records behind the message rather than attaching sensitive incident material unnecessarily.
Describe uncertainty clearly
“We are checking whether the attachment included additional records” identifies a question. “No information was affected” is a conclusion that needs evidence. Avoid making that conclusion simply because a review has not yet found an impact.
Use a time boundary where it matters: “As of this update, the team has confirmed…” That helps the audience understand that the assessment may change.
Make the next step useful
If staff need to preserve a message, report a related event or use an alternative process, explain the approved route. Do not direct them to send passwords or customer files into an uncontrolled inbox.
If the audience does not need to take an action, say so in the appropriate context. Avoid adding speculative instructions that could create confusion, disrupt evidence or lead people towards unofficial support services.
Check the contact route
Verify the reply address or support page before release. A genuine incident message can be imitated later, so use the organisation’s established communication channels and explain how readers can verify a subsequent message.
For an external notice, have the appropriate legal, technical and communications owners review the content and timing. Different obligations may apply to different recipients and jurisdictions.
Keep a version record
Record the approved wording, issue time, audience, approver and delivery method. If a material fact changes, prepare a corrected update that explains the change. Do not silently rewrite a public statement in a way that leaves recipients with conflicting information.
NIST’s incident-response guidance treats response as part of wider risk management. This original message structure supports the practical communication stage; it does not certify that a legal notification requirement has been fulfilled.
Practise before an incident
Use the template in the privacy incident tabletop. Give the team incomplete fictional facts and ask it to produce an update without inventing a cause or affected count. The review should test whether the message helps its audience make the right next decision.
Featured image: AI-generated conceptual illustration.
