Root cause, and making the lesson stick

Why this matters

This is the phase with no urgency, no incident forcing it and no visible reward — and the only one that makes the next incident less likely.

It is also where most organisations quietly fail. The systems are back, the meetings stop, everybody is exhausted and behind on their other work, and the review either does not happen or happens as a meeting with no output. The incident has then been paid for in full and bought nothing.

The exam asks about the post-incident phase and about root cause specifically. The job asks whether anything actually changed.

The lesson

Root cause versus proximate cause

The distinction that decides whether the review produces anything useful.

The proximate cause is the thing that immediately preceded the incident: the user clicked the link, the unpatched server was exploited, the credential was reused.

The root cause is the condition that allowed the proximate cause to matter — and there is usually more than one.

Worked example. An intrusion begins when an employee opens an attachment.

• Proximate cause: the employee opened it.
• Deeper: the attachment reached the inbox, so mail filtering did not catch it. Macros were permitted to run. The workstation allowed the payload to execute. Nothing alerted on the process chain. The account had access to more than the role required. Credential theft from memory was possible. Lateral movement was unrestricted. And nothing detected any of it for eleven days.

Nine conditions, each an independent control that could have stopped or bounded the intrusion, and not one of them is "the employee". That is the usual shape: incidents happen where several controls are weak at once, so "root cause: user error" is almost always a review that stopped at the first answer.

The habits that get you past it:

• Keep asking why. Five is the usual prescription; the count matters less than not stopping at the first satisfying answer.
• Ask why at each layer rather than following a single chain, since controls are layered and several failed.
• Include the detection failure as its own root cause. "Why did this run for eleven days?" is a separate question from "how did they get in?", and it is frequently the more actionable one.
• Be suspicious of a root cause that names a person. Human error is a constant of the environment, like weather. A system that fails when someone makes an ordinary mistake has a design problem, and "be more careful" is not a control.

Blameless post-incident review

The practice that makes accurate review possible, and it is a practical mechanism rather than a courtesy.

The premise: people give you the truth when telling it is safe, and hide or soften it when it is not. An organisation that punishes the person who clicked gets fewer reports next time, later reports, and reviews where nobody says the useful thing.

What blameless means in operation:

• Assume everyone acted reasonably given what they knew at the time. Almost always true, and it redirects the question from "who was careless" to "what made that the reasonable action".
• Focus on conditions, not individuals. Not "the analyst missed the alert" but "the alert was one of four hundred that shift, and there was no way to distinguish it".
• Include the response in scope. What slowed you down? What did you not have? What did you decide late, and why?
• Guard against hindsight bias, which is the hardest part. Knowing the outcome makes the signal look obvious; it was not obvious among everything else happening. Reconstruct what was actually visible at each moment, and lesson 30's timeline is the tool for it.
• Blameless is not consequence-free. Deliberate misconduct is a different matter, handled elsewhere. The blameless stance covers ordinary error, which is what nearly every incident involves.

Run it soon enough that memories are fresh, with the people who were actually there, and with a facilitator who was not central to the response.

Turning findings into detections and controls

Where the review stops being a discussion and becomes work, and the difference between a review and a report.

Every finding should produce something in one of these categories, or be explicitly recorded as accepted:

• A detection. The clearest output. "We could not see credential dumping" becomes a rule, tested per lesson 14, and added to the coverage map from lesson 27. This is the highest-value output of any incident, because the organisation has just been handed a real, confirmed attack path — better threat intelligence than any feed, and specific to your environment.
• A preventive control. Blocking the macro, restricting the protocol, requiring the authentication, segmenting the network.
• A telemetry gap closed. "We could not answer what happened on that host" becomes a log source onboarded or a retention extended. Frequently the single most valuable action and the least exciting.
• A process change. Faster declaration, clearer authority, a playbook for this scenario.
• A preparation item, straight from lesson 29: a contact list, an out-of-band channel, a restore test.
• A vulnerability remediation, fed into Domain 2's process with the exploitation evidence attached — which, as lesson 23 noted, is the argument that makes it move.

Two rules that make these last:

• Each becomes a ticket with an owner and a date, in the same system as other work. A finding in a document is not an action.
• New detections must be tested. An untested rule is a hypothesis, and a review that closes with three untested rules has closed with three hypotheses.

Tracking actions to completion

The step where good reviews die quietly, and the one nobody notices failing.

The pattern is familiar: a thorough review, fifteen sensible actions, genuine intent — and six months later four are done, six are stale, five were never started, and the document is unread. The next incident exploits the same gap and the same finding is written again.

What makes tracking work:

• A single owner per action, a person rather than a team. Actions owned by "Infrastructure" are owned by nobody.
• A real date, agreed by the owner.
• In the normal work system, prioritised against everything else. A separate incident-actions spreadsheet is invisible and therefore optional.
• Fewer, larger actions. Five that will be done beat twenty that will not, and the temptation after a bad incident is to write twenty.
• Reported until closed, at the same forum that heard the incident. Visibility is most of the mechanism.
• Closed on evidence. "Detection deployed" means the rule exists, fires on a test, and someone receives it — exactly the remediation-verification standard from lesson 24, applied to your own commitments.
• Re-opened honestly when a deadline passes, rather than silently extended.

And the check that costs nothing and finds a great deal: before writing this review's findings, read the last one's. A finding that appears twice is not a finding about the incident. It is a finding about the organisation's ability to act on findings, and it should be reported as one — to a level that can do something about it.

Metrics that show whether anything improved

The closing question, and the honest one: is any of this working?

Metrics worth tracking across incidents:

• Time to detect — from first attacker activity (from the timeline, not from the alert) to detection. The measure that best reflects whether Domain 1 is improving.
• Dwell time, the same idea stated as how long they were in.
• Time to contain, and time to eradicate.
• Detection source, tracked over time: internal tooling, internal person, external party. A rising share of external notification is a serious finding, and the metric most organisations do not keep.
• Repeat root causes, per above.
• Post-incident action completion rate, and the age of open actions.
• Coverage improvements: techniques newly detectable, log sources onboarded, restore tests completed.

Reading them honestly requires two caveats that lesson 40 develops:

• Small numbers are noisy. Few organisations have enough incidents for these to be statistics. Treat them as a narrative with dates attached, not a trend line, and resist computing an average over four events.
• Every one of these can be improved by detecting less. Fewer incidents declared, shorter apparent dwell times, better numbers — and a worse security posture. Any metric that can be met by looking away needs a counterweight measuring how hard you are looking.

Which returns the domain to where it started, and to the sentence this course keeps arriving at from different directions. An organisation with no detected incidents and one with no incidents produce identical reports. Only a deliberate test — a hunt, a purple team, an exercise, a restore — tells you which one you are, and the post-incident review is the one moment when you have been handed the answer for free.

Topics this lesson owns

• [x] Root cause versus proximate cause
• [x] Blameless post-incident review
• [x] Turning findings into detections and controls
• [x] Tracking actions to completion
• [x] Metrics that show whether anything improved