Postmortems and Root-Cause Analysis

Why It Matters

Resolving a vulnerability closes the loop with the researcher, but it doesn’t answer the question your auditor (and your own team) will ask next: why did this happen, and what did we change so it can’t happen again? A postmortem is that answer — captured once and kept for the record.

Every report has one postmortem: a private, structured root-cause analysis owned entirely by your team.

What It Captures

A postmortem pairs structured fields with three free-form narrative sections:

Field	What it captures
Summary	One-line description of the incident
Severity	The incident’s severity level
Category	The root-cause class (e.g. configuration, code defect, process gap)
Occurred / Detected / Resolved	Timestamps for when the problem began, when it was detected, and when it was fixed
Time to fix	Derived automatically from the occurred and resolved timestamps
Root cause	What actually went wrong, beneath the symptom
Corrective actions	What you changed (or will change) to prevent a recurrence
Lessons learned	What the team takes away — process, tooling, ownership

You can also attach evidence files — screenshots, logs, links to the fix commit or ticket.

When you open a new postmortem, Kit pre-fills it from the report: severity, the resolution timeline, and a starting summary are already filled in, so you begin from context rather than a blank page.

Who Can Write One

Any member of your CSIRT team can create or edit a report’s postmortem — there is no separate admin restriction. It’s available wherever CSIRT report management is, so any active program with report access can use it.

The Postmortem Tab

Open a report and select the Postmortem tab. If none exists yet, a lock-framed empty state invites you to write the first one. Creating and editing happen on dedicated, full-width forms so you have room to write.

The Audit Trail

Each save writes an immutable, attributed revision — who changed what, and when. Revisions are never overwritten or deleted, so the postmortem carries its own change history. Every revision also appears in the report’s timeline, alongside status transitions and assessments, giving you one chronological record of the whole incident.

The PDF Dossier

From the Postmortem tab you can download a per-report PDF dossier — the full report together with its postmortem in a single file. It’s your point-in-time evidence document: drop it in an audit folder, attach it to a ticket, or hand it to an auditor as the complete record of a single incident.

Compliance

A per-report root-cause analysis is exactly what several frameworks ask for:

• SOC 2 — satisfies Vanta’s “Incident report or root cause analysis” evidence test. See Vanta Integration.
• ISO 22301:2019 — supports the business-continuity requirements of §10.1.1, §10.1.2, and §10.1.3 (nonconformity, corrective action, and continual improvement).

Manage It With AI

Two MCP tools let an AI assistant read and maintain postmortems:

• csirt_get_postmortem — reads a report’s postmortem, including the three narrative sections, time_to_fix_seconds, and revisions_count.
• csirt_set_postmortem — creates or updates a postmortem (upsert). Only the fields you pass are changed; the rest is left untouched.

See the MCP Tools Reference for full parameters and permissions.

What’s Next

• Triaging Reports — resolve a report, then capture its postmortem
• Metrics and Exports — bulk SOC 2 evidence packs alongside per-report dossiers
• Vanta Integration — turn triaged vulnerabilities into live compliance evidence