---
name: it-incident-postmortem
description: Reconstructs an IT service incident and produces a blameless post-mortem with impact, contributing factors, corrective actions, and customer-facing facts. Use for outages, security-adjacent service failures, major incidents, and recurring support escalations.
license: Apache-2.0
metadata:
  adlass.categories: "it-security/incidents-postmortems, operations/quality-management"
  adlass.industries: "it-services"
  adlass.tags: "incident, postmortem, it-services, outage, remediation"
  adlass.adaptation: "reference-doc"
  adlass.source: "n8n:IT-02"
  adlass.version: "1"
---

# IT incident post-mortem

## Purpose

Turn fragmented incident evidence into a reliable account of what happened, why controls failed, and what will reduce recurrence.

## Scope

Operational incidents affecting availability, performance, data handling, support, or service commitments. **Excluded:** live remediation, blame assignment, and legal or regulatory reporting decisions.

## Data basis

- Incident timeline, logs or alerts, ticket history, communication record, service agreement, change history, and similar incidents.
- The fixed records, tables, or folders in the skill scope that hold the relevant history or schema.

## Result

A post-mortem document, action register, and factual customer-summary draft.

## Quality criteria

- The timeline cites the source for each material event.
- Impact quantifies affected services, users, duration, and commitments where data exists.
- Trigger, contributing factors, detection gap, and root cause are separated.
- Actions have a measurable completion criterion and owner or missing owner.
- The customer summary contains no internal speculation or blame.

## Instructions

Resolve timestamps to one stated time basis and flag conflicting times. Distinguish evidence from interpretation and avoid using a proximate trigger as the whole cause. Compare the incident with prior cases to identify systemic patterns. Include what worked as well as what failed. Keep security-sensitive details out of the customer version unless explicitly approved in scope.

## Adapt before use

Keep the source trail close to every conclusion and preserve the difference between a source fact, a calculated value, an assumption, and a recommendation. Use stable identifiers across the document and sheet so a reviewer can move from a summary statement to the underlying row and source. Prefer a complete, transparent partial result over a confident answer built on missing evidence.

- Add the incident taxonomy, severity policy, and post-mortem template.
- Define impact metrics, service-level terms, and time-zone conventions.
- Specify action ownership and follow-up review cadence.
- Set rules for security, privacy, and customer-facing content.