After a security incident, turn the review into four lasting updates: fix the runbook that was used, add an FAQ entry for the question people asked, record any decision made under pressure, and file the review in a searchable place. If nothing in the knowledge base changes, the incident taught the team less than it could.
What a postmortem is
Google's SRE book defines a postmortem as a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root causes, and the follow up actions to prevent recurrence. It also stresses that postmortems should be blameless: focus on contributing causes without blaming individuals or teams, and assume everyone involved had good intentions.
That culture matters for knowledge too. People share what really happened when they are not afraid of punishment.
The four updates
| Review finding | Knowledge base update |
|---|---|
| A step was missing, wrong or slow | Edit the runbook. Date it and note the incident. |
| People asked the same question mid incident | Add an FAQ entry, answer first. |
| A trade off was decided on the fly | Write a decision record with the options and reason. |
| A new failure pattern appeared | Add a short lessons page and link it from related runbooks. |
Do these within a week, while details are fresh. Assign each to a named owner in the review itself.
Steps to build it into the process
- Add a "documentation changes" section to the postmortem template.
- During the review meeting, ask: which page would have helped, and does it exist and is it correct?
- List each update with an owner and due date.
- Link every changed page back to the review, and the review to the pages.
- Follow up at the next team meeting until all items are closed.
Define when a postmortem is written before an incident happens. The SRE book lists common triggers, such as data loss, on call intervention like a rollback, a long resolution time, or a monitoring failure that meant manual discovery.
Write the lessons so strangers can use them
An outsider will read this page months later. Write it so they can follow it:
- State what happened, in order, with times.
- Name the contributing factors in system terms, not people.
- State what worked, so the team keeps doing it.
- Keep indicators of compromise and sensitive details out of broad spaces. See what should never go in a security wiki.
Test the update
After editing a runbook, do a cold read: someone who was not in the incident follows the steps. See testing a runbook with a cold read.
Where Safeguard fits
For incidents rooted in a compromised dependency, Safeguard's SBOM and dependency scanning help establish which services were affected, and the findings give the review facts to cite.
Sources
Quick check
Do all incidents need a full postmortem?
No. Set criteria in advance. Small events may need a runbook edit and a short note.
Who writes the knowledge base updates?
The owners of the affected pages, assigned during the review, with a due date.
Last reviewed: 19 October 2026.
