The postmortem owner writes the document and drives it to publication, the incident commander runs the meeting and keeps it on track, and approvers sign off and put the follow-up actions in their teams' backlogs. One named owner matters most, because shared ownership means no ownership.
The three roles
Postmortem owner. According to PagerDuty's public process, the incident commander designates the owner at the end of the incident call or shortly after. The owner schedules the meeting, investigates with help from other teams, fills in the document, creates the follow-up tickets, reviews the content beforehand and shares results internally. Notably, in that process the owner only creates the tickets and is not responsible for chasing them to completion.
Incident commander (IC). The IC "runs" the meeting and keeps discussion focused, while the owner usually does most of the talking as they walk through the report.
Approvers. Atlassian's handbook describes approvers as managers who review and approve the postmortem and are expected to prioritise the resulting actions in their backlog. The delivery team for the service that failed chooses the owner. The owner is accountable for the postmortem through drafting and approval until it is published.
Who owns what, in a table
| Task | Owner | IC | Approver |
|---|---|---|---|
| Book the meeting | Yes | ||
| Draft timeline and analysis | Yes | Helps | |
| Keep meeting on topic | Yes | ||
| Create action tickets | Yes | ||
| Commit team time to actions | Yes | ||
| Share summary widely | Yes |
Why one owner, not four
Google's Workbook uses a deliberately bad example postmortem to make the point. It lists four owners, and most action items have none. The Workbook says an ideal owner is a single point of contact for the postmortem, follow-up and completion, with others as collaborators. The same applies to every action item.
Steps for a small team
- At the end of the incident, the IC names the postmortem owner out loud and in the ticket.
- Pick the owner from the team that owns the failing system, not the person who was blamed or who was most tired.
- Agree who the approver is: usually the engineering manager of the affected system.
- The owner books the meeting and shares the draft a day ahead.
- After the meeting, the owner files tickets and the approver confirms the team will schedule them.
- Someone other than the owner tracks overdue actions. A weekly look from a manager does the job. See the postmortem was good, the actions were not done.
If you have only two or three people, one person may hold all three roles. Keep the roles separate on paper anyway, so the question "who is following up?" always has an answer. Our guide to incident roles for a small team covers the roles during the incident itself.
Mistakes to avoid
- Making the person who caused the change the owner by default. It can feel like a penalty.
- Letting the approver be the same person as the owner. You lose the second pair of eyes.
- Naming a team instead of a person. Teams do not close tickets.
How Safeguard fits
For incidents involving software supply chain components, Safeguard's policies and gates can encode preventive follow-ups so they are enforced after the meeting, not just remembered. Try a free scan at https://gold.safeguard.sh/scan.
Quick check
Can the incident commander also own the postmortem?
Yes in a small team, but name both roles so tasks do not blur. In larger teams, separate them.
Who closes the action items?
The team that owns each action. The postmortem owner files the tickets, and approvers make sure the work is scheduled.
Sources
- PagerDuty incident response documentation, postmortem process
- Atlassian incident management handbook, postmortems
- Google Site Reliability Workbook, Postmortem Culture
Last reviewed: 19 October 2026.
