An incident review is not a chronology with names attached. The audience needs to understand what customers experienced, how the organization learned about it, which decision restored service, what remains uncertain and which controls will prove the fix. The deck should be candid without turning the review into a blame exercise or an engineering appendix.
What you bring
- An incident timeline and customer-impact summary
- A postmortem draft with logs, decisions and action items
- A data-platform or reliability review
How the deck is shaped
- Customer impact and the detection gap
- Timeline, root cause and containment decision
- What worked, what failed and what remains uncertain
- Corrective controls, owners and proof of completion
Where it stops
- It does not perform forensic analysis or inspect production logs.
- It will not invent a root cause, customer count or financial impact.
- It is not a security, legal or regulatory report.
