panaversity UNIVERSAL RULES (apply to every incident task)
- NEVER skip the post-mortem for a P1 incident -- the post-mortem is how the organisation learns; skipping it guarantees recurrence
- NEVER conduct a post-mortem as a blame session -- frame every question as "what in our systems, processes, or controls allowed this?" not "who made the mistake?"
- NEVER accept a corrective action that targets only the proximate cause -- fixing "the thing that broke" without fixing "why it was able to break" is incomplete
- ALWAYS include specific recommended actions with deadlines in every output -- observations without actions are not acceptable
- ALWAYS load ops.local.md for incident severity definitions, escalation paths, and post-mortem requirements
MANDATORY OUTPUT HEADER
Every output must begin with:
TASK: [e.g. Post-Mortem -- Payment System Outage]
INCIDENT TYPE: [Post-Mortem / Five Whys / Log Entry / CA Tracker / Brief]
CONFIGURATION: [Loaded: ops.local.md / Not configured]
DATE: [Date of output]
OWNER: [Named post-mortem lead]
INCIDENT SEVERITY CLASSIFICATION
Configure in ops.local.md -- defaults:
P1 -- CRITICAL:
Service unavailable; >50% of users/transactions affected;
revenue impact >threshold; regulatory notification likely
Response: immediate; senior management within 15 min
Post-mortem: mandatory; within 5 business days
P2 -- MAJOR:
Significant degradation; >20% affected; revenue impact;
customer-visible; no regulatory notification
Response: within 30 min; team lead engaged; hourly updates
Post-mortem: mandatory; within 10 business days
P3 -- MINOR:
Limited impact; <20% affected; no revenue impact; workaround available
Response: within 2 hours; standard team response; daily updates
Post-mortem: optional; log entry required
INCIDENT QUALITY STANDARDS
Every post-mortem output must include:
- Timeline (specific times -- not "eventually" or "shortly after")
- Root cause (systemic -- not the proximate event)
- Contributing factors (what made it worse)
- What went well (protect what works)
- Corrective actions (specific, owned, time-bound)
- Lessons learned (for organisation-wide sharing)
INCIDENT WORKFLOW
Task Type 1: POST-MORTEM
INCIDENT POST-MORTEM REPORT
================================================================
Incident ID: [INC-YYYY-NNN]
Severity: [P1 / P2 / P3]
Date: [Date] | Duration: [Start-End, total hours]
Status: CLOSED
Lead: [Named person]
Distribution: [Who receives this report]
INCIDENT SUMMARY
[2-3 sentences: what happened, how long, what the impact was.
Written for a leadership audience -- no technical jargon.]
TIMELINE
[HH:MM]: [Event -- specific; factual; not interpretive]
[HH:MM]: [Event]
[Note gap between START and DETECTION -- this is MTTD]
[Note gap between DETECTION and first ACTION -- response lag]
IMPACT
Users/customers affected: [N]
Transactions affected: [N / value]
Duration of impact: [Time]
Regulatory notification: [Required / Not required -- reason]
Reputational impact: [Social media / press / complaints]
Estimated financial impact: [Range]
ROOT CAUSE ANALYSIS
Immediate cause: [The proximate event]
Root cause(s): [The systemic reason -- use Five Whys]
CONTRIBUTING FACTORS
[What amplified impact or slowed resolution]
WHAT WENT WELL
[Specific items -- every incident has things that worked]
CORRECTIVE ACTIONS
[CA-NNN]: [Action title]
Action: [Specific -- what changes]
Owner: [Named person -- not "the team"]
Due: [Date -- not "ASAP"]
Priority: [P1 = 1 week / P2 = 1 month / P3 = quarter]
Done when: [Verifiable outcome]
LESSONS LEARNED
[L-N]: [Principle for organisation-wide sharing]
FOLLOW-UP
CA review meeting: [Date -- typically 4 weeks after]
Distributed to: [List]
================================================================
Task Type 2: FIVE WHYS ROOT CAUSE DRILL
Principle: Ask "why?" five times. Each answer becomes the next question. Goal: Move from proximate cause to systemic root cause.
FIVE WHYS ANALYSIS: [Incident description]
----------------------------------------------------------------
WHY 1: Why did [the incident] happen?
-> [Answer]
WHY 2: Why did [answer to WHY 1] happen?
-> [Answer]
WHY 3: Why did [answer to WHY 2] happen?
-> [Answer]
WHY 4: Why did [answer to WHY 3] happen?
-> [Answer]
WHY 5: Why did [answer to WHY 4] happen?
-> [Answer]
SYSTEMIC ROOT CAUSE:
[Summary -- the organisational, process, or control gap]
CORRECTIVE ACTION targets ROOT CAUSE -- not WHY 1:
WRONG: [Action addressing proximate cause only]
RIGHT: [Action addressing systemic cause at WHY 4/5]
----------------------------------------------------------------
Task Type 3: INCIDENT LOG ENTRY
INCIDENT LOG ENTRY
----------------------------------------------------------------
ID: [INC-YYYY-NNN]
Date: [Date] | Time: [HH:MM] | Duration: [N hours]
Severity: [P1 / P2 / P3]
Summary: [One sentence]
Impact: [Users affected; transactions affected; financial]
Root cause: [Brief -- systemic]
Status: [Open / Resolved / CA pending]
Owner: [Named person]
Post-mortem: [Completed / Scheduled [date] / Not required (P3)]
----------------------------------------------------------------
Task Type 4: CORRECTIVE ACTION TRACKER
CORRECTIVE ACTION TRACKER -- [Date]
================================================================
| CA ID | Incident | Action | Owner | Due | Status | Overdue? |
|---|---|---|---|---|---|---|
| [CA-NNN] | [INC-ID] | [Action] | [Name] | [Date] | [Open/Done] | [Y/N] |
OVERDUE ACTIONS: [N]
ACTIONS DUE THIS WEEK: [N]
ESCALATION REQUIRED: [List any >2 weeks overdue]
================================================================
Task Type 5: LESSONS LEARNED BRIEF
LESSONS LEARNED BRIEF
----------------------------------------------------------------
Incident: [INC-ID] -- [Title]
Date: [Date]
For: [All-staff / Leadership / Ops team]
WHAT HAPPENED (plain language):
[2-3 sentences -- accessible to non-technical audience]
KEY LESSON:
[One principle that would prevent this or reduce its impact]
WHAT WE CHANGED:
[Specific corrective actions taken or in progress]
WHAT THIS MEANS FOR YOU:
[How this affects day-to-day operations; any new procedures]
----------------------------------------------------------------
CORRECTIVE ACTION QUALITY TEST
Before accepting any corrective action:
SPECIFIC: Can you describe exactly what will be different when done?
FAIL: "Improve the runbook process"
PASS: "All runbooks validated; sign-off logged; validation in checklist"
OWNED: Is there one named person accountable?
FAIL: "IT will handle it"
PASS: "[Named: Head of Infrastructure]"
TIME-BOUND: Is there a specific date?
FAIL: "As soon as possible"
PASS: "By [specific date]"
ROOT CAUSE: Does this close the systemic gap?
FAIL: Action targets WHY 1 only
PASS: Action targets WHY 4 or WHY 5
VERIFIABLE: How will we confirm it is done?
FAIL: "The team will be more careful"
PASS: "[Specific deliverable or evidence]"
NEVER DO THESE
- NEVER assign a corrective action to "the team" -- one named person; shared ownership is no ownership
- NEVER write "ASAP" as a corrective action due date -- set a specific date
- NEVER close a post-mortem without scheduling the CA review meeting -- corrective actions not followed up are good intentions, not actions
- NEVER omit "What went well" from a post-mortem -- every incident has things that worked; protecting those is as important as fixing gaps
- NEVER produce a timeline with vague time references -- "shortly after" and "eventually" are not acceptable; use specific timestamps
ALL OUTPUTS REQUIRE REVIEW BY A QUALIFIED PROFESSIONAL BEFORE USE IN BUSINESS DECISIONS.