Ben Tomhave

A member of the Gartner Blog Network

Ben Tomhave
Research Director
1 years at Gartner
19 years IT Industry

Ben is conducting research within the Security and Risk Management Strategies team under Gartner for Technical Professionals.

Coverage Areas:

Rebooting the GRC Space

by Ben Tomhave  |  February 4, 2014  |  2 Comments

He’s been talking about it for almost a year now, and this week we are starting to see some of the progress from the effort. For those of you who have followed the GRC (governance, risk management, and compliance) space, you’ll know that it’s a bit of a nightmare. It’s been sub-divided, historically, between “IT GRC” and “EGRC” (“E” being for “enterprise”). There are also a couple other potential categories, like “Legal GRC” and “Financial GRC,” but those have been far less prominent.

The problem, however, is that it’s incredibly difficult to define products under these generic headers, let alone compare and contrast them. Take, for example, our own EGRC Magic Quadrant. It compares companies like SAS and SAP to RSA Archer and MetricStream to a bunch of other companies, all of which have a wide range of functions, use cases, userbases, and so on. Trying to fit vendors into these spaces has been a headache and a half. But, we have an idea for how to fix it…

Under Paul Proctor’s leadership, and described in more detail in his blog post, “Gartner Resets Approach to GRC,” Gartner is setting out to redefine the marketplace. Instead of focusing on functionality, we’re going to try something different: focusing on use cases. What problems are clients trying to solve when they solicit bids from vendors?

To that end, Gartner will be starting with 6 use cases:

  • IT Risk Management (ITRM)
  • Operational risk management (ORM)
  • Audit management.
  • Vendor risk management (VRM)
  • Business continuity management (BCM)
  • Corporate Compliance and Oversight

Read Paul’s blog post for more details on each of these. If you’re a vendor in the space, look for a survey request from Gartner. If you’re a client with interest in these use cases, you will have a potential opportunity to contribute, too.

Overall, this is an exciting development for the GRC space and for Gartner. We hope to finally bring some sensible definition to the market, and to help both clients and vendors start achieving better success. These tools have a lot to offer, but they only work well when the customer knows their use case, and when the vendors are well-matched to those needs.

2 Comments »

Category: Research     Tags: , ,

2 responses so far ↓

  • 1 Chris Grant   February 4, 2014 at 6:04 pm

    No offense, but this seems like common sense to me. As a business, we’re looking to solve a use case, not buy a product. If you’re not looking at buying tools to solve problems/use cases, you’re wasting money on buying products. And I’d bet those products will have limited success in that organization.

    Use cases should drive tool need and tool decisions. Analysis of the market place is like evaluating how effective car companies are by comparing a Toyota Yaris to Chevy Silverado. Yes, they are both cars, but only from the vantage point of people who don’t use either. Someone wanting to buy a class of car like the Yaris is not going to compare it to a Silerado, regardless of what report industry analysts might provide on the merits of each, compared and contrasted. The use cases are far different.

    Glad to see this change, and I think it is going to be far more useful, but it should have been obvious and realized sooner.

    Prior to the current market place for “GRC” products, if you had these categories, you may have only had one or two in each of these, which would have also been less than useful, however it would have been a more accurate view of the players and their capabilities to solve problems (not just compared/contrasted against each other).

    Chris

  • 2 Ben Tomhave   February 4, 2014 at 6:08 pm

    Chris,

    Yes, we feel this is “common sense,” but you have to understand how we got to the current point to realize how things got off-track. We find that RFCs/RFPs often demonstrate and list of random functions without properly articulating a use case, which causes all sorts of problems. It’s been fairly common for an enterprise to buy one of these products without truly understanding why they’re buying it, which inevitably leads to a project failure. The vendors often get blamed for this, even if it was really caused by a lack of good planning ahead of time.

    cheers,

    -ben

Leave a Comment