Part of Data Security Standard 5 - Process reviews
Root cause analysis (5.1.1)
Root cause analysis should be conducted routinely following a data security or protection incident, with findings acted upon.
During an ongoing incident, the top priority of your team should be resolving the problem and ensuring user data is secured and the integrity preserved. However, after the incident there will be an opportunity to investigate and review how the incident occurred.
The investigation should be thorough to determine what the root cause of the incident was and any contributory factors. This should form part of your data security and protection incident management procedure.
You should document your Investigations of root causes of issues, along with the corresponding action plans and lessons learnt. You should also keep a record of evidence associated with the agreed actions being taken to prevent similar incidents from occurring.
| Process | Issue | Lesson learnt | Action |
|---|---|---|---|
| Starter user account creation | Commonly guessable passwords being used on account setup change process | There is no audit mechanism in place to check password strengths | Check other user password events such as password reset on accounts to check if guessable passwords are used |
| Job description review | Some contractors job descriptions do not contain data security and protection clauses | No process in place to ensure appropriate data security and protection requirements clauses are in place for contractor job descriptions |
Review other contractor organisations in use to see if they comply and their job descriptions include data security and protection clauses Work with Human Resources or Procurement colleagues to ensure process in place to ensure that any new contractors always have data protection clauses in their job descriptions |
| Firewall Review Check | On a policy based firewall “any any” rules exist | To review firewall boundary devices (especially legacy) rule set. (IPS/IDS) and DLP for any insecure rules | Remove any insecure “any any” rules |
Regardless of whether or not an incident has occurred, you should be conducting regular learning activities in the form of process reviews, simulations and business continuity exercises (as discussed in Data Security Standard 7 - Continuity planning).
Learning from your mistakes, in particular technical ones, should allow you to look at your systems, processes or controls to ensure the same incident does not occur again, or reduce the likelihood that it will.
The difference between actions and lessons learnt
Actions tend to exist in relation to one process whereas lessons learnt can have a broader applicability. A lesson learned can have multiple actions associated with it.
Last edited: 12 September 2022 3:55 pm