Root cause analysis — SY0-701
Master the Security+ SY0-701 concept of root cause analysis in security operations: what it is, how it differs from remediation, and where candidates go wrong.
WHAT IT IS
Root cause analysis (RCA) is a principle-based, systems approach for the identification of underlying causes associated with a particular set of risks. (NIST SP 800-30 Rev. 1 / SP 800-39, via CSRC Glossary.)
The key word is underlying. RCA does not stop at the visible failure; it works backward through contributing factors until it reaches the condition that, if removed or changed, would prevent recurrence.
Mental model
Think of RCA as answering a chain of "why" questions after an incident closes:
Each arrow represents a "why" question. RCA ends when you reach a cause you can act on to prevent the same chain from recurring — not just the one you can contain quickly.
When to use it
RCA is a post-incident activity, performed after containment and eradication are complete. It is easy to confuse with adjacent activities that share the same timeline.
| Activity | Question it answers | When it happens |
|---|---|---|
| Incident response | "How do we stop the harm?" | During the incident |
| Root cause analysis | "What underlying condition enabled this?" | After containment |
| Remediation | "How do we eliminate that vulnerability or threat?" | After RCA identifies the target |
| Risk assessment | "What is the likelihood and impact of future harm?" | Ongoing; informed by RCA findings |
Incident response is defined by NIST as "the remediation or mitigation of violations of security policies and recommended practices" (NIST SP 800-61r3). RCA is distinct: it is not a mitigation action but an analytical process aimed at the underlying causes.
Remediation is defined as "the neutralization or elimination of a vulnerability or the likelihood of its exploitation" (NIST SP 800-216). Remediation follows RCA — you cannot remediate the right thing until RCA has identified it.
COMMON MISCONCEPTION
Candidates confuse RCA with the containment or eradication steps of incident response.
Patching a vulnerable system, resetting compromised credentials, or reimaging a host are response actions. They address the immediate threat but do not constitute RCA. NIST defines a vulnerability as "a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source" (FIPS 200). A patch eliminates one vulnerability instance; RCA examines why that vulnerability existed undetected — for example, a gap in the patch management process, a misconfigured scan policy, or an undocumented system.
Similarly, RCA is not the same as identifying the threat source. A threat source is "the intent and method targeted at the intentional exploitation of a vulnerability, or a situation and method that may accidentally trigger a vulnerability" (FIPS 200). Attributing an attack to a specific threat source is a forensic finding; RCA focuses on the internal systemic conditions that made exploitation possible, regardless of who the threat source was.
How it shows up on the exam
Exam questions targeting this concept generally measure whether candidates can distinguish the analytical phase (RCA) from the action phases (incident response, remediation) and from related but distinct processes (risk assessment, threat hunting).
Signal phrases to recognize:
- "After the incident was contained…" — sets the stage for a post-incident activity; RCA is the likely correct answer when the question asks what the team should do to prevent recurrence.
- "Determine why the breach occurred" / "identify the underlying condition" — language pointing toward analysis, not containment.
- "Lessons learned" / "prevent future occurrences" — outputs of RCA; distinguish from "restore operations" (response) or "patch the system" (remediation).
A common misconception exploited here is that fixing a problem and understanding why it happened are the same step. They are not: NIST's risk assessment framework (SP 800-30 Rev. 1) places identification of underlying causes as analytically prior to selecting and implementing controls. Candidates who conflate the two will mismatch the activity to the phase.
Related concepts
- Incident Response Process — the structured set of actions RCA follows; understanding its phases clarifies where RCA fits.
- Threat Hunting — a proactive search for threats that may inform RCA findings but is not the same as post-incident causal analysis.
- Digital Forensics — the evidence-collection discipline that supplies the factual record RCA reasons from.
Sources
Every claim on this page traces to the public exam blueprint and official documentation: