Incident Response — Troubleshooting

Evidence was contaminated by an action taken during initial response

If someone rebooted, powered off, or ran remediation commands on a compromised host before evidence was captured, the damage is often partial, not total — volatile evidence (memory contents, active network connections) is likely lost, but disk-based evidence usually survives a reboot (though a reboot can still trigger malware behavior, alter timestamps, or clear some in-memory-only artifacts). The immediate step is documenting exactly what happened, when, and by whom — honestly and completely, in the same timeline discipline covered in the Fundamentals tab — since papering over a evidence-handling mistake is far worse for any later legal/regulatory scrutiny than a documented, acknowledged gap. The longer-term fix is a "hands off" rule built into the runbook itself: no one touches a suspected-compromised system beyond network isolation until forensics has explicitly confirmed evidence capture is complete — this needs to be a clear, memorized rule for anyone who might be first to respond, not something looked up mid-incident under pressure.

Alert fatigue: analysts are missing real incidents among too much noise

If genuine incidents are being missed or caught late, and analysts report the SIEM alert volume feels unmanageable, the root cause is almost always overly broad, poorly-correlated alert rules producing too many low-confidence single-event alerts (covered on the Intermediate tab) rather than analysts being negligent. The fix is a deliberate correlation-rule review: identify the highest-volume, lowest-value alert rules (often discoverable directly from SIEM alert-volume-by-rule reporting) and either tune them to require multiple correlated weak signals before firing, or demote them to a lower-priority queue reviewed on a different cadence rather than treated identically to a high-confidence alert. Alert fatigue is a systemic tuning problem, not an individual analyst attentiveness problem, and treating it as the latter (asking analysts to "just be more careful") doesn't fix the actual root cause.

Backups intended for recovery turn out to also be infected/encrypted

This is one of the more severe discoveries during ransomware recovery specifically — if online, continuously-connected backups were reachable by the same compromised network the ransomware spread across, they may be encrypted or compromised too, not a safe recovery point. Before restoring from any backup, verify its actual integrity and a scan-confirmed clean state, not just its existence — restoring from a backup that's silently also compromised can reintroduce the exact same incident immediately after what looked like a successful recovery. This is the direct, practical argument for maintaining offline or immutable backups (air-gapped, or write-once/immutable storage) as a deliberate architectural decision made before an incident, not a recovery option assumed to exist during one — an organization discovering during an active ransomware incident that all its backups were reachable and therefore compromised has a substantially worse recovery path than one with a verified, isolated offline backup ready.

Escalation broke down — the right people weren't notified in time

If a significant incident's severity was underestimated initially, or the right people (legal, executive leadership, an outside forensics firm) weren't engaged until well into the response, this usually traces back to either an unclear or unmemorized severity/escalation matrix (covered on the Fundamentals tab — a scale that exists on paper but wasn't actually internalized by whoever was first to respond), or a first responder correctly following the matrix but the contact/escalation path itself being stale (an outdated on-call rotation, a legal contact who's left the company). Escalation matrices need to be tested via tabletop exercises regularly, specifically checking that the actual contact information is current and that whoever's on shift genuinely knows the escalation path without having to look it up — a matrix that's correct on paper but untested in practice is a common, real gap that only surfaces during an actual incident, at the worst possible time to discover it.

Post-incident action items were identified but never actually implemented

If a pattern emerges of similar incidents recurring despite prior post-incident reviews identifying the same root causes, the review process itself has a follow-through gap — action items were documented but not tracked to completion with a clear owner and deadline. The fix is treating post-incident action items with the same tracking discipline as any other committed work — assigned to a specific named owner, with a deadline, reviewed at a regular cadence (not just written into a report and never revisited) until actually closed. A security team that produces thorough, honest post-incident reports but has no mechanism holding the resulting action items accountable to completion is functionally in the same position as a team that never did the review at all — the value of a post-incident review is entirely in the follow-through, not the document itself.