Blog post

Why I Hate the Term GRC

By Paul Proctor | May 13, 2013 | 10 Comments

GRC is the most worthless term in the vendor lexicon. Vendors use it to describe whatever they are selling and Gartner clients use it to describe whatever problem they have. For seven years I have battled this monolithic term and I fear I’m losing the battle. The alternative is to try to bring some clarity to its usage by defining some boundaries.

Here is our published GRC definition, which I like:

GRC is neither a project nor a technology, but a corporate objective for improving governance through more-effective compliance and a better understanding of the impact of risk on business performance. Governance, risk management and compliance have many valid definitions. The following definitions illustrate the relationship of the three terms and serve for Gartner’s GRC research:

  • Governance — The process by which policy is set and decision making is executed.
  • Risk Management —The process for preventing an unacceptable level of uncertainty in business objectives with a balance of avoidance through reconsideration of objectives, mitigation through the application of controls, transfer through insurance and acceptance through governance mechanisms. It is also the process to ensure that important business processes and behaviors remain within the tolerances associated with policies and decisions set through the governance process.
  • 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.

When it comes to GRC technologies we have to define some boundaries or essentially GRC is everything and everything is GRC. Well who does that help?

  • It’s important to know which projects, workflows, and processes are in scope before starting a tool acquisition process.
  • GRC tools are good for automating EXISTING, good processes
  • Buying a tool to solve your GRC problems is putting the cart before the horse. For example, if you don’t have risk assessment, buying a GRC tool is not going to give it to you.

IT GRC is a particularly complicated issue so we have recently evolved our definition to help Gartner clients match their need to product capabilities. My next blog post will address this issue in a couple of days.

Follow me on Twitter (@peproctor)

Comments are closed


  • I’m not going to argue with your definition of GRC, because that would be quiviling. And I very much agree with your first bullet point.

    However, your second bullet point is off the mark and simply not true.

    I’ve been in this industry and watched as people didn’t know how to write policies, to writing policies by the book (think Charles Cresson Wood and other materials like that), to routing policies through the organization using simplistic tools, to finally having integrated policy and procedure management that ties those policies and procedures directly to laws and regulations.

    GRC tools integrating with data sets did that. Companies couldn’t do that on their own. I’ve watched companies go from *bad* processes to *very good* processes becuase they found a GRC tool that took them to places they didn’t know they could go.

    Yes, you *do* have to know what you want to do (roughly), or what you’d love to achieve (roughly) before selecting a tool. But to say that you have to have good processes in place *first* is a bit absurd.

    Here’s a concrete example.

    How would you, without a tool and an integrated data set, have a process to compile and harmonize 100 Authority Documents into a cohesive set of Controls that you could then turn into your Compliance Documentation set of policies, standards and procedures? You couldn’t.

    How could you, without a tool and an integrated data set, have a process to link Secure Configuration Management Controls found in any given set of Authority Documents (FedRamp, DISA, HIPAA, PCI, EMV, etc.) to a methodology to check for proper configuration? Each and every Microsoft server based organization will have over 500 checks to perform *on each server*. You *couldn’t* have a process for that without an integrated data set performing through both an IT GRC tool and a Secure Configuration Management (SCM) tool talking together.

    My argument is this: Good GRC tools (and their extensions in SIEM, SCM, etc.) – using an integrated and harmonized data set – work together to provide processes and procedures that an organization might not even be able to dream about.

  • I couldn’t agree more – the acronym GRC means little to many organisations; it’s most commonly used as a label for a category of software, and is not a generally recognised business term.

    At a recent European information technology press conference, I took the opportunity to poll the 30 or so IT journalists in the audience to see if they had heard of the term. Being generous, I would say that only 30% responded with a yes. If that’s the IT media, I think we can safely assume the level of understanding across business managers and leaders (IT and non-IT) will be far less.

    The Gartner definitions for Risk and Compliance make perfect sense, possibly because these are commonly practiced business disciplines in their own right, which are clearly specified in standards and methodologies, and often performed by people whose roles have similar titles.

    Governance on the other hand is not as clearly defined – perhaps because governance is more nebulous, without a clear definition or dedicated practitioners. I feel the current Gartner definition is a little too simplistic. Governance is not limited to the setting and following of rules (policies), it must also encompass the practices and processes by which a company is directed and controlled, to ensure that all stakeholder interests are protected.

    Governance is a process (or series of processes) that ensures organisations:
    a) Implement the necessary management processes to maintain control, such as risk management, policy management, compliance management, process auditing, strategic planning, incident response, supplier management etc (plan and implement); and

    b) Operate them to the required/agreed levels of efficacy and maturity (review and improve).

    I look forward to your next blog entry.

    Richard Hibbert
    CEO SureCloud

  • Every organization does GRC whether they call it GRC, something else, or do not have a name for it. Every organization has Governance, Risk Management, and Compliance.

    The question is – how mature are your GRC practices and processes? Are they the ad hoc – fly by the seat of our pants approach? Are they integrated and structured with proper accountability/oversight?

    GRC is part of what businesses do. From a technology perspective it is a whole market of technologies and not about a single product. You do not just buy GRC. There are a lot of aspects to it. A lot of sectors and sub-sectors.

    My point of view, Gartner is adding to the confusion. For one thing – why does Gartner have to create its own definition of GRC? It is ridiculous having so many GRC definitions and that is what confuses organizations. All these definitions come from different analysts and consulting firms – as well as solution providers.

    There is only one definition of GRC that has in a standard/framework that has gone through a vetting process including open comment period. That is the OCEG definition.

    Paul – simply put, what is wrong with the OCEG definition that makes it so you would not want to use it?

    The OCEG definition is “GRC is a capability to reliably achieve objectives [GOVERNANCE] while addressing uncertainty [RISK MANAGEMENT] and acting with integrity [COMPLIANCE].”

    Each of the sections is built out to further to cover everything needed. But that is the core.

  • On buying a GRC tool v/s establishing processes first, I will have to agree with Dorian. GRC tools will help you define your processes and make them efficient quicker than spending years and thousands of consulting dollars to make them perfect. Especially with small GRC team and limited budgets, you would be better of looking at tools and best practices provided by those tools to get going. In any process, there is always room for improvement so its better to start with a baseline recommendation and then keep refining them to meet your business objectives.

  • Paul Proctor says:


    I assume, by “my second bullet point” you disagree that GRC is good at automating existing process. I stand by this and I think your examples are excellent for backing up my position. You are correct that GRC is very good at tying policy and procedure to regulation, however how do you do this if you have NO policy?

    I get a lot of calls from clients who have no risk management process at all and they want to know the best tool to buy to start doing risk management. Seriously? You can’t buy risk management, policies, vendor management, or 90% of the other things that GRC automates out of the box.

    Your statement (“Good GRC tools…provide processes and procedures that an organization might not even be able to dream about”) is wrong about “providing”. The “make it possible” to reach levels of maturity that are not possible without automation, but they don’t “provide” much of anything to someone who starts with nothing.

  • Paul Proctor says:


    GRC has become a global mess of a term. The journalists must have been pure IT (cloud, infrastructure, etc), and not risk and security savvy. I think your comments on governance are spot on. There are limitations to every definition. My short definition of governance is very simply “how do we make our decisions?”

  • Paul Proctor says:


    GRC is the ultimate fuzzy term and it makes me laugh. It is whatever you want it to be.

    Our clients expect us to explain things to them that are fuzzy, so we developed a definition based on their needs as they explain them to us in our interactions. Why didn’t we just adopt the OCEG definition? In addition to “our clients don’t pay us to just point to sources they can google for free,” it is a terrible definition that provides zero clarity.

    How on earth is addressing an external mandate like HIPAA “acting with integrity?”

    Here’s the short form definition I use:

    Governance is how we make our decisions, risk management is how we prioritize, and compliance is ensuring we address internal and external mandates.

  • Paul Proctor says:


    I couldn’t disagree more. You’re perpetuating the myth that GRC tools will create good policies, give you good risk management, and establish the ability to make better decisions.

    You are putting the cart in front of the horse.

    I’ve got too many clients trying to buy GRC out of a box, and this is not productive for them, so I will not support it.

  • Dan French says:

    Great blog post and good discussion.

    I agree with Paul’s basic premise that the term ‘GRC’ means everything and nothing.

    I admire the work that OCEG does, but I have trouble with their definition of ‘GRC’ because to describe to a CFO, for example, a capability to “reliably achieve objectives while addressing uncertainty and acting with integrity”, sounds a lot like ‘running the business’. I believe this is a real challenge for us all. Too broad a definition and the term loses precision and even causes confusion. Too narrow, and we lose much of the business relevance.

    Best regards

    Dan French
    CEO, Consider

  • Paul,

    I don’t disagree that GRC is good at automating existing processes. My only point was that GRC can deliver to clients processes that they never had dreamt of.

    You don’t have to have any processes for reporting on regulations complied with for configuration management before you purchase a GRC tool and SCM tool that speak to each other and provide that service/process.