The Black Book of Identity Access Mgmt
This form does not yet contain any fields.
    « The Power is in your hands | Main | A Painfully Obvious Truth From Gartner »

    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.

    PrintView Printer Friendly Version

    EmailEmail Article to Friend

    References (6)

    References allow you to track sources for this article, as well as articles that were written in response to this article.
    • Response
    • Response
      Response: accounting books
      Identity and Access Management Framework Book - Journal - To GRC or Not to GRC
    • Response
      Response: kid's clothes
      Identity and Access Management Framework Book - Journal - To GRC or Not to GRC
    • Response
      Response: Groovy Sunglasses
      Identity and Access Management Framework Book - Journal - To GRC or Not to GRC
    • Response
      Identity and Access Management Framework Book - Journal - To GRC or Not to GRC
    • Response
      Response: Insert your Data
      Identity and Access Management Framework Book - Journal - To GRC or Not to

    Reader Comments

    There are no comments for this journal entry. To create a new comment, use the form below.

    PostPost a New Comment

    Enter your information below to add a new comment.

    My response is on my own website »
    Author Email (optional):
    Author URL (optional):
    Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>