incident

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.