# 7.1 Post Incident Review and Timeline

# Goals

The post-incident review creates a clear record of what happened during the incident.

The goal is not to blame people. The goal is to understand the timeline, decisions, actions, delays, gaps, and outcomes so the company can improve.

A good review answers:

What happened?
When did it happen?
How was it detected?
Who was involved?
What systems, accounts, data, vendors, or business processes were affected?
What actions were taken?
What worked?
What slowed the response?
What still needs follow-up?

The timeline should be factual. Do not fill gaps with guesses. If something is unknown, mark it as unknown.

# Step 1: Assign a Review Owner

Assign one person to coordinate the post-incident review.

This may be the incident response lead, security owner, IT lead, MSP contact, compliance owner, or operations manager.

The review owner is responsible for collecting records, building the timeline, scheduling the review meeting, documenting findings, and preparing the handoff into improvement actions.

# Step 2: Collect the Incident Records

Gather the records created during Detect, Respond, and Recover.

Include:

Incident record
Detection notes
Employee reports
Alert records
Log extracts
Email evidence
Screenshots
Ticket records
Containment action log
Communication log
Vendor or MSP notes
Insurance, legal, or compliance notes
Recovery records
Validation evidence
Leadership decisions
Open risks and exceptions

Do not rely only on memory. The review should be based on records wherever possible.

# Step 3: Build the Incident Timeline

Create a timeline from the earliest known sign of the incident through final recovery.

Include:

When the incident may have started
When it was first detected
Who reported it
When triage began
When the incident was classified
When leadership was notified
When containment started
When attacker access was interrupted
When evidence was preserved
When external support was contacted
When eradication began
When recovery began
When systems were restored
When business operations resumed
When the incident was closed or conditionally closed

Use exact timestamps where available. Use approximate times only when exact times are not available.

# Step 4: Identify Key Decision Points

Record the major decisions made during the incident.

Examples include:

Decision to activate the response process
Decision to disable accounts
Decision to isolate devices
Decision to pause payments
Decision to contact cyber insurance
Decision to contact legal counsel
Decision to notify customers or vendors
Decision to rebuild instead of clean a system
Decision to restore from a specific backup
Decision to return a system to normal use
Decision to accept a temporary risk

For each decision, record who made it, when it was made, what information was available, and what action followed.

# Step 5: Review Detection and Reporting

Determine how the incident was first noticed.

Was it detected by an employee, security tool, MSP, vendor, customer, bank, insurer, external party, or attacker message?

Review whether detection happened early enough.

Ask:

Was the right alert enabled?
Did the alert go to the right person?
Was the report reviewed quickly?
Did employees know where to report?
Were there earlier warning signs that were missed?
Were logs available when needed?

This helps determine whether the Detect section needs improvement.

# Step 6: Review Response and Recovery Actions

Review what happened after detection.

Focus on whether the company acted in a controlled and timely way.

Ask:

Was the incident owner clear?
Was evidence preserved?
Was severity classified correctly?
Were containment actions taken quickly enough?
Did communication stay controlled?
Were vendors or external responders contacted at the right time?
Was eradication completed before recovery?
Were backups usable?
Were restored systems validated?
Were business owners involved before normal operations resumed?

This helps determine whether the Respond and Recover sections worked as intended.

# Step 7: Identify Delays, Confusion, and Missing Information

Look for places where the response slowed down or became unclear.

Common issues include:

No clear owner
Old contact list
Missing logs
Alerts sent to the wrong inbox
Delayed employee reporting
Unclear escalation path
Unclear authority to disable systems
Vendor support delay
No backup owner available
Unknown system dependencies
Incomplete asset inventory
No customer communication process
No recovery priority list
No validation checklist

These findings should become improvement actions.

# Step 8: Record Business Impact

Document how the incident affected the business.

Include:

Downtime
Lost productivity
Delayed orders
Delayed payments
Customer impact
Vendor impact
Employee impact
Data exposure
Fraud attempts or losses
Recovery costs
External support costs
Legal, insurance, or compliance involvement
Reputation or relationship impact
Manual workarounds used

This helps leadership understand the real cost of the incident and justify improvements.

# Step 9: Create the Review Summary

Create a short factual summary.

Include:

Incident name or ID
Date range
How it was detected
Systems, accounts, data, or processes affected
Initial severity
Final severity
Containment summary
Recovery summary
Business impact
What worked well
What did not work well
Open risks
Recommended next review areas

The summary should be clear enough for leadership to understand without reading every technical note.

# Step 10: Prepare for Root Cause and Control Failure Analysis

The post-incident timeline should feed directly into the next Review subsection.

Before moving on, confirm that the company has enough information to analyze why the incident happened and what controls failed.

If the timeline still has major gaps, assign follow-up work.

Do not move straight to improvement actions before understanding the sequence of events.

# Timeline Template

Use a simple timeline with these fields:

Incident ID
Date and time
Event or action
Detection source
Person or team involved
System, account, data, or process affected
Evidence source
Decision made
Action taken
Result
Open question
Follow-up owner

# Review Meeting Agenda

Use a short meeting structure:

Confirm the purpose is learning and improvement, not blame.
Review the incident timeline.
Confirm what is known, suspected, and unknown.
Review detection and reporting.
Review triage, containment, communication, eradication, and recovery.
Identify delays, gaps, and unclear ownership.
Confirm business impact.
Assign follow-up questions.

Move confirmed findings into root cause and control failure analysis.

# Helpful Tools and Supporting Infrastructure

Helpful tools include:

Ticketing system for incident records and action tracking
Case management system for security incident documentation
Shared document repository for timelines and evidence
Project board for follow-up tasks
Log management or SIEM tool for event review
Endpoint response tool for device investigation records
Cloud or SaaS audit logs for account and data activity
Spreadsheet or database for the incident timeline
Encrypted notes platform for sensitive review notes

The tool choice matters less than having one controlled place where the timeline, evidence, decisions, and follow-up items are stored.

# Expected Outputs from This Section

At the end of this section, the company should have:

A review owner assigned.
Incident records collected.
A factual incident timeline created.
Major decisions documented.
Detection and reporting reviewed.
Response and recovery actions reviewed.
Delays and missing information identified.
Business impact recorded.
A post-incident review summary completed.
Open questions assigned.
A clear handoff into root cause and control failure analysis.

# Practical Rule

The company cannot improve what it does not understand.

A company should leave this section able to say:

“We know what happened, when it happened, who acted, what decisions were made, where the response slowed down, and what needs deeper analysis.”

That is the post-incident review and timeline.