Skip to Content

Lessons learned from SAP GRC projects

     SAP’s Governance Risk and Compliance (GRC) solution has so much to offer and is so feature rich that I can understand why some SAP customers might be overwhelmed, and I can relate to that. Last year, when I worked on my first SAP GRC project, the solution has so much functionality, it was a lot to take in. However, after several more GRC projects, one of my big lessons learned is that SAP GRC has something for everyone, and you don’t have to deploy the whole enchilada, as we say here in Texas, all at once if you don’t need it.


One of the project teams I was on last year worked with a customer who was migrating from another GRC solution for some of its SAP systems, but other systems in scope were not yet on an SOD tool, so we worked with them to develop custom rule sets, used SAP delivered rules, leveraged our internally developed knowledge base of SOD rules, and various combinations of those options.   If you already have SOD rules, great, you can utilize them for designing rules in SAP GRC; if you don’t have any SOD rules yet, it’s OK, too. Use the delivered rules as a basis for your ruleset, or build them up from scratch. Have it your way, as an American burger chain used to say.


Another GRC project team that I was on last year worked on integrating Superuser Privilege Management (SPM) with Compliant User Provisioning (CUP), Yes, it was a GRC 5.3 project. The client had not yet deployed those components, so for them, it made sense to go ahead and leverage the GRC version they already had, and implement the components they needed at the time.


On my current GRC 10.0 project, the client originally thought they would use Business Role Management (BRM) just as a repository of roles for the Access Request module. However, after a demo of the workflow capabilities, they decided to add the workflow functionality for approving changes to the Business Roles to the scope of the project. That component also includes functionality to do the maintenance of the SAP technical roles, basically replacing the Profile Generator (PFCG) tool, but they decided to forgo that functionality, and that’s OK, too. Just because you choose to deploy one of the component modules of GRC does not mean that you must utilize all the functionality. If just some of the functionality is the perfect fit for you, that is OK.


The lesson learned that I hope you take away is that SAP GRC has much to offer, but don’t let that discourage you if you are a smaller SAP installation or don’t need all of the functionality. It’s like the saying, how do you eat an elephant? One bite at a time. You can deploy SAP GRC in the components and functionality that make sense for you.

You must be Logged on to comment or reply to a post.
  • Gretchen, thanks for sharing your great experience with clients. Has that extended to all the solutions in the SAP GRC suite, including risk management and process control, or is it limited to the Access Control product set?
    • Norman,
      So far I have just worked on Access Control, but I look forward to future projects deploying the other SAP GRC solutions, too. Now that there is improved integration between Process Control and Access Control with the 10.0 release, I am confident that increasing numbers of SAP customers will see value in deploying more of the GRC solutions.
      I’m glad you enjoyed the post.
      Thanks and regards,
  • Hi Gretchen,

    I also want to thank you for sharing your experiences in such a project. This time I was looking specially for how did others handle the SAP-delivered ruleset. We are using it as well, but we picked up from OSS-note 986996 that SAP will not say “it is sufficient” – of course they don’t say that.

    Can you tell me please why you didn’t find that ruleset from SAP not sufficient and where (for which risks / funcitons) you adjusted the most? and – also important – how close did you work together with the auditor while designing the adjustements for the rulesetß

    Thank you very much and best regards


    By the way: I can completely confirm what you say. it is a very powerful tool and a big advantage is, that you can start with a small solution fitting you needs best.

    • Matthias,

      In that project our starting points were all over the map: some solutions were on SAP GRC, some solutions were using another GRC toolset, some solutions had no SOD risks/ rules defined at all. We held workshops where we reviewed the rulesets already in use and SAP delivered rules with internal process experts, who identified risks not already covered in the rules, and we did also have the proposed rulesets reviewed by external auditors. It was a big effort, and getting the right process experts from the business units involved was very important.

      Best regards,


      • Hi Gretchen,

        thanks a lot for your detailed feedback. This is very important for me. We have that investigation right in front of us and we need to estimate the effort and the scope of such a project. Also the involvement of the auditors will be a big challenge regarding the budget ($$$ 🙁 )….

        by the way, I started a question about the handling of the ruelset in special as well and I already got very important answers. If you like take a look:

        all the best


  • I need to learn a lot on GRC. I am waiting for an implementation project so that I can start learning. This blog are helping me to keep points in my mind to start with GRC

      • Thanks Gretchen…. Since I am new to GRC, I have got a project for SOD Matrix in GRC10.1. I need to take care of Z t-code that are created. Uploading and creating function id and risk id for the same. Can you help me with this? If some useful documents to read before on-boarding it will great. Thanks in advance

        • Mili,

          How to create functions and risks in GRC 10.x is well documented. Please review the documents listed on that reference page.

          Search first, review the documents, then post if you need clarification, is an SCN rule. Thanks and good luck!