Post-Incident Review

The Problem with Blame

When an incident occurs, the instinct is to find out who made the mistake. The developer who wrote the vulnerable code. The analyst who closed the alert as a false positive. The administrator who did not apply the patch. This instinct is natural but counterproductive.

Blame creates a culture of fear. Analysts hide mistakes instead of reporting them. Developers avoid taking risks. Teams cover up incidents rather than disclosing them. The organization learns nothing, and the same incident happens again.

The Blameless Philosophy

A blameless post-incident review assumes that people make decisions based on the information they had at the time. The analyst who closed the alert as a false positive made a reasonable decision given the context — the alert was noisy, the asset was low-criticality, and there were 50 other alerts in the queue. The problem is not the analyst's decision — it is the system that produced a noisy alert on a low-priority asset without sufficient context.

This is the core insight: incidents are system failures, not individual failures. The system includes processes, tools, training, and culture — not just technology.

How to Run a Blameless Review

1. Set the tone — open the meeting by stating that the review is blameless and the goal is to learn, not to assign fault
2. Focus on decisions, not people — "what information did the analyst have when they made that decision?" not "why did the analyst make that mistake?"
3. Ask "why" five times — drill down to the root cause. "The alert was closed as a false positive" → why? "The alert lacked context" → why? "The SIEM does not enrich with asset criticality" → why? "We never configured asset enrichment" → why? "We did not have an asset inventory" → root cause: no asset inventory process.
4. Document system conditions — "the SIEM lacked asset enrichment" not "the analyst did not check the asset"
5. Make it safe to participate — no retaliation, no performance reviews based on incident participation

When Blame Is Appropriate

Blameless does not mean accountability-free. There are situations where individual action (or inaction) is the root cause:

• Repeated negligence — an analyst who consistently closes alerts without investigation despite training and feedback
• Policy violations — an administrator who bypasses change management to make an unauthorized change
• Malicious intent — an insider who deliberately causes an incident

These are HR matters, not post-incident review matters. The post-incident review focuses on system improvements; HR processes address individual performance and conduct.

The Hindsight Trap

After an incident, it is easy to look at the timeline and say "we should have caught this earlier." But this is hindsight bias — judging past decisions based on information that was only available after the fact. A fair review separates what was known in the moment from what is known now.

Building the Timeline

The incident timeline is a chronological record of events from the attacker's first action through detection, response, and recovery. It has two parallel tracks:

Attacker Timeline

Defender Timeline

The Hindsight Analysis

The hindsight analysis asks: "At each point in the timeline, what did we know, and what could we have known with the tools and processes we had?"

• 09/28 09:42 — the proxy detected the phishing click. Could we have blocked the URL? Only if the URL was in the threat intelligence feed. It was not — it was a newly registered domain. Gap: no real-time URL analysis.
• 09/28 09:43 — the VPN login from the Netherlands. Could we have detected this as suspicious? Only if we had impossible travel detection. We did not. Gap: no impossible travel detection rule.
• 09/28 10:30 — the scheduled task creation. Could we have detected this as malicious? Only if we had a baseline of normal scheduled task activity. We did not. Gap: no scheduled task baseline.
• 09/30 08:15 — the ransomware alert. This was detected correctly and escalated within 5 minutes. No gap — this worked as designed.

The hindsight analysis reveals the specific detection gaps that allowed the attacker to operate undetected for 46 hours. These gaps become action items.

Timeline Sources

A complete timeline requires correlating multiple data sources:

• Email gateway logs — phishing email delivery and click tracking
• Proxy logs — URL access and credential entry
• VPN logs — authentication and source IP
• EDR telemetry — process creation, file access, registry modifications
• SIEM alerts — detection and escalation timestamps
• Case management — response actions and timestamps
• Network logs — lateral movement and data exfiltration

The timeline is only as complete as the available logs. Missing logs are themselves findings — if a critical log source was unavailable, that is a gap to address.

The Review Is Worthless Without Action

A post-incident review that produces a document and no changes is a waste of time. The value of the review is in the action items — specific, measurable improvements with owners and due dates that address the root causes identified during the review.

Action Item Criteria

Every action item must be:

1. Specific — "implement impossible travel detection" not "improve detection"
2. Measurable — "create a detection rule that alerts when a user logs in from two countries within 1 hour" — you can verify this was done
3. Owned — assigned to a specific person or team, not "the SOC" or "the security team"
4. Dated — has a due date, not "as soon as possible" or "next quarter"
5. Root-cause focused — addresses the underlying condition, not the symptom

Action Item Examples

From the ransomware incident review:

Tracking and Accountability

Action items must be tracked to completion. A tracking system (Jira, ServiceNow, or a simple spreadsheet) records:

• Status — not started, in progress, completed, blocked
• Progress updates — weekly status from the owner
• Completion verification — evidence that the action item was actually implemented
• Overdue alerts — automatic notification when a due date passes

The SOC manager reviews action item status weekly. Overdue items are escalated. Completed items are verified — "implement impossible travel detection" is not complete until the rule is deployed, tested, and generating alerts.

Measuring Improvement

The post-incident review should produce measurable improvements. Track these metrics before and after the action items are completed:

• Mean Time to Detect (MTTD) — did it decrease?
• Mean Time to Respond (MTTR) — did it decrease?
• Detection coverage — did the number of ATT&CK techniques with detection increase?
• False positive rate — did it decrease?
• Analyst training hours — did they increase?

If the action items are completed but the metrics do not improve, the action items did not address the real root cause. This is valuable information — it means the review needs to go deeper.

When to Conduct Reviews

Post-incident reviews should be conducted for:

• All confirmed incidents — regardless of severity
• Near-misses — attacks that were blocked but could have succeeded
• Tabletop exercises — simulated incidents that reveal process gaps
• Significant false positives — alerts that consumed significant analyst time

The review should be conducted within one week of incident resolution, while the details are fresh. Delayed reviews lose accuracy as memories fade and context is lost.

The Review Document

The post-incident review document includes:

1. Executive summary — one paragraph describing the incident and its impact
2. Timeline — attacker and defender timelines
3. Root cause analysis — the system conditions that allowed the incident
4. What worked — detections, tools, and processes that performed well
5. What did not work — gaps and failures
6. Action items — specific improvements with owners and due dates
7. Metrics — before and after measurements
8. Lessons learned — key takeaways for the organization

The document is shared with the SOC team, SOC manager, and CISO. It may also be shared with external parties (regulators, customers) if required by regulation or contract.