Store every postmortem in one repository and give each a few consistent tags: how it was detected, what class of cause contributed, which system was involved and its severity. Review the tags quarterly to see patterns that single incidents hide. Google notes mature teams add machine-readable tags to enable analytics.
Why a repository and tags
Google's SRE book says that once a postmortem is complete and reviewed, it is added to a team or organization repository of past incidents, and that transparent sharing makes it easier for others to find and learn from it. The Workbook adds that mature postmortem cultures often add machine-readable tags and other metadata for downstream analytics.
One incident tells you a story. Fifty tagged incidents tell you where to invest.
A starter schema
Keep it small, or no one will fill it in.
| Tag | Example values |
|---|---|
| Detection source | Own monitoring, customer, partner, researcher, audit |
| Cause class | Access control, dependency, configuration, build or release, process gap, third party |
| Affected area | Service or product name |
| Severity | Your own levels |
| Time to detect | Bucketed, for example under 1 hour, 1 to 24 hours, over 24 hours |
| Time to contain | Same buckets |
| Action types | Prevent, detect, mitigate |
| Status | Draft, reviewed, actions open, closed |
The Workbook also says you can add team specific metadata as your practice matures. For instance, a mobile team might record platform versions. A security team might record the ecosystem for supply chain events.
Steps to set it up
- Pick a home. A wiki space, a folder or a ticket project is fine if everyone can search it.
- Create a template with the tag fields as dropdowns where possible. Free text produces twenty spellings of the same cause.
- Back fill the last year of incidents. Even rough tags are useful.
- Make the tags part of the review checklist, so no postmortem is closed without them.
- Once a quarter, count by tag. Look at the top cause class and the slowest detection source.
- Turn one pattern into a roadmap item, with an owner.
For turning patterns into plans, see use incidents to shape a security roadmap without whiplash.
Pitfalls
- Too many tags. Five to eight fields is plenty.
- Tags as blame. Never tag a person. Tag the system and the control.
- Counting incidents as a score. More incidents recorded can mean a healthier reporting culture, not a worse system. Look at detection source and time to detect, not just volume.
- One cause per incident. Allow multiple cause classes. Google's guidance speaks of contributing causes in the plural. See human error is not a root cause.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a component inventory gives you an "affected area" tag for supply chain incidents.
How Safeguard fits
For dependency related incidents, an inventory makes the affected area tag accurate. Safeguard's SBOM and dependency scanning supports that, with a free scan at https://gold.safeguard.sh/scan.
Quick check
Do we need special tooling for tags?
No. A spreadsheet or wiki table works. Consistency matters more than tooling.
Should near misses be tagged too?
Yes, with a separate severity or type value, so you can compare them with full incidents.
Sources
Last reviewed: 19 October 2026.
