Is there value in talking about GRC?
GRC, which stands for “governance, risk management, and compliance”, is a buzzword that is receiving a lot of play. But everybody has a different definition of what it means – what processes and applications are included in GRC.
Personally, I like the definition from the Open Compliance and Ethics Group (www.oceg.org):
“A system of people, processes and technology that enables an organization to:
- understand and prioritize stakeholder expectations;
- set business objectives that are congruent with values and risks;
- achieve objectives while optimizing risk profile and protecting value;
- operate within legal, contractual, internal, social and ethical boundaries;
- provide relevant, reliable and timely information to appropriate stakeholders; and
- enable the measurement of the performance and effectiveness of the system.”
However, this set of processes is so vast it is hard to identify a process or application that is not part of GRC. Even transaction processing applications (such as included in an ERP) include controls used to ensure the integrity of the transactions being processed – and therefore have at least an element of GRC in them.
It is useful for OCEG to gather these processes together and provide guidance on best practices. They take an ethics and compliance perspective, rather than one focused on broader governance and management of the enterprise to achieve short and longer-term goals.
But does it make sense to a business person assessing software to improve governance, risk management, or compliance processes? I am not persuaded that it does.
Is it necessary or even valuable for all the applications supporting GRC processes to be integrated? Is it critical that a vendor supply every part?
Again, the GRC universe is so vast that I doubt that any single vendor will provide a solution for every nook and cranny in my lifetime. The OCEG definition of GRC includes the management of organizational strategies and performance management – perhaps the core of GRC. But very few GRC vendors (only one comes to mind) offers both.
I also am not persuaded that every GRC-enabling application has to be integrated with every other one. For example, I would be very nervous about linking my whistleblower system to anything else – the need to safeguard its confidential information is too great.
So what does this all mean? I believe that there is so much talk about GRC that we can’t ignore it. Instead we need to:
- Recognize there is no common definition of GRC and ask everybody who uses it just what do they mean
- Instead of talking about GRC processes and applications, talk about the real business process problems in the enterprise
- When assessing applications from so-called GRC vendors, realize that each has a different definition of GRC and focus on the real business process needs you have. Don’t allow the fog of GRC to get in the way
- Recognize that the assessments of the market and solutions by analysts like Forrester Research and Gartner are based on their own (different) definitions of GRC. The components they include may not all be as important to you as they have assumed in rating vendors’ solutions
The bottom line, for me, is that we should not allow the buzzword of GRC to divert us from assessing what is needed in our business. Just because somebody includes a functionality in their “GRC platform” does not mean we have to.