Rethinking GRC
2012 marks the 10th anniversary since I first modeled a market for technology, content, and professional services and labeled it GRC. It all started with a vendor briefing with a software firm in which they demonstrated an integrated view of controls, policies, and assessments. A light bulb flashed within my head that there is a strategic approach to business combined with services, content, and technology to service it – organizations could achieve an integrated view of information to assist with Governance, Risk Management, and Compliance (GRC). That was February of 2002 and the GRC market was born.
From the beginning I always stated that GRC was about the business first and technology was a foundation for the business to build upon. It was first and foremost about understanding the business – its strategy, risks, obligations, commitments, objectives – and helping the organization manage risk and compliance in the context of business.
Over the years, GRC has grown in conception and understanding. The best thing to happen to GRC was the development of the OCEG GRC Capability Model, and with that the OCEG definition of GRC:
- GRC is a capability to reliably achieve objectives while addressing uncertainty and acting with integrity.
What has been a disappointment with GRC and needs us to cause some rethinking is our technology approach to GRC. It is impossible to define GRC as a package of software. There is not one vendor that can be your GRC band-aid and solve your problems. GRC is not a commodity that you buy from a technology vendor.
GRC is what is achieved in the business and its operations. To that point we need to rethink our understanding of GRC technology.
This means that we need to think of GRC in the context of business architecture. To achieve good GRC processes in our environment requires and understanding of what the business is about, how it operates, and how it should be monitored and controlled through information and technology.
Rethinking GRC is about taking an enterprise/business architecture approach to understanding the business and how it operates. This includes:
- Strategy architecture. Understanding what the business is about, where it is going, what the goals are. This requires that we understand GRC — and its components of governance, risk management, and compliance – in the context of business performance, strategy, objectives as well as its culture and values.
- Process architecture. Flowing from strategy are the processes that define the business and how it operates. Good GRC is done in the context of the business – the rhythm of the business. GRC technology and processes should be integrated with business processes and systems. We need a firm understanding of how the business operates and how to manage risk, policies, and controls in the context of business operations. GRC requires that we be able to model the organization, its operations, and its processes to understand GRC in context of the business.
- Information architecture. To support business operations and processes, we need a good definition of GRC related information. To define standards/schemas of information for risk, policies, controls and how information flows across the business. What GRC information is needed to make sure that the business is reliably achieving objectives while addressing uncertainty and acting with integrity.
- Technology architecture. Finally, we approach technology. GRC technology needs to be kept in perspective – it is about the business. We need to make sure that the GRC technologies (and I purposely use the plural) integrate with our business operations, systems, and processes. To put GRC before the business is to put the cart before the horse.
What does all of this mean? I will write more on that in the next article. For now, it means we need to take a business approach to GRC and not lead with a technology approach. It means that we should stop thinking that GRC is about one vendor that solves all the business’ problems. It may mean that there is a technology backbone for GRC consolidated to a single vendor, but it most likely means that there will be several vendors that do different parts of GRC well that form a GRC architecture supporting the business, its operations, and its processes.
I look forward to hearing your comments and thoughs on Rethinking GRC . . .