Postmortem Sanitize-for-Public-Sharing Prompt
Prepare an internal postmortem for external or cross-customer sharing by finding secrets, PII, customer names, and internal details that must be stripped or redacted — without gutting the technical lesson.
- Target user
- SRE / eng manager publishing or sharing a postmortem externally
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a staff SRE and careful editor who has published external postmortems and reviewed many for disclosure risk. Your job is to flag what must be removed or generalized before this document leaves the company — while preserving the technical narrative that makes it worth sharing. I will paste the internal postmortem draft below: [POSTMORTEM DRAFT] [SHARING CONTEXT: public blog, a single customer, an industry group, or a regulator] Do the following: 1. Scan for hard secrets and security-sensitive detail: credentials, tokens, internal hostnames/IPs, file paths, exploit-enabling specifics, and unpatched-vulnerability detail. Flag each with its location and the disclosure risk. 2. Scan for PII and customer identifiers: real names, emails, account IDs, customer names, region/tenant identifiers, and quoted chat that names individuals. 3. Scan for internal-only context that should be generalized, not necessarily removed: team names, internal tool names, org structure, roadmap hints, and unannounced products. 4. For each finding, recommend an action: REMOVE, REDACT, or GENERALIZE — and propose the replacement wording where it can be generalized without losing the lesson. 5. Identify anything that, even after redaction, still uniquely identifies a customer or person through context (the re-identification risk) and flag it. Output format: a findings table (Location / Item / Category / Risk / Action / Suggested replacement), then a short note on residual re-identification risk. Guardrails: you are flagging candidates, not certifying the document as safe — list what you find but state clearly that you may miss things and a human and, where relevant, legal must do the final review. Do not paraphrase away the technical root cause while sanitizing. Keep all framing blameless. Mark anything ambiguous as [NEEDS HUMAN DECISION].
Why this prompt works
Public and cross-customer postmortems are some of the most valuable artifacts a team produces, but they are also a disclosure minefield. A single internal hostname, an unredacted token in a pasted log, or a customer name in a quoted chat can turn a goodwill-building writeup into an incident of its own. The risk is not only obvious secrets — context-based re-identification, where redacting the name still leaves enough detail to point at one customer, is the failure mode people miss.
This prompt separates the scan into the categories that matter: hard secrets, PII and customer identifiers, and internal context that should be generalized rather than deleted. The REMOVE / REDACT / GENERALIZE distinction is what keeps the document useful — the goal is to strip what is sensitive while keeping the technical root cause that makes sharing worthwhile. Blunt redaction that paraphrases away the actual cause produces a sanitized but pointless document.
Most importantly, the prompt refuses to certify safety. An LLM pass is a fast first filter that surfaces obvious and many subtle leaks, but it will miss things, and disclosure decisions carry real legal and security weight. By flagging candidates, marking ambiguous items for human decision, and explicitly deferring final clearance to a person (and legal where warranted), it keeps the human firmly in the accountable seat.