Post Incident Review Template
Purpose
Use this template after a significant cybersecurity incident, near miss, fraud attempt, or major security control failure.
The objective is to establish what happened, how well the company responded and recovered, what weaknesses were exposed, and what improvements are required.
The review should focus on learning and control improvement rather than blame.
Incident Information
Incident ID: ____________________
Incident type: ____________________
Incident date: ____________________
Date detected: ____________________
Date contained: ____________________
Recovery completed: ____________________
Review date: ____________________
Review lead: ____________________
Participants: ____________________
1. Incident Summary
Briefly describe what happened:
How was the incident discovered?
What systems, accounts, data, vendors, or business processes were affected?
2. Business Impact
Record the known impact.
Operational disruption:
Financial impact:
Data impact:
Customer impact:
Employee impact:
Legal, regulatory, or contractual impact:
Reputational impact:
3. Incident Timeline
Record the most important events.
Include where relevant:
- Initial compromise
- First attacker activity
- First alert
- First employee report
- Triage
- Containment
- External escalation
- Recovery
- Return to service
- External notifications
4. Detection Review
How was the incident first identified?
- Employee report
- Security alert
- Customer or vendor
- External security provider
- Attacker notification
- Financial institution
- Other: ____________________
Was detection timely?
- Yes / Partially / No / Unknown
What helped detection?
What delayed detection?
Was relevant logging available?
- Yes / Partially / No
Were alerts being monitored?
- Yes / Partially / No
5. Response Review
Assess:
Incident ownership:
- Strong / Acceptable / Weak / Missing
Initial triage:
- Strong / Acceptable / Weak / Missing
Evidence preservation:
- Strong / Acceptable / Weak / Missing
Containment:
- Strong / Acceptable / Weak / Missing
Internal communication:
- Strong / Acceptable / Weak / Missing
External escalation:
- Strong / Acceptable / Weak / Missing
Decision making:
- Strong / Acceptable / Weak / Missing
Documentation:
- Strong / Acceptable / Weak / Missing
What worked well?
What caused delays or confusion?
6. Recovery Review
Assess:
Recovery priorities:
- Strong / Acceptable / Weak / Missing
Backup availability:
- Strong / Acceptable / Weak / Missing
Restore capability:
- Strong / Acceptable / Weak / Missing
Security validation:
- Strong / Acceptable / Weak / Missing
Business validation:
- Strong / Acceptable / Weak / Missing
Communication during recovery:
- Strong / Acceptable / Weak / Missing
What worked well?
What should improve?
7. External Support Review
If an MSP, insurer, legal adviser, incident response provider, cloud provider, bank, or other external party was involved:
Provider: ____________________
Support provided: ____________________
What worked well?
Problems encountered:
Changes required:
8. Key Lessons
What should the company continue doing?
What should the company stop doing?
What should the company start doing?
9. Improvement Actions
Action: ____________________
Owner: ____________________
Priority: ____________________
Due date: ____________________
Evidence required: ____________________
Tracker reference: ____________________
Repeat for each significant improvement.
10. Review Closure
Review completed by: ____________________
Approved by: ____________________
Open actions transferred to Improvement Action Tracker:
- Yes / No
Next leadership review: ____________________
Evidence location: ____________________
Practical Rule
An incident is not fully closed when systems are restored.
It is closed when the company understands what happened and turns the lessons into improvements.