I’ve been involved in some discussions recently around GRC that remind me about the arguments around KM — as to whether it is a valid term or not. The antagonists argue that GRC does more harm than good. They argue that the term creates market confusion, that the vendors that claim to offer GRC solutions don’t actually do so, and that you can’t actually do GRC.
They shout to kill GRC — which elicits a roar from the crowd which is fed up with vendor TLA-ism. No one asks why the term exists in the first place — it just represents a lot of nasty hard work and vendor hype — the mob roars, “Kill GRC.” It’s fun bloodsport.
Years ago I heard the same arguments around knowledge management, to the detriment of many organizations who could benefit from a sound KM strategy — a strategic approach to managing all the information and technologies that support critical business decisions. The argument then was that vendors were using the term KM to sell any kind of IT they could — portals, collaboration software, even e-mail. But none of it actually managed knowledge.
In the case of KM, the antagonists discredited the term thoroughly in the IT marketplace — no vendor wants to touch it — though to this day “knowledge management” remains on the top search terms of IT professionals. The sad situation is though that professionals have no good architectural foundations or common frameworks for KM. Along with the discrediting of the term for vendor usage, it became discredited as a strategic framework for managing critical business information.
Rather than discrediting vendor usage of a term — vendors will do what’s expedient for them– we need to understand why these terms like GRC and KM come into being. It’s not a clever marketing ploy by devious vendors — rather it’s the fact that business and IT professionals recognize that there are are some activities within their organizations that seem to have similar characteristics and relationships. While these activities are not common enough to enjoy the same IT solution, they are close enough that organizations that learn to manage the interrelated activities better can differentiate themselves. Common principles and architectures may be applied, even if common solutions cannot. I’ve tried to get a start on this strategic approach with a standard Statement of GRC Principles.
Business leaders who are making critical decisions need to know that risk management professionals and compliance professionals can work together when needed to support the business goals and objectives of the enterprise that those business leaders set through the governance processs. By the way this whole concept of GRC as an inter-related set of activities is reflected well in ISO 38500, Corporate Governance of Information Technology.
How about if for now we see how GRC plays out? Give peace a chance. It seems that the vendors are not hyping it as much as they used to do, and most are using it within context — pointing out more specifically what it is they do within the broad GRC marketplace. Let’s encourage them to keep doing that, and call them on it when they don’t.
Let’s not kill GRC, just yet, okay?
p.s. I’m not keen on overly defining strategic concepts, but here’s a definition of GRC used by Gartner to illustrate the inter-relationships of its components.
Governance, risk management and compliance have many valid definitions. The following definitions illustrate the relationship of the three terms and serve for Gartner’s compliance and risk management research:
- Governance — the process by which policies are set and decision making is executed.
- Risk Management — the process for ensuring that important business processes and behaviors remain within the tolerances associated with those policies and decisions, going beyond which creates an unacceptable potential for loss.
- Compliance — the process of adherence to policies and decisions. Policies can be derived from internal directives, procedures and requirements, or external laws, regulations, standards and agreements.