In 2008, SAP acquired Business Objects, where I was the VP of Internal Audit and also ran the risk management, Sarbanes-Oxley program, and license compliance. After working on the integration of the new BusinessObjects division into SAP for most of the year, I moved to a new role as an evangelist for GRC.
I had never heard of GRC and naturally wanted to understand what it was all about. After all, how can I be an evangelist for something I don’t understand!
Is GRC just a term for a collection of related software products (audit management, policy management, risk management, and compliance management)? Or is it a term used to describe how to run the business better?
Why talk about GRC instead of ERM or compliance?
What’s the big deal, the reason for talking up GRC?
Initially I heard that:
We need to manage the cost of compliance. Compliance requirements are getting more and more complex, with overlapping requirements, fragmented organizations managing them, and escalating costs. OK, I agree — but what has that got to do with GRC? Why isn’t that simply managing compliance more efficiently?
We need enterprise risk management. OK, I agree — but what’s the difference between ERM and GRC?
We need to integrate risk management with the ability to test and evaluate the controls that manage risk. OK, I agree — but when you look at the risk management standards, they include the identification and assessment of the related controls. Why talk about GRC instead of ERM?
I was confused. I was starting to think that the talk about GRC was hype and we should instead be talking about addressing the failures in governance, in risk management, and in compliance.
Then I ran across the OCEG definition of GRC. Now I am starting to see what this is about. Here’s my take on the "good" and the "bad" of GRC.
1. GRC is not about technology, it’s a way of looking at how you direct and manage the organization to optimize value, considering risk, and remaining in compliance — very much a business perspective: what I like to call “Best Run GRC Processes.”
2. The set of processes that make up GRC includes the elements of governance, risk management (which includes controls), and compliance. But the concept that is GRC is more about optimizing the relationship between these elements than about optimizing them individually. It’s about what Michael Rasmussen called “harmony.”
Michael said, in his comment on my earlier post:
“GRC, simply put, is to provide collaboration between [the] silos of governance, risk, and compliance. It is to get different business roles to share information and work in harmony. Harmony is a good metaphor, we do not want discord where the different parts of the organization are going down different roads and not working together. We also do not want everyone singing the melody as different roles (such as risk, audit, [and] compliance) have their different and unique purposes.”
Why is harmony so critical?
Governance activities, such as the setting of strategy and management of performance, are likely to fail if the consideration of risk is not embedded in the strategy-setting process, if risks to the strategies are not identified and managed, and if strategies are not changed in response to changes in risk levels.
The setting and management of strategies is also unlikely to be effective if compliance requirements are overlooked, inadequate resources are allocated to ensuring compliance, and compliance-related risks are not monitored.
Risk management only adds the necessary value if the risks being managed include those critical to organizational objectives and strategies.
One element of an effective risk management is effective oversight of the risk management process by the board. Another is oversight of management’s attitude to risk: it’s willingness to pursue and take risk, and it’s tolerance for risk.
When managers evaluate performance, they should be considering not only financial and operational metrics, but risk indicators as well. Kaplan has asserted that the balanced scorecard should include reports on risk, as managing risk is an essential component of effective management of the business.
3. GRC is also about addressing the issue of fragmentation, even within a single component of GRC. Consider:
A typical enterprise of any size has seven different organizations performing risk assessments and managing risk. How do you get an enterprise view, so the board can manage risk across the business, when you have seven different reports, using different evaluation criteria, and different language?
Compliance within most organizations is fractured, with overlapping responsibilities, gaps, and rampant inefficiency — with separate processes and systems that do essentially the same thing.
4. Finally, GRC is about the need for what Carole Switzer calls “Principled Performance.” Organizations need to consider the ethical environment and the expectations of the society within which they operate. Optimizing profits for the shareholders at the same time as you are building a reputation as a ruthless operator that doesn’t care about the environment, your workers, or the community is not a recipe for long-term success
5. The OCEG definition is not universally recognized. Last year, at a GRC Summit in Boston, I heard 22 different definitions of GRC. Unfortunately, it appeared as if each vendor or consultant was defining GRC to suit the capabilities of their offering. That behavior reinforces the impression that GRC is all "hype."
6. GRC processes include just about every activity involved in directing and managing the organization. So any product that supports any single component (or more) could be called a GRC solution.
In January, I did a quick internet search of vendors who describe themselves as leading GRC vendors:
Vendor A has: risk management, (manual) control testing and assessment, policy management, loss and incident reporting, and some degree of compliance management. (There are many specialized aspects to compliance management, and nobody covers them completely in detail).
Vendor B: risk management, quality management, corporate social responsibility, and certain compliance functionalities.
Vendor C: risk management, internal audit management, and some compliance management.
Vendor D: risk management, internal audit management, some compliance management, and document management.
Vendor E: risk management and control self-assessment.
Vendor F: management of spreadsheets.
Vendor G: risk management, internal audit management, manual and automated controls testing, and trade compliance.
Vendor H: risk management, financial controls management, and internal audit management.
Vendor I: risk management and some compliance management.
Vendor J: risk and control self-assessment, internal audit management, event and loss management, and issues and action plan management.
Vendor K: risk management, performance management, and internal audit management.
Vendor L: controls management for SOX, control self-assessment, management of SOX testing.
Vendor M: document management, and monitoring of certain IT controls.
When there is so much variety of "GRC solution," that tends to say (IMHO) that there is no such thing as a "GRC solution." It reinforces the belief that there is no business value in GRC and the term is just a way for vendors to hype their product.
This confusion is increased when you have terms like:
7. In my opinion, strategy is the core of GRC. After all that is what you are setting, identifying risks to, and trying to achieve. Yet, very few so-called GRC solutions (and none of the above) include any strategy management functionality!
8. My impression is that most of the marketing for "GRC solutions" has been based on the technology or service offered rather than on the true needs of the customer. After all, I believe that there is no such thing as a single GRC process and that talking about “optimizing GRC” is nonsense. Companies should understand their business problems, including the lack of harmony and the extent of fragmentation, and address them rather than some mythical beast called GRC.
9. Too few companies have products that address "harmony" between governance and risk management (such as integrating strategy management and risk management). Some address "fragmentation," but only within a limited number of processes within GRC; I am not persuaded that a product that addresses fragmentation in risk management is a GRC rather than a risk management product.
10. When vendors talk about the value of GRC, they typically talk about the value of ERM and/or the value of integrated compliance. That is talk about the value of the component(s), not the value that is derived from GRC. These are not arguments for a GRC solution: They are arguments for risk management or compliance solutions — which coincidentally may be what they offer.
11. Too much hype about GRC does detract, as commentators to the previous post have pointed out, from the ability of risk practitioners to get management attention and dollars for implementing risk management. The same may apply with compliance professionals, whose business needs for software are saddled with additional "GRC" requirements.
12. Also hyped, this time as GRC convergence or as addressing the need for harmony, is the ability of some "GRC platforms" to integrate multiple GRC functionalities, such as risk and audit management, in a single technology. My problem is that this leads to optimizing the technology for these limited applications rather than optimizing the IT infrastructure as a whole. The need to integrate risk management with the ERP, enabling automated risk monitoring, is ignored.
So, there is good and bad — IMHO. If I ruled the world, everybody would use the OCEG definition and think and talk in business terms.
But, we are saddled with the misuse and abuse of the term — what CFO.com called “the academic definition of the word ’mess.’”
So, my perhaps quixotic quest is to persuade people to either use the OCEG definition or at least insist on an explanation of what people mean by GRC — and then focus on solving their business problems instead of trying to “do GRC.”
Where do you stand?
Do you agree with this, from Michael Rasmussen's site?:
GRC is a federation of business roles and processes – the corporate secretary, legal, risk, audit, compliance, IT, ethics, finance, line of business, and others – working together in a common framework, collaboration, and architecture to achieve agility, effectiveness, and efficiency across the organization.
GRC is a three-legged stool: governance, risk, and compliance are all necessary to effectively manage and steer the organization.
In summary — good governance can only be achieved through diligent risk and compliance management. In today’s business environment, ignoring a federated view of GRC results in business processes, partners, employees, and systems that behave like leaves blowing in the wind. GRC aligns these to be more efficient and managable. Inefficiencies, errors, and potential risks can be identified, averted, or contained, reducing exposure of the organization and ultimately creating better business performance.
Is There Value in Talking About GRC?
Is There Value in Talking About GRC? – II
Risk and Strategy
Goldman Sachs’ 10 Principles of Effective Risk Oversight
Another Rant on the Misuse and Abuse of “GRC”
GRC vs. “gRc:” A Chat With Business Finance’s Eric Krell
In the Land of GRC, Who Is the Sane Person?
GRC – an Academic Definition of the Word “Mess”
Selecting the Right GRC Solution for Your Organization
Governance: the Overlooked Part of GRC – Contributions Welcome
How Is GRC Different From Effective Management?
Perhaps I Am Naive, but Really!