About BWise

Blog

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.

Tags: GRC

More Information

What is GRC?

Read the definition of Governance, Risk and Compliance


Gartner ORM report

Nasdaq's BWise has been positioned as a Leader in Gartner's Magic Quadrant for Operational Risk Management Report, 2015. 


Forrester report

Forrester positioned Nasdaq BWise as a Leader in New Report, The Forrester Wave™: Governance, Risk, And Compliance Platforms, Q1 2016.


Why BWise

Download the brochure: Three Key Reasons why Hundreds of Customers Rely on Nasdaq BWise.

Scroll up