Postmortem Anonymization

Strip PII.

What to scrub

Anonymisation is the discipline that makes a public postmortem safe. Scrub the things that identify customers or expose private architecture; preserve the things that teach.

• Customer identifiers. Email addresses, names, account IDs all replaced with placeholders. Customer privacy is non-negotiable.
• Internal hostnames and IPs. Internal service names, hostnames, and IP addresses redacted. Architecture privacy preserved.
• Sensitive product detail. Feature flags, A/B test names, business-context numbers. Competitive position stays protected.
• Credentials sweep. Explicit search for accidentally-pasted tokens, keys, or session IDs. Belt-and-braces against the worst-case leak.

What to preserve

Over-scrubbing kills the postmortem’s value. Preserve the technical detail and the narrative; that is where the lesson lives.

• Service names after assessment. Public services usually publish-as-is; internal-only services redact. Decide per service.
• Technical detail. Error messages, log excerpts, metric values. The technical specifics are the lesson.
• Timeline. Dates, durations, and sequence. The narrative is what teaches future on-call.
• Contributing factors. The explicit contributing-factor list preserves the system view of the incident.

Automation

Anonymisation is an automation problem with a human review backstop. Regexes catch most leaks; humans catch the rest.

• Anonymisation pipeline. Regex-based scrub of email, IP, customer ID, and known sensitive patterns. Automated and runs on every export.
• Pre-publish human review. One human reads the redacted document before it ships. Catches what regex misses.
• Quarterly random-sample audit. Random sample of published postmortems audited for leaks. Drift catches drift.
• Per-team redaction policy. The team’s explicit policy lives in the wiki. Future reviewers reference the same standard.

Publication policy

The publication policy is the contract between engineering, legal, and the audience. Internal and external versions serve different audiences and need different bars.

• Internal vs external versions. Two-version pattern: internal less aggressive scrub; external tightly redacted. Same lesson, different audiences.
• Legal review for high-stakes. Major incidents touching customer data or money go through legal. The review matches liability.
• Annual standards review. Walk the published postmortems each year. Drift in standards gets remediated.
• Per-postmortem approval gate. Explicit approval before publication. Nothing goes external without sign-off.