Answer yes if your organisation completed a root cause analysis for all security incidents that are reported, and implements any lessons learnt after each analysis has been completed. Please provide a template root cause analysis document (as a PDF file) as evidence.
Root cause analysis is the final phase of incident response and should be conducted after (or alongside) identification, containment, control and recovery.
It helps you to understand why something happened and what action you need to take to prevent something similar happening again in future.
The key to root cause analysis is to ask what exactly happened and why did it happen?
For example, a security incident involving an exploit of a known vulnerability on one of your systems would cause you to look at your patch management, which may cause you to look at your asset management, which may cause you to look at your service introduction or change management etc.
A root cause analysis for this example incident might go something like:
Repeatedly asking 'why' in this way can help you understand the root causes which led to the incident and make the changes required to prevent them from happening again in future. In this example, you may choose to review and improve your service introduction process, to run regular discovery scans looking for unapproved software, to improve security awareness with senior staff members etc.
An incident may have several contributing factors, all of which could warrant remedial action. Once you have conducted your root cause analysis, you should prioritise, plan and execute any remedial actions.
If you would like to contribute to this article or provide feedback, please email knowledge@riskledger.com. Contributors will be recognised on our contributors page.