Share the lessons as widely as you can, and restrict the details that could cause harm: live weaknesses, secrets, personal data and unconfirmed claims about people. The simplest approach is two layers, a broad summary for everyone and a restricted appendix for the response team.
The tension
Google's SRE guidance aims to share postmortems with the widest audience that would benefit, because learning spreads when documents are open. It also notes strict rules about information that could identify an end user, so even internal postmortems never include it. Both ideas apply to security work, where the same document can teach and expose.
What should be restricted
| Content | Why | Where it goes |
|---|---|---|
| Credentials, tokens, keys | Direct misuse | Never in the document, even redacted partly |
| Unfixed weaknesses | Others could exploit before the fix | Restricted appendix until fixed |
| Personal data | Privacy rules and trust | Counts only, not records |
| Names of individuals | Blameless culture | Use roles |
| Customer identities | Contract and trust | Restricted appendix, or codes |
| Raw malicious samples | Risk of accidental execution | Restricted storage with a warning |
| Unconfirmed attribution | May be wrong | Leave out |
Two layers
Layer one, broad. Summary, impact in plain terms, causes, actions and what went well. Safe for the whole engineering organisation, and often for the whole company.
Layer two, restricted. Indicators, hashes, system details, customer mapping, credential tables and logs. Limited to the response team, security and, where needed, legal advisers.
Link layer two from layer one, so people with access can find it and others know it exists.
Set the access once
Decide the rules before an incident. Name who can read each layer, who can change it, who approves publishing outside the company, and how long restricted material is kept. Add this to your postmortem template so nobody improvises under pressure.
Beware of leaks through tools
Postmortems often live in a wiki, a chat thread and an email chain at once. Check the permissions on each. A restricted appendix pasted into a public channel is no longer restricted. Also check automatic features such as link previews or indexing in search tools.
Sharing outside the company
External sharing is a separate decision. Customers, auditors and the public each need a tailored summary, reviewed by your communications owner and legal adviser. This post is not legal advice. Do not send the internal document by default.
Retention
Keep the broad postmortem as long as it teaches. Keep restricted material only as long as you need it for review, contract, or legal reasons. Ask your legal adviser what applies to you, and write the answer into your policy.
Quick check
Can we publish the whole postmortem internally?
Publish layer one widely. Keep secrets, live weaknesses and personal data in a restricted layer.
Should the postmortem name the engineer who made the change?
No. Use roles. Blameless writing focuses on the system conditions that made the action reasonable.
Sources
Last reviewed: 19 October 2026.
