I was recently asked a question by a customer that took me by surprise. Instead of asking what manual processes could be automated, this customer wanted to know which ones I would not recommend automating.
I decided to take some time for this response as I didn’t think it should be given lightly.
After some consideration, I thought it is possible to split these processes into two categories. First, processes that are too risky to be automated. If errors were to occur the damages would be too important. And second, processes that can be automated provided there is thorough testing of the principle and its application.
I’d like to share my thoughts with you in more detail and I hope this will resonate with your own experience.
Manual processes that I would not suggest automating
Public reports that include a risk section, such as the company’s annual reports, are meant for shareholders and business partners, but competitors and malicious people will also have access to them. Automating the disclosure of your risk register, alongside the mitigation strategy (and its effectiveness) and potential incidents might give away more information than you intended. Let’s assume that “deficient cyber security” is one of your risks, do you really want to let cyber criminals know what you have done to mitigate it and the fact that you are not fully there yet?
As I already discussed in a previous post (The Use of Risk Scenario Analysis) I am a believer in using scenarios for decision making. But that’s precisely the point: a scenario needs to be leveraged for decisions, not used as an easy option to assess your risks automatically for you. A human review is essential, at least to confirm that the assumptions used are still correct within the business context.
Risk management is iterative: once you’ve identified, assessed, mitigated your risks and you are in a monitoring phase, you do have to trigger a new cycle to ensure that the risk definition and its level still reflect its current status. Launching a new cycle at the company level without previously reviewing the framework, applicable policies or even risk appetite and thresholds would, in my mind, introduce too many threats that can derail the whole process. Before starting a new cycle, I would recommend reviewing the past one to see what can be improved and, only if all is still relevant and that no new activities have been carried out by the business, triggering a new identification and analysis phase.
Manual processes that can be automated with caution and testing first
Risk-based auditing is a tremendously efficient approach. Audit teams can focus on important risks and therefore actively participate in the protection of the company’s assets. I have already seen examples where the audit planning is entirely automated by leveraging heatmaps and control ratings. I personally believe this is dangerous as it means some risky areas, that are not reflected in the heatmaps for different reasons, will not be highlighted and will be missed. I think this approach can be relevant for some very specific topic-orientated audits, but should not be generalized.
Executives have long required simple to read consolidated reports that they could get in real time. Risk management tools have this great capacity, as all the information is held in one database and can be consolidated at any level. But, before pushing it to your executives, I would strongly suggest testing this thoroughly to ensure that all relevant information is displayed and that the executive can indeed act on this report. I would also suggest reviewing the consolidation mechanism regularly to ensure it is still relevant and that you are not adding apples and pears.
I am sure that there are other processes that could fall into any of these categories, but I wanted to share with you the ones I considered most important. Would you agree with this segregation? Would you add any others?
What more on risk management best practices? See Why I Love Risk Management … And You Should Too.
I look forward to reading your thoughts and comments either to this blog or on Twitter (@TFrenehard)!