I recently read an article, “The Transformative Power of Cognitive GRC,” from the Open Compliance and Ethics Group (OCEG). The OCEG is a global, nonprofit think tank that claims to have invented GRC, and develops standards and other resources. They have a lot of good content if you’re planning to deploy an enterprise GRC.
In this article, I find it interesting that the proponents of eGRCs continue with the “you ain’t seen nothing yet” perspective… or “we’re just gonna add one more widget,” or “one more integration or one more capability and we’ll have a wonder tool that will do everything!”
The primary problem with these approaches is that they want to boil the ocean.
We’re talking about enterprise GRCs here, not IT GRCs, to be clear… When you look at the “governance” part of GRC, it can typically include all aspects of a business. Therefore, all data become subject to some level of analysis and correlation. I’ll argue that there are probably unknown gems in those data…. But at the same time, they will most likely not yield proportional improvements in risk or compliance regimes. This is another attempt to push the boundaries of GRCs – one ring to rule tem all, indeed.
I’m a proponent of applying many of the same techniques used in big data analytics to security and risk, but models continue to be a challenge because the threats evolve faster than the models can be implemented. It’s getting close however…
I see this latest quest to add AI to an already complex tool as a continuation of the problem with enterprise GRCs… they are too big, try to do too much, and yield questionable value based on their implementation and maintenance costs. But it’s like using a password or deploying a firewall in your network… you need them, but they really don’t do much anymore by themselves. Even if the technology is perfect and someone makes the über GRC, you still have to deal with people and processes…. Conflicting interests and goals and methods within a large organization will always make deploying an eGRC a huge orchestration that ends with frustrated users, because the watered down amalgam of controls and workflows and reports will cater to the lowest common denominator – it’ll meet all requirements, but satisfy no one. Not even factoring on the negative inertia of politics, data fiefdoms, etc. eGRCs are their own worst enemy.
This is why products that differentiate themselves by doing one or two things very, very well will always succeed. Focus on the needs of a specific group with simplified screens and workflows, provide the ability to ingest open standards content, and report or export in open standards content, and you have a product that can be deployed faster than an eGRC, but show tangible ROI well before an eGRC can even get past the architectural design phase at a big organization.