What do postmortems get wrong when they ignore people?

They reduce incidents to engineering timelines and miss the actual cost to users, customers, and operators. That leads to remediation plans that look complete on paper but fail to address the workflows and access paths people depended on during the outage. Good postmortems explain what changed for humans, not just for systems.

Why This Matters for Security Teams

Postmortems are often treated as technical artefacts, but incidents are lived through human work: support desks absorb the confusion, operators improvise around missing access, customers lose trust, and business teams make decisions with incomplete information. When those effects are omitted, the report can still satisfy a compliance checklist while missing the operational failure that actually mattered. The NIST Cybersecurity Framework 2.0 puts governance and outcomes at the centre of security, which is the right lens for post-incident learning as well.

The common mistake is to confuse a timestamped sequence of alerts with a root-cause analysis of impact. That framing narrows the lesson to system recovery speed, leaving out who could not log in, which approvals stalled, which manual workarounds were unsafe, and which identities or service accounts became single points of failure. For NHI-heavy environments, that omission is especially costly because machine access often substitutes for human oversight, and the people who depend on those controls are rarely represented in the write-up.

In practice, many security teams encounter the real blast radius only after business operations, support queues, or customer escalations have already revealed what the postmortem failed to capture.

How It Works in Practice

A useful postmortem traces the incident across both systems and human decision points. That means documenting not only what failed, but who was blocked, who had to improvise, which approvals were delayed, and which compensating actions introduced new risk. Current guidance suggests using a timeline, but the timeline should include human checkpoints such as escalation handoffs, access requests, manual overrides, and communications failures.

Security teams should separate technical cause from operational consequence. A service outage may stem from a bad deployment, but the human impact could be that a privileged operator could not reach the console, a customer could not complete a time-sensitive transaction, or a responder had no clear authority to bypass a broken control. Those are not side notes. They are often the reason the incident became severe.

• Record user groups affected, not just affected hosts or services.
• Capture access paths, approvals, and fallback methods that failed under pressure.
• Note whether monitoring detected the fault before people reported it.
• Document workarounds and whether they increased exposure or weakened segregation of duties.

For process discipline, many teams align the report with lessons from CISA incident response guidance, because it encourages consistent triage, communication, and recovery ownership. Where identity or privileged access was involved, it is also sensible to ask whether the incident exposed brittle account recovery, over-permissioned service identities, or unclear emergency access paths. Those issues often appear in the aftermath as “people problems,” but they are usually control design problems. These controls tend to break down when recovery depends on a small number of responders working from tribal knowledge because the formal process does not describe how humans actually restore service under stress.

Common Variations and Edge Cases

Tighter postmortem requirements often increase reporting effort, requiring organisations to balance analytical depth against the speed needed to restore normal operations. That tradeoff is real, especially after high-severity outages when teams want to close the event quickly. Best practice is evolving, but there is no universal standard for yet another metric-heavy template that automatically captures human impact well.

The edge cases are where people are easiest to ignore. In a customer-facing outage, the important human story may be fraud review friction, failed identity verification, or missed service deadlines rather than pure availability. In an internal systems incident, the relevant people may be on-call engineers, IAM administrators, or help desk staff forced into unsafe manual steps because the normal workflow was unavailable. In agentic AI or NHI-heavy environments, the question becomes whether autonomous systems had authority that bypassed human escalation, and whether the postmortem examined that delegation clearly.

When there is a regulatory or contractual angle, the report should distinguish operational loss from legal exposure. For example, a breach notification timeline, a payment workflow disruption, or a healthcare access interruption may require different evidence than a standard engineering incident review. The same is true for privacy-sensitive logs: a postmortem can be thorough without exposing unnecessary personal data. Guidance from frameworks such as NIST SP 800-63 Digital Identity Guidelines is useful when identity proofing, authentication, or account recovery contributed to the failure. The practical question is simple: did the report explain how the incident changed real work, or did it only catalogue what the tooling observed?

Related resources from NHI Mgmt Group

• What do organisations get wrong when they secure AI only at the model layer?
• What do organisations get wrong when they let AI assistants handle privacy lookups?
• What do teams get wrong when they treat sso as a one-time integration?
• What do teams get wrong when they rely on human-in-the-loop controls for AI?