GRC – Governance, Risk Management, Compliance. A typical buzzword, but well established right now. However, the problem of all emerging markets associated with a buzzword arises here as well: There are many different vendors with different types of offerings, all claiming to solve the GRC problem. But: The GRC problem has many facets and is (beyond “we have to manage risk, we have to be compliant”) largely undefined. We’ll publish a report these days on a GRC reference architecture followed by, probably in early November, a market segmentation report, placing vendors in one or more appropriate segments. Like every valid and successful emerging market, GRC will move from a large set of different solutions towards a market with some well defined segments of vendors.
There are the so called "Enterprise GRC" vendors like Mega, OpenPages, or Bwise. But even between these there are significant differences. There are vendors working more at the level of CCM (Continuous Controls Monitoring), including companies like Approva. There are IAM-GRC vendors like Aveksa, BHOLD, Engiweb, Sailpoint, and several others. There are IAM solutions with added GRC capabilities - in the meanthime most of them. There is GRC support in BSM (Business Service Management) applications. And, and, and... I don't want to unveil to much from the upcoming reports which you will find at our website but like to focus on another aspect:Which GRC approach to choose?
First of all, I believe that we have to use the potential of GRC for better interfacing Business and IT. There are business controls, there are IT controls. These have to be mapped. Thus, we should end with solutions which support as well the business as the IT requirements. That will never ever be a single solution, but a combination of some. High level controls and dashboards, CCM approaches and more specific solutions for different groups of IT controls. It should as well be an approach which isn't only "detective" or, more correct, "reactive" but finds the balance between proactive/preventive and reactive/detective.
The big picture is relatively easy to describe, like we have done in our reference architecture.
The way towards that is much more difficult. There are many influencing factors like the industry and size of the organization, the current organizational structure (especially around the responsibility for GRC issues), the process maturity of the organization, the maturity of IT management approaches, and so on. Thus there can be different (and more than one) starting points. But in any case, there should be a well agreed (but coarsely described) "big picture", as the guideline for building a GRC roadmap.
I personally believe that three factors are most important:
- Providing quick wins
- Providing a business view which, from the beginning, starts in integrating with IT - only manual controls are't sufficient, it is always about the appropriate mix of manual and automated controls
- Closing the loop - don't focus only on the reactive part (like with pure "access certification") but start acting on the results, for example by integrating provisioning to fix the detected problems
These are some of the most important criteria to choose solutions in the GRC space.
Have a look at our event website for upcoming events and webinars around GRC.
And, for sure, don't hesitate to ask for our advice on building your GRC "big picture".