I have yet to implement a GRC solution without hearing the line “But Our Program is Different”, referring to a department’s need for an exception to how the rest of the organization manages a foundational process or defines a key term (e.g., risk assessments, issue management, etc.).  If not properly managed, the statement can send an implementation into a tailspin, consuming time, resources, and jeopardizing an enterprise implementation. Early in my career, as an in-house GRC practitioner, these scenarios would create stress and add hours onto my day as I worked towards convincing leadership of the need for standardization or coming up with an acceptable compromise. However, as I have come to discover, these scenarios occur frequently in implementations and do not need to create the panic that seems to follow them. Over several years of implementing enterprise level solutions, I developed a series of questions to help frame the discussion around variations and whether exceptions should be built into a GRC solution.

1. What is driving the need for the variation?

The first step in any variation request is to understand what is specifically being requested and what is driving the request. Does it require a workflow change? Additional values in a field? Conditional layouts? Complex calculations? While many variations can be accommodated through very simple configuration, some can both add weeks of additional configuration and testing up front, and increase the required effort to maintain long term. Understanding the need and the amount of effort to implement and maintain helps guide the rest of the discussion.

2. What is driving the need for the variation or what is the impact to the group requesting the exception?

Is the variation required by corporate policy? By regulation? Industry best practice? Or would rejecting the variation have a significant negative impact on the requesting group’s process or reporting? By asking the requesting group to articulate the impact of not having the variation, you require them to evaluate their own processes to understand if the change would simply require them to adjust their business process or would failing to implement the variation truly have a negative impact on their process. In my experience, it is a good way of rooting out personal preferences versus meaningful variations that would benefit the requesting group. 

3. How would accepting the variation impact key enterprise metrics?

Worded a different way, would the variation impact global reporting needs of leadership that would materially impact their understanding of the state of risk or compliance at the organization? If the answer is that there is no impact, then the request needs only to be evaluated from the implementation difficulty lens. However, if the variation has a material impact on enterprise metrics, then the level of impact should be defined and questions 2 and 4 need to be closely scrutinized to see if a compromise can be accomplished.

4. Can an alignment be accommodated through the use of calculations or other reporting mechanisms?

In instances where enterprise reporting would be negatively impacted and the requesting group would be adversely impacted by not accepting the variation, I look to see if an accommodation could be accomplished through building calculations into the tool or through reporting mechanisms. This often requires process discussions and alignment, but typically a workable solution can be developed for all parties.

The ultimate determination to implement or not implement a variation needs to be a decision by the organization, but by framing the request using these four questions, an informed decision can be reached by involved the parties. If you have an established governance process, the questions can be incorporated into how you evaluate requests, or even used more informally as you are gathering initial requirements for an implementation.

Have a question about accommodating variations in your GRC program?  Contact us to discuss how we can help you with your GRC efforts.