Skip to Content

So you’re on a GRC (Governance, Risk and Compliance) project and you’ve gotten past all of the technical work. SAP GRC has been installed and all the workflows, notifications, jobs, etc. are running smoothly. The IT department breathes a sigh of relief and all seems to be good in the world. Now what?

Now your client is ready and willing to tackle those findings. That’s right, findings. All of those SoDs, critical access risk, risk flags, process improvement findings etc. that your newly implemented SAP GRC system points out so well.

Your client then turns to you and asks, “Ok, so now we’re implemented, what’s the best way to tackle these issues?” We’ve all been there. Staring at a client, wondering what is the best possible way to answer that question and replying with the most infamous line a consultant uses:

…. “Well, it depends”

You prepared your client back in blueprint that this moment would come and now it’s here. Where do you start? What are your client’s options? This is where that skill of over-clocking that CPU in your brain has to come in. You start to present the options, business process redesign, security remodeling, mitigation, etc. and you find your client slip into what I like to call the three stages of “Post-GRC Implementation Syndrome.”

 If you are that client, DON’T WORRY. A good consultant can guide you through this.

  1.  Denial – “We have HOW MANY risks in the system??” Denial may be an initial reaction, but knowing what’s going on in your system is a good thing. Having SAP GRC not only visually highlights room for improvement, but provides the tools necessary for these issues to be corrected in a streamlined manner via risk response catalogs and policy enforcement. But the greatest advantage here is prevention. Remember your goal is to not only eliminate identified risk, but also to keep it risk-free in the future.
  2. Bargaining – “Well I know that risk was identified as being critical when we first started looking at it, but there are too many exceptions so let’s lower some of these risk levels.” Don’t manipulate the stats. Try not to second guess yourself as data becomes available. While it’s true that risks and their associated levels should be periodically evaluated, trust your baseline standards and stick to fixing the problems.
  3. Acceptance – Everything is going to be OK. Trust in your software, its real-time analytics, workflow notification and audit/policy enforcement. Above all, trust your resources. A sure sign of a successful SAP GRC implementation is that all involved will have learned something new. Clients find themselves having an even firmer understanding of their business, a renewed or newly found appreciation for compliance and the technology surrounding it. For the consultant, the experience should have brought on new opportunities to make long-lasting business ties so that your client can reference your expertise anytime.

What methods do you use when you are ready to conquer a GRC project’s findings? What criteria do you use to determine what’s best for your client? Do you have specific guidelines or does it really all “depend”?

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Humberto Ramos

    What is described conforms to what is commonly observed, but that does not imply that this sequence of events is a best practice. If a client is in the need to correct SAP system configuration, it is due to a poorly performed security configuration in the first place.

    Moreover, implementing a GRC is not a task that ends with the installation of the software, in fact, installation is only an activity of a larger scale program. This program should considers:


    • Strategy and governance of the organization – Who will define access policies?, Who authorizes them?, Who oversees them?, Who implements them?
    Definition of policies and procedures for managing roles, access request and access verification

    Definition of rules for access and segregation of duties verification – this replaces or complement the generic rules proposed by the software tool, otherwise it will appear many false positives.
    Reengineering of roles and profiles of the organization, and implementing this definition onto the SAP system – This is an effort to correct the security settings and to align to the rules mentioned in previous bullet..
    Review and / or establishment of a continuous compliance office, to take responsibility for ongoing monitoring of risks observable with both SAP GRC tools, as with other tools and / or procedures, as well as the ongoing maintenance of rules verification.
    • Training end user (compliance office) to take over the operation of GRC tools,

    Training and awareness of the new policies, procedures and rules on SAP security issues for the remainder SAP implementation team and user community.

    In my opinion, all these tasks, should be included in the “Implementation” effort, and only until they are completed, you can consider that technology has actually been implemented.

    Good article
    Best regards!



    (0) 

Leave a Reply