The requirements for a GRC integration
September 28, 2015 by
Filed under: Governance, Risk and Compliance
The abstract language on how to integrate GRC initiatives is quite complex and lengthy. There is an overwhelming amount of notes, blogs and reports on the benefits of integrated GRC, mostly from professionals in the industry who have an interest in the integration but not having done the integration first hand. It is very interesting to note that very few individuals talk about what actually needs to be done.
Integration is an activity, something that requires planning, preparation and execution, something that doesn't come out of thin air. As a professional in this field, I feel it is important to share with you some of the most important requirements to consider for a successful GRC integration. Yes, indeed the benefits are enormous, and the idea of integration is obvious, but how do you integrate risk management, compliance, audit and IT GRC initiatives (including BCM, 3rd party risk management, fraud detection programs, and etc.)?
Considerations to implement GRC technology
If you are considering to implement GRC technology to support your GRC integration, listed below are several topics to consider:
Common Organization Structure
If every GRC initiative uses its own structure, it will be very difficult to share information and will prove to be impossible to aggregate data. This however, does not mean that everyone will be using the same structure. You need to clearly define the relations between your business unit structures, legal entities, locations and whatever other org-structures you need. Without a clear view on your organization, forget the idea of GRC integration or sharing information across GRC initiatives.
Common Risk Language
First of all, everybody should use the same definitions across the board. For example, a risk owner should have the same meaning in Operational Risk, Internal Control, IT GRC, Audit, and in the various compliance programs (including BCM, 3rd party risk management, etc.). This does not mean the risks are all the same, but the language is the same. If this isn't the case, sharing information across initiatives or rolling up information will be time consuming, labor intensive and prove to be unsuccessful in the end.
Common Process & Risk Taxonomy
Ideally, you would be using a common process & risk taxonomy. This means that everybody has the same high-level process structures and is using the same risks. In the previous bullet, I mentioned that it is not necessary to use the same risks. However, in this topic, when you do use the same risks, it becomes much easier to re-use information. Re-using control self-assessment information in Audit is only possible when the controls used by Audit have some relation with the controls used by the business (or are actually the same controls).
There are of course many other factors to think about. If you want to get more information or ideas, take a look at our latest GRC integration webinar. Please remember to take a step-by-step approach on your GRC Journey; Rome wasn't built in a day.