Blog

Controls Automation - Monitoring vs. Operation - Part 3

GRC
Controls Automation - Monitoring vs. Operation - Part 3
Marc Jackson
Written By Marc Jackson
written

22 Oct, 2015 — 3 min read

Controls Automation - Monitoring vs. Operation - Part 3

Table of contents

Controls Automation - Monitoring vs. Operation - Part 3
4:54

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

Five-Ways-to-Develop-Your-Corporate-Culture.jpg

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.

Security insights, delivered.

Join 10,000+ risk professionals. Get the latest trends, guides, and case studies sent directly to your inbox.

By subscribing, you agree to our Privacy Policy and provide consent to receive updates.

Related posts

April 15, 2026

Five questions to guide your move to GRC for HANA 1.0

January 07, 2026

SAP Security, GRC, and IAM in 2026: What's coming and what does it mean for you?

December 22, 2025

SAP GRC 2026: Your questions answered