Blogger: Trent Henry
Each fall the Security and Risk Management Strategies team gets together for annual planning and brainstorming. These are long days spent in conference rooms, followed by evening vacillation: "should I go exercise, or go to the calorie-laden group dinner?" then email, then repeat the next day.
We always try to create a list of key themes for the research year -- things that are top-of-mind to clients, represent interesting trends for the industry, or are potential market "gotchas." This year we looked at the emerging discussion of "GRC" and scratched out heads. We didn't get it. In fact, we thought the market messaging and product direction(s) were potentially deleterious, so one of our key themes was to debunk the solution space of GRC (that's "Governance, Risk management, and Compliance" in case you were unaware; of course, as further evidence of the meaninglessness of glomming these words together, some vendors use "GRC management," which drops the individual management from risk management. On the other hand, it also implies a such thing as "governance management," which, if not redundant, I don't know what is; but don't get me started down the semantic idiocy path...)
Back to the point: GRC is not a solution, technology, or product category. This sentiment has been echoed the last couple weeks by others in the blogosphere, notably kicked off by Rich Mogul (securosis.com/2008/05/13/grc-is-dead).
Of course, the elements of G, R, C are not dead. Governing, managing risk, and responding to compliance obligations are ongoing and critical organizational tasks. The problem is conflating them into a single term. As Burton Group is inclined to say, GRC is a four-letter word that shouldn't be spoken among polite company. Each function is deserving of its own, complete, and separate word. There's no organization in which compliance activities, risk management, and executive governance are rolled into a single person, group, or tool. No sense creating an acronym that implies it.
This is more than terminological, though. The problem is a vast landscape of vendors touting "GRC" functionality, but whose tools operate at widely varied levels of the solution stack (or, more aptly, at very different levels of organizational reporting). Is a SOX risk register a "GRC" tool? Apparently--particularly if you call it "Enterprise GRC." Is a user provisioning and identity certification solution a "GRC" tool? Yes--it seems--because it has a small stake in validating user management controls. And the list of claims goes on... If everything is "GRC," then nothing is.
What this obscures is the real value that many solutions provide: to map various enterprise requirements (regulations and control standards), test controls for effectiveness, and report gaps or problems that need attending. And it's appropriate that certain tools address the audit community, others the security team, and yet others lower-level technical operations groups. What's inappropriate is to call them all some variation of "GRC."
We've published two reports, a Telebriefing, and we plan to talk at some length about these issues at Catalyst in June (San Diego). We'll be talking realistically about governance functions, the landscape of tools, etc. Our intent is to make clear that many vendor solutions provide value to staff at various levels: just don't go looking for some unifying uber-tool called "GRC."
