Post-Incident Review & Root Cause UI in Figma

Quick answer

Post-incident review UI turns war-room chaos into durable improvements—without blame, with traceable root causes, and with actions that actually ship. Design a blameless timeline reconstructed from logs and human notes; a five-whys / cause tree board with contributing vs root causes; corrective action tracker with owners and due dates; and an executive summary export for leadership and auditors. Start from the Figma guides hub and pair with war room, forensic evidence, incident runbooks, security posture dashboard, and Dev Mode handoff.

Who this is for

Product designers building postmortem modules, RCA workspaces, and improvement backlogs inside enterprise Security and SRE platforms.
Design system teams aligning timeline lanes, cause-tree nodes, and action status chips with badges, tables, and progress steppers.
Engineering teams implementing immutable incident timelines, action ticket sync, and PDF/Markdown export for compliance archives.

Post-incident review hub (case closure)

PIRHub — Case INC-2026-0891 · Status: Review in progress
├── Header: Sev 1 · Duration 18h 42m · Facilitator: Jordan Lee · Target close: 2026-08-02
├── Actions: [ Import war room timeline ] [ Start five whys ] [ Add action item ] [ Publish summary ]
├── Tabs: Timeline · Cause analysis · Actions · Participants · Executive summary
├── Progress: Timeline ✓ · RCA draft · Actions 3/7 complete · Summary not published
└── Link: Evidence locker (14 artifacts) · Breach notification (filed)

Section	Purpose
Timeline	Blameless reconstruction of detection → containment → recovery
Cause analysis	Five whys, fishbone, or fault tree—pick one primary pattern
Actions	Corrective and preventive items with owners
Participants	Who attended review; optional anonymous contributor mode
Executive summary	Non-technical export for leadership and board

Verdict: PIR opens only after operational closure (containment complete)—not while war room is active. Link from shift handover “Close incident” action.

Blameless timeline reconstruction

TimelineCanvas — INC-2026-0891
├── Lanes: Detection · Response · Communication · Recovery · External
├── 2026-07-24 2:14 AM — SIEM alert fired (auto) · Source: [automation run](/designing-security-automation-and-response-workflows-ui-in-figma/)
├── 2026-07-24 2:31 AM — Analyst acknowledged (human) · Jordan Lee
├── 2026-07-24 4:02 AM — Containment: disable compromised API keys (human)
├── 2026-07-24 9:15 AM — Legal engaged (human) · Link breach case
└── Gap flagged: 47 min between alert and ack — tagged for RCA

Element	UI detail
Event source	Auto (log), human note, or imported runbook step
Actor	Person or system—never use for performance scoring in UI
Evidence pin	Link artifact from evidence locker
Gap highlight	Visual marker when SLA or expected step missing
Edit policy	Append corrections; do not delete original entries
Zoom	Hour view for active IR; day view for long incidents

Import baseline from war room shift log to avoid retyping.

Five whys and cause tree board

CauseTreeBoard
├── Problem statement: Unauthorized API access persisted 6 hours before key revocation
├── Why 1: Compromised key not rotated after employee offboarding
├── Why 2: Offboarding checklist did not include API key inventory
├── Why 3: No automated discovery of keys owned by departing user
├── Why 4: Key management lived outside IAM provisioning workflow
├── Root cause (candidate): API keys not in SCIM deprovision scope
├── Contributing: Delayed alert triage (47 min) — separate branch
└── Tags: Process · Tooling · Training · Third party

Node type	Visual treatment
Problem	Single locked statement at top
Why node	Numbered chain; max depth warning at 7
Root cause	Distinct badge; requires facilitator approval
Contributing	Parallel branch—does not replace root
Rejected hypothesis	Struck through with reason—keeps audit trail
Category tag	Process, tooling, people (as factors, not blame), vendor

Use cards for each why node; connector lines for tree edges.

Facilitator role can mark “Root cause validated”—locks branch from casual edits.

Corrective action tracker

ActionTracker — INC-2026-0891
├── Open: 4 · In progress: 2 · Done: 1 · Overdue: 1
├── Row: ACT-441 · Integrate API keys into SCIM deprovision · Owner: Platform · Due 2026-08-15 · Priority P1
├── Row: ACT-442 · Add alert ack SLA dashboard · Owner: SOC · Due 2026-08-01 · Overdue
├── Row: ACT-443 · Update offboarding runbook v3.2 · Owner: IT · Due 2026-07-30 · In progress
└── [ Create action ] [ Bulk export to Jira ] [ Link to posture metric ]

Field	Handoff
Action ID	Immutable; links from executive summary
Type	Corrective (fix) vs preventive (avoid recurrence)
Owner	Single DRI; team roles for visibility
Due date	Required; overdue shows badge
Source	Linked why node or timeline gap
Verification	”How we know it worked” field before Done
Ticket sync	External issue URL optional

Closing PIR case requires all P1 actions either Done or explicitly deferred with exec approval.

Participants and blameless ground rules

ParticipantsPanel
├── Facilitator: Jordan Lee · Scribe: Ana Liu · Required: CISO delegate ✓
├── Attendees: SOC (3) · Platform (2) · Legal (1) · Comms (0) — optional invited
├── Anonymous feedback: 2 submissions (facilitator-only view)
└── Ground rules banner: Focus on systems · No individual blame · Assume good intent

Feature	Why
Role tags	Facilitator, scribe, decision-maker
Attendance optional	Legal/Comms for breach-linked PIRs
Anonymous input	Forms for sensitive context
Ground rules	Persistent banner; link security policy acceptance
Export list	Names in internal PDF; redacted version for wider share

Executive summary composer

ExecutiveSummary
├── Sections: Impact · Timeline (plain language) · Root cause · Actions taken · Lessons · Next steps
├── Metrics: Downtime 0 · Records exposed ~12k · Time to contain 6h · Time to detect 47m
├── Tone: Non-technical · No individual names · Approved by: CISO (pending)
├── [ Preview PDF ] [ Submit for approval ] [ Publish to leadership portal ]
└── Version history: v1 draft · v2 after Legal review

Section	Content guardrails
Impact	Business, customer, regulatory—aligned with breach notification if applicable
Timeline	5–7 bullets max
Root cause	One primary; contributing in appendix
Actions	Link ACT- IDs; show due dates
Lessons	What worked in response—not hero narratives
Approval	CISO + Legal when breach case linked

Publish triggers audit log entry and optional compliance export archive.

Metrics and SLA reflection

MetricsPanel — Response effectiveness
├── MTTD: 47 min (target 15) · Gap tagged in timeline
├── MTTC: 6h 12m (target 4h)
├── MTTR: 18h 42m total incident duration
├── Runbook adherence: 8/10 steps followed · Link [runbook](/designing-incident-response-runbooks-and-security-playbooks-ui-in-figma/)
├── Automation contribution: 3 auto-containment actions
└── Compare: vs org baseline · vs previous Sev 1 (INC-2026-0412)

Metric	UI note
MTTD/MTTC/MTTR	Define formulas in tooltip
Baseline comparison	Sparkline or delta badge
Runbook score	Which steps skipped—feeds RCA
No leaderboards	Avoid ranking analysts by speed

Feed overdue actions into security posture dashboard as open PIR debt.

Integration with runbooks and automation

Source	PIR usage
Incident runbook	Expected steps vs actual timeline
Automation workflow	Auto actions as timeline events
Threat hunting workspace	Detection query saved as lesson
Forensic locker	Evidence pins on timeline
Breach notification	Disclosure dates on Communication lane

Runbook update action: one-click “Propose runbook change” spawns ACT item pre-filled with gap reference.

PIR templates by incident type

Template	Extra sections	Pairs with
Data breach	Regulatory timeline, scope evolution	Breach notification
Ransomware	Backup restore path, payment decision log	Forensic evidence
Account takeover	Affected users, session revocation	Suspicious login
Third-party vendor	Vendor timeline, contract SLA	Vendor risk
DDoS / availability	Capacity, mitigation vendor	War room
Insider threat	HR/legal sealed appendix	Offboarding

Template picker on PIR creation—preloads lanes and summary sections.

Handoff checklist (Dev Mode)

PIR lifecycle — states: Draft → Review meeting → Actions open → Closed.
Timeline immutability — append-only edits with amendment reason.
Cause tree schema — node types, max depth, root validation role.
Action sync — Jira/Linear webhook fields and status mapping.
Executive PDF — template sections, redaction rules, approval signatures.
Metrics formulas — MTTD/MTTC/MTTR definitions and data sources.
Permissions — who sees anonymous feedback; sealed HR appendix.
Archive — retention link to compliance export and data retention.

Common mistakes

Mistake	Why it hurts	Fix
Naming individuals in root cause	Blame culture; legal exposure	System and process language; sealed appendix for HR
PIR during active incident	Incomplete facts	Gate until operational closure
Actions without owners	Nothing ships	Required DRI and due date
Generic “train staff” actions	Unmeasurable	Tie to runbook version or control ID
Timeline without evidence links	Disputed facts	Pin artifacts to key events
Executive summary before Legal review	Wrong external narrative	Approval gate when breach linked
Deleting timeline events	Audit failure	Append amendments only
Leaderboards on MTTR	Perverse incentives	Team metrics only
Closing PIR with open P1 actions	Recurrence likely	Block close or exec deferral
No link to posture dashboard	Improvements invisible	Surface open PIR debt on dashboard

Recommended workflow

Design PIR hub with tabs, import from war room, and closure criteria.
Build blameless timeline with lanes, gaps, and evidence pins.
Implement cause tree board with five whys, root validation, and categories.
Add action tracker with ticket sync, overdue states, and verification field.
Create executive summary composer with approval and PDF export.
Wire metrics and posture dashboard links in Dev Mode.

FAQ

PIR vs incident runbook?

Runbook is the planned response; PIR analyzes what actually happened and updates runbooks and controls afterward.

Blameless vs anonymous?

Blameless means UI copy and exports avoid individual fault; anonymous feedback is optional input channel—facilitator sees it, not attribution in timeline.

When to link breach notification?

When incident triggered regulatory disclosure—Communication lane shows filing dates; executive summary requires Legal approval.

Root cause vs contributing cause?

Root cause — systemic fix that prevents recurrence; contributing — factors that worsened impact but are not the primary system gap. UI keeps separate branches.

PIR retention?

Archive with case—same legal hold rules as forensic evidence when litigation possible.

Next steps

Design security operations shift handover and war room UI in Figma — source timeline for PIR import
Design forensic evidence management and chain of custody UI in Figma — pin artifacts to timeline events
Design incident response runbooks and security playbooks UI in Figma — update runbooks from PIR actions
Design breach notification and regulatory reporting UI in Figma — align Communication lane and executive summary
Design security posture dashboard and compliance checklist UI in Figma — track open PIR actions and MTTR trends

Designing post-incident review and root cause analysis UI in Figma: timelines, five whys, and action tracking