GRC Tuesdays: My Pet Peeve: GRC ≠ Access Authorization Management

I confess–that isn’t really me.  However, she represents what I feel like inside when I hear the depth and breadth of disciplines, practices, policies, and tools that make up governance, risk and compliance (GRC) summarized into nothing more than managing user access and segregation of duties.

GRC:  The Domain

First, let’s look at a classic definition.  GRC definitions abound, and there are some good ones out there.  I think OCEG’s definition is one of the better ones:

GRC is the integrated collection of capabilities that enable an organization to reliably achieve objectives while addressing uncertainty and acting with integrity – this is the outcome that we call Principled Performance.

Of course, there are also bad or overly narrow definitions as well.  I won’t embarrass the author or publication, but I think this one totally confuses GRC with software to help support selected aspects of GRC:

GRC is an administrative concept supported by a certain class of software. GRC tools allow users to manage compliance with regulatory standards.

Governance, risk and compliance isn’t about software, and it’s certainly not about just a narrow category of software.  Yet take a look on LinkedIn, for example, and search for people who list GRC experience.  Do you typically see those that have a wide and varied experience in the various capabilities that can lead to achievement of objectives, addressing uncertainty and acting with integrity?  Not really.  Especially within IT circles, GRC is often used to mean experience with managing access authorizations and familiarity with segregation of duties concepts—or, even more narrowly—experience with using software to do so.

Now, I certainly agree that managing access to various systems and applications is important—critical, in fact—to protecting a company’s data, deterring fraud, and ensuring privacy.  And it is one of many disciplines or capabilities involved in GRC, but I wouldn’t personally call it GRC.  Wouldn’t that be like:

• Claiming to be a pilot because you can take off safely?
• Professing to be a medical doctor because you can apply first aid?
• Advertising as a certified public accountant because you can do your own tax return?

GRC Software Solutions

On to my pet peeve, which relates most to the world of SAP GRC solutions (this time, I am talking about software).  We currently have 18 products we sell as part of our SAP GRC and Security (GRC&S) portfolio, and there are a lot of other relevant products in other SAP portfolios.  (Of course, other vendors have their own lists.)  Here are just some of our GRC&S solutions:

• SAP Access Control
• SAP Audit Management
• SAP Business Partner Screening
• SAP Enterprise Threat Detection
• SAP Fraud Management
• SAP Global Trade Services
• SAP Process Control
• SAP Risk Management
• SAP Single Sign-On
• SAP Identity Management

Yet, as I speak to customers, partners, consultants, and even some of our internal people who should know better, the conversation often goes something like this:

Them: “I need some help with XYZ.  We’re using SAP GRC.”

Me:  “Great, what products?”

Them:  “GRC.”

Me:  “Well, SAP GRC isn’t a product.  We have a lot of products that can help support GRC.”

Them:  “Uh, GRC 10.1, I think.  We upgraded from GRC 5.3.”

Me:  “Then you must be talking about SAP Access Control because that’s the only one that had a version 5.3.”

Them:  “Oh yeah, right.  But isn’t AC the same as GRC?”

Even more difficult, however, is when customers are trying to engage a suitable consultant for one or more of our SAP GRC solutions—hence my LinkedIn comment earlier.  They might see many resumes that claim “extensive GRC experience” including “multiple SAP GRC go-lives” yet find they are interviewing someone with SAP Access Control experience.  If that is what they need, great!  If not, they are in for a surprise (hopefully during the interview process, not during the project itself).

Similarly, how many have gone to user conferences and attended a mythical session like “See how our company used SAP GRC to support our global GRC efforts and get a solid ROI in just 4 months” only to find that the company had finally cleaned up their segregation of duties and critical permissions weaknesses?  A worthy goal, to be sure, but not as broad a project as the title might indicate.

The Broader GRC

So what am I suggesting here, now that I’ve aired my pet peeve?  I would just like to see a little more precision in language that reflects an understanding that:

• GRC is much more than access and authorization management
• GRC is much more than software—it’s people, processes, and perhaps technology working together to help the company achieve its objectives while acting responsibly
• And, our SAP GRC solutions are more than SAP Access Control

Thanks for letting me “vent.”  I feel much better now.