In my last blog on the subject of “The Importance of Governance in the GRC Implementation”, I briefly touched on the importance defining a Vision, or rather, setting standards for a GRC implementation. I felt I needed to dive into these a little more because having solid parameters around which the GRC program is built is efficient, establishes key decisions up front, and eliminates ambiguity for the delivery teams going into the effort. 
The steps I mentioned in the last blog were:
- Define common roles and responsibilities;
- Define common reporting; and
- Make sure it is enterprise focused rather than siloed.
Let’s take a look and each of these.
Common metrics and scales – one of the first clients I worked with had very decentralized and siloed compliance functions. Their goal was to consolidate all areas under one system/tool so as to drive toward Enterprise Compliance Management. However, each compliance area used a different scale and definition for Risk and impact ratings. The first compliance group that implemented the GRC software dictated the metrics, scales, and related definitions for interpretation. As other areas came to the table they could not reconcile nor agree with the configuration of the system and therefore adoption of the new system halted.
Common roles and responsibilities – business roles are usually defined for record ownership and/or workflow processing. From application to application there needs to be a common taxonomy for user roles. If a “Policy Manager” is used in the policy application then “Policy Owner” should not be used in the change request application. While this sounds like a no brainer for software design I can’t stress how difficult it can be to align these roles and their taxonomy, especially if there are different teams developing for different business areas. A lack of commonality in role taxonomy across applications leads to user confusion as to their responsibilities and results in poor accountability.
Common Reporting – The purpose of implementing a GRC system and collecting tons of data is to derive intelligence for making business decisions. However, many times reporting seems to be an afterthought. Since they aren’t properly planned, when reports are finally addressed there’s usually no common approach to formatting, data elements, or coloring of dashboard indicators. One report will show green for a statistic while another will show yellow for the same metric. This leads to confusing results and inaccurate decision making.
Enterprise focused – everything that goes into the build of the GRC function should be viewed through an enterprise lens. Much like the first example regarding common metrics and scales there must be a commitment to ensure there are no silos. Each application, process, workflow, report, etc. must support an enterprise view and decisions should be weighed accordingly to this mandate.
The above issues can be avoided by spending time at the beginning of the effort to speak with key stakeholders to identify and document where GRC is performed. Project teams should first determine metrics used, role taxonomy, current reporting, and gaps in processes. All this is used as input to an established governing body that has the authority to agree on the standards and enforce them into production and throughout the life of the project as a guide for future expansion or development. Cential has helped several organizations lay such foundations for their GRC journeys, and we’ve have learned through experience where the pitfalls are. I’m certain we can help you too.
Have a question about your GRC program? Contact us now to discuss how we can help you supercharge your GRC efforts.