Incident updates: distinguish containment from repair

Incident communication should tell affected users what is established, what has been contained and what remains unresolved. This checklist is an editorial approach informed by the separation of response and recovery in incident management. It is not evidence about any particular project's incident.

Build a factual timeline Record detection, disclosure, acknowledgement, containment, remediation and retest as separate events. A message saying the team is investigating establishes acknowledgement, not repair. A disabled feature may reduce exposure while leaving the underlying defect unresolved.

Ask for the evidence of closure A credible closure record identifies the affected version, the change and the retest conditions. Some details may need to remain private while users are exposed, but that does not justify presenting an unverified claim as a completed fix.

Preserve uncertainty without evasiveness Explain the limits of the available evidence in plain language. If no response has arrived, say that no response was received; do not claim that silence proves exploitation or deliberate neglect. Equally, a polite acknowledgement should not erase a reproducible technical finding. The status needs to follow the evidence rather than the tone of the conversation.