I'm sure you've heard the term GRC, and I'm quite sure you know it stands for governance, risk and compliance. What you might not realize is how important it is for all three parts to fit together well, forming one seamless system. Having a GRC framework that demonstrates the relationship among the three parts will help you build much more effective compliance systems.
In this era of heightened security around air travel, a Nigerian terrorist successfully smuggled a liquid explosive onto a flight bound for Detroit on Dec. 25, 2009, and came very close to accomplishing a devastating mission. U.S. Department of Homeland Security chief Janet Napolitano characterized the resulting government response as a success, proclaiming that the system worked. To be fair, she's correct -- but only if you have a very myopic perspective centered on compliance. If the scope of your system includ es mitigating risk, this system did not work at all.
So, let's start from the ground up. In my view, governance, risk and compliance have a hierarchical relationship, with compliance being on the bottom. In short, the goal of compliance is to make sure you're following the rules. When addressing systems of compliance, the assumption should be that you're following the rules, and the focus should be on building architecture that proves it.
First question for a GRC framework: Why am I following the rules?
The compliance architect should constantly ask, "How can I prove we're following this rule?" A robust compliance strategy will prove the rule from more than one angle. Napolitano's statement is obviously framed only from this level. What she claims is that all the proper procedures were followed -- and I'm sure they were -- but there's an obvious problem: The man still got on a plane with explosives.
So compliance is driven from risk. Napolitano is only one high-profile example of a common problem I see in corporate America: Companies follow the rules, but they never take the time to really understand why they're following the rules. The reason for following the rules, or staying in compliance, is to mitigate some risk with an unappealing effect or impact.
So when designing your system of risk, take into consideration how it relates to compliance. When you profile risk (basically an uncertainty), characterize it with a probability, impact and set of probable causes. Using our terrorist example, the risk is that somebody with bad intentions will try to smuggle explosives on the plane. I'm not sure what the probability is, but I'd say given the current climate that it's fairly moderate, and the effect is an explosion with the devastating impact of lost lives.
Because this risk has such a prominent impact, we've come up with rules, or controls, to mitigate this risk. As noted above, a good system of compliance will prove that these rules are being followed. When you elevate your scope from compliance to risk, you have the opportunity to mitigate impacts instead of just following rules, which is much more valuable.
Risk architects should constantly ask themselves, "How can I prevent this from happening?" If starting from compliance, to uncover the risk, the architect will ask, "What risk event is this rule trying to prevent?"
Governance at the top of a GRC framework
At the top of the hierarchy is governance. Governance is about management efficacy. It's the policies and controls that an organization has in place to ensure that its missions and goals are being accomplished. Governance is more similar in form to compliance than risk. They're both about making sure things are done properly. The reasons why they're separated in the GRC framework, however, are in their differences. Governance has more to do with the strategic objectives of the company, whereas compliance has more to do with outside concerns.
Once framed properly and architected as a system, the three layers of a GRC framework dramatically reinforce each individual component.
The relationship that risk has with governance is in the organization's probability of accomplishing its strategic objectives. Risks usually represent uncertain events that can derail the accomplishment of strategic objectives, thereby compromising governance. To uncover risks from governance, the architect will ask, "What can go wrong as we try to accomplish this strategic objective?" To uncover governance from risk, the architect will ask, "What strategic objective does this risk interfere with?"
In the end, the GRC architect will have a complete model to build the processes and data architecture into a complete GRC system. The strategic objectives of the company will spawn a governance process to make sure the objectives are met. These objectives are subject to risks, or uncertain events, that can derail the objectives. To mitigate risk, rules are built and, subsequently, controls are put in place to make sure the rules are being followed.
Your compliance subsystem will provide the evidence that everything is happening as it should. Once framed properly and architected as a system, the three layers of a GRC framework dramatically reinforce each individual component. Overlay this framework on what you have today, and take any measures necessary to bring the three pieces together as a whole. If the plane did blow up, does it really matter that everybody was in compliance with the process?
John Weathington is president and CEO of Excellent Management Systems Inc., a San Francisco-based management consultancy.