What is root cause analysis?
Root cause analysis (RCA) is a structured look at why an incident or failure happened, carried past the obvious answer to the condition underneath it. The immediate cause of a breach might be an unpatched server. The root cause might be that nobody owned that server, so it never appeared in the patching schedule. Patching the server closes one hole; fixing the ownership gap closes the whole class of holes. RCA usually happens after recovery, as part of post-incident activity, and its findings feed the post-incident report.
Common RCA techniques
- Five whys: start from the problem and keep asking why, taking each answer as the next question, until the answer is something the organization can change. Five is a rule of thumb, not a requirement.
- Fishbone (Ishikawa) diagram: the problem sits at the head, and possible causes branch off under categories such as people, process, technology and environment. It helps when several factors contributed.
- Timeline analysis: rebuild the order of events from logs and interviews to see where prevention or detection could have happened.
- Fault tree analysis: work down from the failure through the combinations of conditions that could have produced it.
Example: five whys for an exposed storage bucket
- Why was customer data exposed? A cloud storage bucket allowed public reads.
- Why was it public? An engineer applied a public access policy while testing a feature and never removed it.
- Why wasn't the change caught? The account had no posture monitoring, so nothing alerted on a public bucket.
- Why was there no monitoring? A project team had created the account outside the standard cloud account process.
- Why was that possible? Nothing forced new accounts through the process that applies baseline guardrails, such as blocking public storage access by default.
The engineer's change is the immediate cause and the missing monitoring is a contributing factor. The root cause is that cloud accounts could be created without baseline guardrails. Corrective actions come from every level: remove the public policy, turn on monitoring, block public storage access across the organization and require every new account to start from the standard baseline.
Doing RCA well
Keep it blameless. Human error is a symptom to explain, not a conclusion: if one person's mistake could expose customer data, the question is why the system let a single mistake do that. Work from evidence such as logs and timelines rather than memory, expect more than one root cause in a complex incident, and give every corrective action an owner and a due date. Check later that the actions were completed; an RCA whose fixes never happen changes nothing.
RCA vs. lessons learned vs. forensics
- Digital forensics, during the investigation phase, establishes what happened, with evidence that can withstand scrutiny.
- Lessons learned is the post-incident meeting that reviews how the response went and what to change in the process.
- Root cause analysis explains why the incident was possible at all and what change would prevent a repeat.
Root cause analysis on the CompTIA Security+ exam
On SY0-801, root cause analysis is part of the post-incident phase of incident response in objective 4.7, alongside the lessons-learned meeting and post-incident reporting (PIR), an acronym new to the SY0-801 list. A scenario that keeps asking why until it reaches an underlying process failure, or that asks how to keep the same incident from happening again, points to RCA. Distractors include a tabletop exercise, which rehearses an imagined incident in advance; threat hunting, which searches for attackers that have not been detected; and lessons learned, which reviews the response rather than the cause. RCA also appears in IT problem management, where it targets recurring outages.