Safeguard
Security Guides•

Public postmortem for customers: what to publish and what to withhold

Decide what a customer-facing postmortem should include, such as timeline, impact, cause and fixes, and what to keep internal like names and exploits.

Safeguard Security Team
3 min read

A customer-facing postmortem should state what happened, who was affected, how long, why it happened at a level customers can use, and what you are changing. Withhold names of individuals, exploit details that remain unfixed, internal blame and anything legal advises against. Aim for honest and useful, not exhaustive.

Internal and public versions differ

Your internal review can name systems, people's decisions and raw logs. The public version is a summary for customers who need to judge their own risk. Write the internal one first, then derive the public one.

What to publish

  • Summary in three sentences.
  • Timeline in UTC with start, detection, mitigation and resolution times.
  • Impact: which customers or features, what data if any, for how long.
  • Cause at the level you have confirmed. "A configuration change removed a rate limit" is enough.
  • Why detection took as long as it did, if it was slow. Customers respect this.
  • Changes with owners and target dates you are confident of.
  • What customers should do, if anything.

What to withhold

  • Names of employees. Use roles. See human error is not a root cause.
  • Exploit steps for a weakness not yet fully closed across your fleet.
  • Details of other customers.
  • Speculation about attackers or motives.
  • Anything under legal hold or active law enforcement request.

Be careful with promises

Publish only commitments you intend to track. If the postmortem says "we will add monitoring for X by next quarter", someone must own it, and you should report completion later.

Timing

Commit to a window, such as five business days, and meet it. A short follow up beats a perfect one that never arrives. If the investigation continues, publish an interim version marked as such and update it with a dated log.

Review checklist

  1. Fact checker confirms every claim.
  2. Legal reads it.
  3. A person outside the incident reads it for clarity.
  4. Customer support has the text before it is published.

Quick check

Should we publish postmortems for minor outages?

A short note for incidents that customers noticed is usually enough, with a full write up for major ones.

Is it risky to admit fault?

State facts without blame language, and let legal review wording. Vague text tends to hurt trust more than clear text.

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.