Write a postmortem for any incident that crosses a trigger you agreed on before it happened: data loss, user impact above a threshold, a rollback or emergency intervention, a long resolution time, or a detection failure. Anyone with a stake should also be able to request one. Deciding in advance removes the argument.
What a trigger is
A postmortem trigger is an objective condition that automatically starts a written review. It is different from a judgment call made in the heat of the moment, when the team is tired and the incident feels "small now that it is over".
Google's SRE book lists common triggers: user-visible downtime or degradation beyond a threshold, data loss of any kind, an on-call engineer having to intervene (such as a release rollback or rerouting traffic), a resolution time above a threshold, and a monitoring failure, which usually means someone found the problem by hand. It adds that criteria should be defined before an incident, and that any stakeholder may ask for a postmortem on any event.
Translating those triggers for security
Security teams can map the same idea onto their own events. A starting table:
| Trigger | Example in a security setting |
|---|---|
| Data loss or exposure | Customer or employee data left a boundary it should not have |
| Intervention required | You revoked credentials, pulled a release or blocked a package in a hurry |
| Long time to resolve | Containment took longer than your agreed target |
| Detection failure | An outside party, not your own tooling, told you first |
| Severity level | Any incident at or above the level you name, for example the top two |
| Stakeholder request | Legal, support, a customer or an engineer asks for one |
Atlassian's public handbook takes the severity route: it carries out postmortems for severity 1 and 2 incidents and treats them as optional otherwise. PagerDuty's public process also requires one for each major incident at its top two severities. Pick the cut line that fits your volume, and write it down.
Steps to set your own
- List the last ten incidents or scares you can remember. Mark which ones you would have wanted to learn from.
- Choose three to five objective triggers from the table that would have caught those.
- Add the "anyone can request one" rule, so quiet problems are not lost.
- Define a lighter option for events just under the line, such as a short note in the incident ticket. Our post on near-miss reports covers that.
- Put the list where responders will see it, for example in the incident template.
- Review it twice a year. If you are writing too many, raise the thresholds. If incidents repeat without a review, lower them.
Common mistakes
- Triggers based only on customer impact. An incident that was caught and contained inside your network still teaches something, and a missed detection is a trigger by itself.
- Letting severity be set after the fact. If severity gets downgraded to avoid paperwork, the trigger loses its meaning. Record the severity at declaration, as in declare an incident early.
- Treating the postmortem as a punishment. If people dread them, they will argue incidents down. Google's book is explicit that a postmortem is a learning opportunity, not a penalty. See blameless does not mean no accountability.
How Safeguard fits
When the incident involves a dependency or build artifact, an up to date inventory shortens the timeline work. Safeguard's SBOM and dependency scanning can show where a component is used, and you can run a free scan at https://gold.safeguard.sh/scan.
Quick check
Does every security alert need a postmortem?
No. Reserve full postmortems for events that cross your triggers. Smaller events can get a short note or a near-miss entry.
Who decides whether a postmortem is needed?
The triggers decide, so no single person has to. Stakeholders can still request one for any event.
Should a successful detection trigger a review?
Not by itself. A failed or manual detection is a standard trigger, because it points to a gap in monitoring.
Sources
- Google SRE book, Postmortem Culture: Learning from Failure
- Atlassian incident management handbook, postmortems
- PagerDuty incident response documentation, postmortem process
Last reviewed: 19 October 2026.
