This lesson's interactive features are locked, please to keep using them

Postmortems

Once you've contained and recovered from an incident, the fun has just begun. A postmortem is a structured review of what happened. The goal is to identify root causes and produce follow-up actions that prevent the same kind of failure.

System Causes

Ask why the incident was possible, not just what failed first. Root cause analysis means tracing the chain of contributing failures instead of stopping at the first one you find. Look for:

Initial entry point – how did the attacker or condition first get in?
Missing controls or checks – what should have prevented this but didn't exist?
Assumptions that didn't hold – what did the system rely on that turned out to be false?
Detection and alerting gaps – why wasn't this caught sooner?
Internal processes – what about our processes caused Simon in IT to want to use a weak password?

Blameless Postmortems

A good postmortem avoids personal blame (unless it's Allan's fault) but still assigns action ownership.

Bad postmortems focus on who made a mistake and end with vague "be more careful" finger-wagging. Good postmortems describe the system conditions that allowed the failure, identify concrete control gaps, and produce specific follow-up work.

The goal is to ship changes that make the system safer, not to shame the people who originally built it.

See Google SRE on Postmortems and the OWASP SCS Incident Response Handbook for more detailed examples.