Following Marc Jackson’s insightful webinar on Controls Automation in the next 3 blogs we will walk you through using Controls Automation, the terminology, the new breed of Controls Automation and Monitoring vs Operation
Monitoring vs. Operation
We talked briefly about the potential controls reporting challenges within a GRC application if you are using it for both control operation and monitoring purposes, so let’s take a closer look at this final element of controls automation – automated controls monitoring. I often find that the terms control operation and controls monitoring are used interchangeably and can be muddled up and confused, mainly because they tend to both be bundled under the umbrella term of automated controls. However you need to be very clear which of the two you are referring to when you embark on your controls automation initiatives as they are very different things, but understanding and appreciating the difference between them is actually quite straightforward.
Automated controls operation is operating a new control without any human intervention (e.g. implementing password parameter settings to password security), whereas automated controls monitoring is the monitoring of a control which is already operating, typically an automated control itself, to ensure it continues to operate as expected going forwards, and this is also performed without any human intervention (e.g. in your deficiency criteria you can state what the password parameter settings should be for it to operate effectively, and if it strays from those expected settings the monitoring rule would automatically detect this and enable the control to be remediated accordingly).
This type of insight into the operating effectiveness of your controls , and the real-time detective reactions to any operating effectiveness issues, means you can strengthen your internal control environment by having a much greater level of assurance and less time during the compliance year when controls are not working.
Business Case for Controls Automation
Now that we’ve covered all of the elements of controls automation, lastly we’re going to take a quick look at the things you need to consider when trying to build a business case for controls automation. The number one priority is to be absolutely clear on what it is that you wish to automate, and avoid talking about it in broad general terms which will only serve to confuse those involved in the process. As we’ve discussed, there are a few different elements of controls automation and not all of them may be relevant for you at a particular point in time (e.g. you may not have a GRC application in place and so would initially like to focus on getting the most out of your in-built application controls before looking to extend the reach to GRC-enabled controls operation and monitoring).
Once you’ve decided on what it is you wish to include you can then evaluate the benefits and costs of each of these elements. Even though the quantitative benefits make the most powerful argument in a business case, the value of the qualitative benefits should not be ignored. These benefits can be looked at in 4 dimensions:
- Cost Reduction – which refers to all direct and indirect cost savings (e.g. lower cost of controls through the reduction of manual controls, lower cost of control investigations through enhanced audit trails etc.)
- Compliance – refers to reduction in compliance costs (e.g. lower audit costs, lower management testing costs, reduction in fines/penalties etc.)
- Risk Reduction – refers to reduction in impact and/or probability of risks (e.g. revenue risk – missed revenue due to missed/under billing etc., cost risk – incurring additional costs due to errors in core processes leading to things such as duplicate payments/overpayments, reputational risk – due to errors in information exchanged with customers, business partners, public etc.)
- Process Improvement – refers to increasing processing speed by automating manual steps and validations (e.g. reduced process cycle time, 100% data validation, enhanced decision-making etc.)
Of course there are also challenges and costs associated with controls automation initiatives and so these also need to be determined and documented in order to provide a comprehensive business case. Such costs include, but are not restricted to, hardware and software costs (although not a factor if not embarking on GRC-enabled controls), cost of implementation depending upon how much is done in-house or with the use of external consultants, training staff on how to use this new technology, as well as the ongoing management and maintenance of such systems, processes and controls.
