The Technology Side of GRC

Pravin Kothari

We’re finally at the end of this discussion on defining GRC automation.  We discussed mitigation as part of the process automation earlier.

Risk mitigation and remediation are not only an integral part, but also usually the most expensive part of a GRC program as it requires changes in your environment.  Some of these changes may require new processes and even additional people if the process is not automated.  Automation of GRC processes is still relatively new to most companies.  Most companies are still working on front-end process automation.  More mature organizations have started working on back-end automation for mitigation and remediation of issues.  The cost savings from automating the back-end processes can be very significant.

When the risk, gaps and issues have been identified and prioritized, a response is needed to mitigate the risk , this can include requesting an exception, accepting the risk, transferring the risk, providing compensating controls, launching a campaign, etc.  Some of these mitigation actions, e.g. requesting an exception, can trigger their own automated processes.  Remediation is one of the possible mitigation actions.

Remediation actions can be manual, partially automated or fully automated.  Partially automated remediation actions have some parts accomplished with integration and other parts manually executed.  For example, automating ticket integration with Remedy, where appropriate user makes the changes by hand.  The technology here is integration to the help desk of your choice.  Not a trivial task, but not rocket science either.

Certain remediation can be fully automated and it typically involves integration with some sort of management software.  System management software, or the new fancier term “business service automation (BSA)” can apply patches, make configuration or policy changes directly to applications, servers, network and telephony hardware.  These applications are the bread and butter of datacenter operations team.  Security software such as identity management, secured configuration management, data leakage prevention are able to implement access changes via remote requests as well.  Identity management can even reach into ERP applications and implement segregation of duties controls on business transactions. These are the tools of trade for security operations team.  There are a number of new and old technologies that fall into these two categories of system management and security tools, and there is no sense for me to inventory these on this blog.  What is important to note is that these technologies do not fall under the “GRC” management space.  Remember that GRC (capitalized) is a well defined application category, where as “governance, risk and compliance” is used loosely to describe a whole slew of technology solutions that have something to do with compliance and risk…. [The abuse of the term GRC by vendors is a whole topic of its own.  I’ll reserve that for venting some other day J]  System management and security management software are necessary in their own right, solving operational and compliance problems.  The key is for GRC applications to leverage these existing assets and not try to re-invent the wheel by duplicating capabilities already available in the infrastructure.

Whew!  That was a long discussion, longer than I expected, actually.  I hope you found this thread on GRC automation definition useful.