.svg)
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.
Now we’ve looked at some of the more traditional forms of automated controls, let’s discuss a new breed of automated controls that should also be considered as part of a controls automation initiative. The use of GRC technologies within organisations, and the rich automated monitoring functionality they provide, has opened up further possibilities and opportunities to implement controls which are out of reach from traditional forms of controls automation. These business rule frameworks/engines provide the ability for organisations to design, build and implement their own business rules to define deficiency criteria which supports their own risk mitigation objectives. The opportunities are endless and controls may be implemented at configuration, master data or transaction-level.
Example: The identification of one-time vendor POs that exceed a specific % of regular purchase orders over a period of time is an example of controls made possible by GRC-enabled technology. These limits can be defined entirely by the customer and allow it to be tailored to their own purchasing policies to ensure adherence. Traditional controls don’t tend to exist for these types of examples, and it would be far too cumbersome to manage manually due to having to pull large volumes of data from several different sources and aggregate amounts over a period of time. But these are the opportunities that functionality within GRC-technologies can provide to organisations, some of which are starting to make use of them.
Another example would be the ability to monitor for unauthorised openings of the production system. Traditional controls allow you to lock down your production environment to enforce a ‘promote to production’ change management approach, but the production client does need to be opened from time to time for legitimate reasons. Using GRC to constantly monitor when this happens provides another layer of control, and allows you to ensure it has been opened in an authorised and controlled manner and spot potential attempts to make unauthorised changes directly in the production environment.
Another element of using GRC-enabled controls is the associated notifications and issue and remediation cycle workflows which accompany them and ensure the relevant individuals are fully integrated in the controls output and the subsequent investigation and remediation of exceptions found. However, due to the fact that some GRC technologies are built primarily for the monitoring and testing of controls, the remediation workflow is really designed to capture issues in the sense that a control is not operating effectively. So if you use the automated monitoring/business rule framework in these GRC-technologies to actually operate these new breed of automated controls, a control issue in this sense is not that the control isn’t working but rather an exception identified by the control completely in line with how the control should operate. This could have the potential to skew controls reporting in a GRC application, particularly if you are using it for both automated controls operation and automated controls monitoring – so this is something of which to be mindful.
