Review how a breach was communicated. Twilio learned on 4 August 2022 that employee credentials had been phished and published one incident report page that it kept updating - the updates named 163 affected customers out of more than 270,000 and 93 Authy users out of roughly 75 million, and the conclusion tied an earlier 29 June 2022 voice-phishing incident to the same actors. What would you keep from this format, what would you change, and what does a sequence of press statements do instead?

What this format gets right

One canonical URL that is edited rather than replaced. A reader arriving in November and a reader arriving in August reach the same document and see the same history, which is the only arrangement under which the question "what is currently known" has a single answer.

Every count is paired with its denominator. "163 customers" and "163 of more than 270,000 customers" are different statements, and only the second one lets a reader estimate their own probability of exposure. The same applies to 93 Authy accounts against roughly 75 million: the shape of the attack - targeted, narrow, credential-driven - is visible in the ratio and invisible in the raw count.

The conclusion widened the scope backwards, attributing an earlier June incident to the same actors. That reads like bad news management and is the opposite: it is the only way a customer learns that the original scoping was incomplete and that their June logs are also worth checking.

What I would change

Add an as-of line and a direction-of-travel sentence to every count. A number published bare is read as final, so each revision looks like a retraction rather than like progress. One sentence fixes it: "accurate as of the date on this update; the count can rise as log analysis completes and will not fall." Without it the organisation faces a choice between publishing early and looking wrong, or publishing late and looking evasive, and most choose late.

Replace "we have notified affected customers individually" with a self-service check. Individual notification is correct and it leaves the other 269,000 accounts unable to resolve their own status, so they open support tickets. A dated statement of the form "if you were affected you received an email to your account owner address on or before X; if you did not, you were not in the identified set" costs one sentence and removes most of that load.

State the detection and containment times separately from the discovery date. "Learned on 4 August" tells a reader when the clock started for you, not how long the exposure ran.

What a sequence of press statements does instead

It produces N documents with no defined ordering. Search engines surface whichever one has the most inbound links, which is reliably the earliest and most alarming. A customer cannot diff two statements to see what changed, so the second statement is read as a new incident. A living page makes the delta visible; a press cycle hides it.

What I would leave alone

The long tail. An investigation conclusion arriving months after the first notice is not slowness to apologise for; it is the honest duration of forensic work on a large estate. Publishing a conclusion in week two would have meant publishing a guess.

Common weak answers

• "Publish less until the investigation finishes." Silence is read as a larger number. The cost of a revised count is small when the revision rule was published with the first count.
• "Give a percentage instead of a count." 0.06% of customers sounds like nothing and is wrong for the 163, each of whom needs to act. Publish both the count and the denominator.
• "Add more technical detail." The audience for a breach notice is a customer deciding whether to rotate credentials, not a researcher. Detail that does not change that decision belongs in a later write-up.