Back to Glossary

RCA

Incident root cause analysis is the evidence-based process of identifying why a security incident occurred, which conditions enabled it, and what changes could reduce the likelihood or impact of a similar incident.

RCA examines technical weaknesses, access decisions, operational processes, and control failures. An incident may have several contributing causes rather than one isolated root cause.

What Is Incident Root Cause Analysis?

Incident root cause analysis goes beyond identifying the malware, compromised account, or vulnerability involved in an incident. It examines how the compromise became possible and why existing safeguards did not prevent, detect, or contain it effectively.

For example, identifying a stolen password explains how an attacker authenticated. It does not explain why the account lacked stronger authentication, retained excessive permissions, or generated no actionable alert.

A useful analysis connects findings to evidence and separates confirmed facts from assumptions.

NIST’s incident response guidance places investigation and improvement within broader cybersecurity risk management.

How Does a Security Incident Investigation Support RCA?

A security incident investigation establishes what happened, which assets were affected, and how the activity developed. RCA uses those findings to examine the conditions that enabled the incident.

The activities overlap. Investigators may identify contributing weaknesses while responders are still containing the threat.

However, containment should not wait for a complete causal explanation. Teams can restrict access or isolate affected systems while continuing to collect and assess evidence.

What Are the Main Steps?

1. Preserve Relevant Evidence

Collect relevant identity, endpoint, network, application, and cloud records. Preserve volatile evidence where appropriate and document collection methods, timestamps, and handling.

Maintain evidence integrity and chain-of-custody records when required. Avoid unnecessary changes that could destroy information needed for the investigation.

2. Build a Supported Timeline

Reconstruct initial access, privilege changes, lateral movement, data access, detection, and response actions.

Account for time zones, clock differences, and missing logs. The first recorded malicious event may not be the attacker’s first action.

3. Identify Causes and Contributing Conditions

Examine the entry point, the weaknesses exploited, and the controls that should have limited the activity.

Ask why those conditions existed. An unpatched server may reflect an incomplete inventory, unclear ownership, or an unresolved maintenance exception.

4. Test the Explanation

Compare the proposed explanation with the available evidence and consider alternatives.

Methods such as the “Five Whys” or a cause-and-effect diagram can structure discussion. They do not prove causation. Record confidence levels and unresolved questions instead of forcing certainty.

5. Assign and Validate Corrective Actions

Give each action an accountable owner, priority, deadline, and verification method.

Installing a patch is one action. Checking whether the same weakness exists elsewhere and improving the process that missed it addresses the wider problem.

What Is an Example of Root Cause Analysis in Cybersecurity?

Consider this hypothetical incident: an attacker uses a former contractor’s account to download customer records.

The investigation confirms that the account remained active after the engagement ended. It also finds broad export permissions and limited monitoring of bulk downloads.

The analysis identifies several contributing conditions:

The offboarding process did not reliably trigger account removal.
No accountable application owner verified deactivation.
Permissions exceeded the contractor’s remaining business need.
Monitoring did not flag the unusual download activity promptly.

Corrective actions could include automated deactivation, verified removal, narrower permissions, and tested detection rules.

“An attacker used valid credentials” describes the access method. RCA explains the failures that allowed that access to remain useful.

How Does RCA Differ From an Incident Postmortem?

An incident postmortem is a broader review of the incident and the organization’s response.

Area	Root Cause Analysis	Incident Postmortem
Main question	Why did the incident occur and develop?	What happened, how did we respond, and what should improve?
Typical focus	Causal factors and enabling conditions	Impact, timeline, coordination, decisions, and lessons
Main output	Supported findings and corrective actions	A documented review and improvement plan

A postmortem may include RCA alongside an assessment of communications, escalation, recovery, and business impact.

What Should an RCA Report Include?

A practical report should document:

Incident scope and business impact.
A timeline linked to supporting evidence.
Confirmed causes and contributing conditions.
Detection and response gaps.
Evidence limitations and unresolved questions.
Corrective actions, owners, and deadlines.
Validation results and remaining risk.

Avoid ending with “human error” as the explanation. Examine the tools, permissions, workload, and procedures surrounding the action. This creates more useful improvements than assigning blame alone.

Frequently Asked Questions

Does Every Incident Have One Root Cause?

No. Several technical and organizational conditions may interact. Documenting multiple causes can be more accurate than selecting a single explanation.