Root Cause Analysis: A Practical Guide
What is a Root Cause Analysis?
Once the fire is out, the ICO is notified (or the breach is logged), and the immediate panic has subsided, it’s time for the most critical part of the process: figuring out why it happened.
A Root Cause Analysis (RCA) is a systematic process used to identify the underlying vulnerability or breakdown that allowed the data breach to occur. It’s not about pointing fingers or finding a scapegoat; it’s about finding the flaw in the system so you can fix it for good.
Why do we need to do an RCA?
There is no explicit part of the UK GDPR that demands you perform a root cause analysis. From Articles 32 and 33(5), you could imply a requirement to understand a breach to prevent it from happening again. This is in line with the Accountability principle, but also demonstrates good practice.
The RCA Process
There are multiple methods for organisations to use when undertaking a RCA.
I like to surmise the process in the same way my History teacher taught me to write essays. You must keep going until you can no longer answer the question: But why (did this happen)?
For example, let’s say an employee emailed a spreadsheet containing client financial data to the wrong external recipient.
Why?
Because they typed the wrong name into the “To” bar and hit send without checking.
Why?
Because Outlook auto-completed a similar name and they were rushing to meet a deadline.
Why?
Because the team is heavily understaffed this month, and they lack a delayed-sending rule on external emails.
Why? Because we haven’t implemented technical email safety controls or reviewed team capacity.
The Root Cause
A lack of technical preventative controls (like external email warnings or delay rules) combined with operational strain and a lack of data-handling awareness training.
Documenting the RCA
Your RCA should be documented right alongside your initial breach log. When wrapping up your analysis, ensure you have recorded:
- What physically happened (e.g., malicious phishing link clicked, physical file lost).
- The systemic vulnerability (e.g., outdated firewall, lack of employee training, flawed business process).
- What actions are being taken? This might include:
- Updating company policies or technical configurations.
- Rolling out targeted training for the specific department involved.
- Upgrading software or security protocols.
You should ensure that a review into the efficacy of these actions takes place after 30 to 60 days to ensure the fix actually works.
