Too many GRCs out there

One issue when dealing with GRC (Governance, Risk Management, Compliance) is that there is no single person which is responsible within organizations. And there is a simple reason for that: There are far too many GRCs out there. Vendors provide completely different offerings using the same acronym. That's not new, but in the case of GRC, there is even more uncertainty raised than usual in the IT industry.

From my perspective, the solutions might be segmented into four layers:

The so called "Enterprise GRC" which should be better named "Business GRC" or something because the other technologies are as well around the "Enterprise" but sometimes more focused on IT. Vendors in that space are, amongst others, companies like OpenPages, Bwise, Mega. The focus is on business risks and business controls, a high level view and frequently mainly on manual controls.
The layer which is best described with the term "Continuous Controls Monitoring", which is about looking at specific IT systems and issues from a business perspective. Order processes, delivery status, and such things. Typically there is a mix of automated and manual controls, and some systems focus more on specific enterprise applications (billing,...), whilst others focus more on the consistency of the entire process. Vendors here are, amongst others, companies like SAP (Process Control, Risk Control) and Oracle, mainly for their environments, and such ones like Approva.
The layer which I'd call "specific/specialized GRCs", amongst which IAM-GRC solutions (sometimes called "access governance") and SIEM solutions are the most popular ones, even while I'd add several service management tools as well as long as they focus on service fulfillment and the service management process itself. These tools provide much more depth on specific controls, typically only a small subset of all IT controls. IAM-GRC for example focuses on roundabout 4 of 210 COBIT controls, the ones around identity and access. However, the level of automation is significantly higher and controls are much more specific. In each of the segments here we have a lot of vendors.
System-level tools around operations management, system-level auditing, integration of system-level logs and that stuff - tools which really do a deep dive into the access controls of file servers and shares and other aspects.

With a big picture like that, it becomes obvious, that we have several elements within a GRC strategy. Business and IT have to work closely together to define what is needed in which area and how these tools interfere and how they have to be integrated. With this view, the need for a single person as responsible one for GRC diminishes. There are at least two, one at the business and one at the IT level. And there are even more for different "operational" tools at the lower levels.

If companies have defined their big pictures, it is easier for them to identify which tools they need to implement it. And it is easier for vendors to identify the persons to speak with.

More important from my analyst perspective is the first aspect: Companies which don't have a clearly defined strategy on GRC will most likely end up with a mix of tools, non-integrated, not always providing the required features. Thus: A GRC roadmap and a GRC architectural blueprint are mandatory.

More about the system-level aspects might be heared (for the ones who read this soon) at our webinar today. A replay will be available soon.

Even more information about this topic and especially the IAM-GRC aspects (Access Governance) will be available at the Kuppinger Cole Virtual Conference on this topic December 8th to 9th. Registration for that conference is free.