Control objective
A security postmortem explains what happened, why defenses and response behaved as they did, and which system changes reduce recurrence or impact. It seeks accountable improvement without using blame as a substitute for causal analysis.
Evidence and timeline
Separate observed facts, inference, and unknowns. Record detection, decisions, access, target effects, containment, last accepted action, recovery, and communication. Include system conditions and normal incentives that made the path possible.
Corrective action
Write actions against causes and contributing conditions. Each action needs an owner, due condition, priority, validation method, and evidence. Prefer control, test, automation, architecture, and recovery changes over reminders alone.
Failure and residual risk
A linear root cause can hide interacting conditions. A document can close while actions remain untested. Excess detail can expose sensitive data or people. Blame discourages reporting and does not remove authority or complexity.
Pomerium boundary
Pomerium records can support the access timeline for routed requests. The review also needs identity-provider, deployment, network, endpoint, application, and response evidence. Pomerium cannot supply business impact or causal conclusions by itself.
Evaluation checklist
- Are facts, inferences, unknowns, and time uncertainty separate?
- Does the analysis include technical, organizational, and recovery conditions?
- Does each action have an owner and observable validation?
- Have controls and exercises changed, not only documentation?
- Can future responders detect and contain the path faster?
