To GRC or Not to GRC

You know what’s really, really? Partnering with a company that sells products that essentially compete with each other. Man, is that fun. You sit in the meeting with two different salespeople, and they’re both talking about how great their stuff is, and one does a thing a certain way, and the other does the same thing in a completely different way, and they’re both saying, “this is the RIGHT way.”

Yeah, that’s fun. Cuz then the customer looks at you and asks, “Well, which way IS the right way?”

So do you want the poke in the eye, or the smack in the head?

So this is a common problem with a GRC tool, versus a roles/analytics tool.

GRC is something that’s often built into business apps. It determines in real time if a user is allowed to execute a particular action. It could be granular, such as clicking a button. Or a little higher up, like editing versus only viewing. Or higher yet, such as getting into a module at all.

Because GRC is typically app-specific, it has some limitations:

• ·         The policies are very particular
• ·         It’s tied to the version of the app, so upgrades can be a slight chore
• ·         It’s a silo, meaning not interoperable with other apps
• ·         It’s somewhat impervious to outside metadata or roles

On the other hand, it’s real-time. Can I do this right now? And can I do this inside this app, specifically related to buttons or transactions? It’s very powerful. However, in the past I have described GRC as a beautiful dress that one must be sewn into. It looks gorgeous, just don’t expect to change dresses too often. And by the way, that dress isn’t for every occasion.

A provisioning system, on the other hand, takes a different approach to the same problem. Can this user do that thing over there? Well, if I provision the user to that task or role, then yes, the user can. If I don’t provision the user to it, then no. But that’s in advance, right? And it may or may not be button-specific, meaning ultra-granular, unless I have access to the application entitlements, or I can provision to an pp-specific role. The enforcement is now the function of the app, and provisioning has simply provided the necessary ammo.

Provisioning can also tell you (and the end user) up front if they’re going to get it. In other words, should I bother trying to use it? I’ve been told at the time of request or approval that Permission B that I’ve asked for is in conflict with Permission A that I already have. So now I won’t wait for GRC to tell me later that I’m out of luck.

An extra benefit of the provisioning approach is the ability to perform SoD checks across applications. Because GRC is internal, it can’t do this unless heavily customized. Provisioning is external, and therefore CAN work cross-platform. Analytics can further help you import entitlements, organizational, and people data to help you build those policies across platforms/applications.

So if you need the real-time SoD checks, at the moment of attempted use, then yes, it’s GRC. Otherwise, consider the approach that tells you in advance whether or not somebody can even have the thing before they find out they can’t use it. It’s almost like calling the restaurant ahead of time to find out if they’re crowded, and saving yourself the ride if they are.