Keep asking why until the answer is something you can assign
An illustrative chain from a real pattern we see often. Each step down is a level of causation, and only the last one produces a corrective action worth funding.
This is where most incident reports stop, and why the same thing happens again nine months later.
True, and useless on its own. People will always eventually open something.
Gateway policy permitted the file type, and no detonation was performed before delivery.
The agent was deployed in audit-only mode after a false positive eighteen months earlier, and never switched back.
Temporary exceptions were recorded in a ticket, not in a register with an expiry date and an owner.
This is fixable, assignable, and prevents an entire class of future incidents rather than one.
In practice the chain is rarely linear. Most incidents have two or three causal branches, and the analysis is only finished when each branch reaches something structural.
Four categories, because the cause is almost never only technical
Every incident is examined against all four. An analysis that finds only technology causes has usually stopped early.
Three weeks, then a check at ninety days
Evidence and scope
Logs, forensic artefacts, tickets, change records and configuration state collected while they still exist. Scope and the questions to be answered agreed with you in writing.
Timeline
Every event placed in sequence: what the attacker did, what was logged, what alerted, what a human saw and when anyone acted. The gaps between those four lines are the finding.
Interviews
Blameless conversations with the people involved. Almost every analysis turns on something that was known informally and never recorded anywhere.
Causal analysis
Techniques applied, causal chains followed to structural causes, and each failed control mapped to the specific reason it did not work.
Report and actions
Findings, causal chains, evidence, and a corrective action plan with owners, effort and dates. Presented to your technical team and separately to leadership.
Verification
We come back and check whether the corrective actions were implemented and whether they hold. This is the step most organisations skip and later regret.
What you receive
A written analysis with the causal chains, the evidence behind each one, the control failures mapped individually, and a corrective action plan stating owner, effort, dependency and date for every item. Plus a short version for the board and, where required, a factual account suitable for a regulator or insurer.
What we will not write
“Human error” as a root cause. “Improve security awareness” as a corrective action. A finding that names an individual. Any conclusion the evidence does not support, if the logs were not retained, the report says so rather than guessing.
What sits either side of an analysis
Incident response
Containment first, analysis second. The evidence an RCA needs is preserved during response or not at all.
Compromise assessment
If you suspect something happened but have no confirmed incident, start by establishing whether you are compromised.
Risk assessment
Corrective actions belong in the risk register, or they will be forgotten by the next budget cycle.