A post-incident review that explains not only what failed technically, but how the failure affected people, work, and dependency chains. It treats user harm as part of the incident record, which gives leadership a better basis for prioritising resilience improvements.
What a Human-Centred Postmortem Captures
A human-centred postmortem treats an incident as more than a technical outage report. It records how people were affected, which teams absorbed the disruption, and where dependency chains amplified the blast radius.
This framing matters because the “incident” is often larger than the failing component. If a service outage forces manual workarounds, delays customer commitments, or creates unsafe operational pressure, those effects belong in the record alongside the technical root cause.
Why Human Impact Belongs in the Incident Record
Traditional postmortems can over-index on root cause, ticket chronology, and system symptoms. A human-centred postmortem broadens the lens so leadership can see whether the issue caused missed work, degraded decision-making, service strain, or downstream coordination failures.
That makes the document more useful for prioritisation. The NIST Cybersecurity Framework 2.0 emphasises governance and recovery as organisational responsibilities, and a human-centred review helps translate those responsibilities into real-world operational consequences.
It also improves learning quality. A review that only names the broken system may miss the conditions that made the failure painful, such as inadequate fallbacks, unclear ownership during incident response, or dependency on a single team to keep work moving.
How Dependency Chains Change the Severity of an Incident
Dependency chains are the hidden multiplier in many incidents. When one service, workflow, or approval step fails, the disruption can cascade into adjacent teams, manual processes, customer commitments, and regulatory or support obligations.
A human-centred postmortem makes those cascades visible. It asks where the break in one layer created queueing, rework, missed handoffs, or time-sensitive harm elsewhere, rather than treating the original fault as isolated.
That perspective aligns with the way modern resilience is assessed in practice. For example, NIST SP 800-207 Zero Trust Architecture and related resilience thinking both assume that weak trust in one area can propagate damage if the surrounding controls and dependencies are not made explicit.
What Makes This Style of Postmortem Different
The key difference is that the review measures success by organisational learning, not by how cleanly the timeline reads. It captures user harm, operational burden, and dependency failure as first-class facts, because those are often the strongest indicators of where to invest next.
A strong human-centred postmortem also improves accountability without becoming blame-heavy. It focuses on system conditions, process gaps, and recovery friction, which helps teams talk honestly about what happened and what should change.
For teams working on service reliability, the same principle is reflected in incident-learning methods used across postmortem culture and resilience programmes: the review should surface the organisational cost of failure, not just the technical defect.
Risk and Threat Considerations
When postmortems ignore human impact, organisations can understate the real severity of an incident. That creates a risk that repeated “minor” technical failures continue to impose major operational, customer, or safety costs because the harm is not being measured where decisions are made.
Failure mechanism: A narrow incident review captures the component failure but misses the downstream burden on people, teams, and dependent workflows, so the same fragility keeps reappearing in different forms.
Impact: Leadership may prioritise the wrong fixes, underestimate resilience gaps, and leave high-friction dependency chains intact, which increases the chance that future incidents cause broader disruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-02 — Roles, Responsibilities, and Authorities | Human-centred postmortems clarify who was affected and who owned response decisions. |
| RC.CO-02 — Incident Reporting | Postmortems formalize incident communication and the record of effects on operations and people. | |
| RC.IM-01 — Improvements Are Incorporated | These reviews exist to convert lessons about human harm and dependency failure into resilience improvements. | |
| Recommendation — Assign clear postmortem ownership across teams so incident learning captures operational impact and accountability. Document incident effects on services and people so recovery decisions reflect the full operational impact. Feed postmortem findings into resilience improvements that address the exposed dependency chain. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | Post-incident reviews support planned incident handling and learning from disruptions. |
| A.5.27 — Learning from information security incidents | Human-centred postmortems are a structured way to learn from incidents across technical and human effects. | |
| Recommendation — Use incident reviews to capture business and human impact alongside technical root cause. Record what people experienced during the incident so lessons improve future response and resilience. | ||
Practitioner Guidance
Why practitioners should care: Human-centred postmortems are most useful when incident severity is judged by business and operational harm, not just technical downtime. If a failure forced manual work, delayed decisions, or created unsafe pressure on staff, that effect should be explicit in the review.
Governance implication: Treat postmortem ownership as a cross-functional responsibility, so the review includes the technical fault, the affected teams, and the dependency path that turned the fault into user or operational harm.
Practitioner takeaway: A good postmortem should explain what broke, who felt it, and why the organisation was exposed to that degree of disruption.