Skip to Content
Author's profile photo Babu Jayendran


The subject of my blog is a jumble of alphabets! Since we are all from the SAP space we understand what it stands for!

I want to delve into one area of SAP GRC and that is Segregation of Duties (SOD).  Let us first try and understand the scenario in which most organizations work in. The responsibility for Security and Authorizations has evolved over a period of time and the staff that normally handles this function have been ‘upgraded’ from a Basis background. Most of them are hard core techies and excel in the tech space. Business tcodes for them is nothing but a jumble of alphanumeric characters! It can be MM01, FB01 or VK01, it does not matter since they are not aware of the business process and the impact of the related risk, if there is an SOD violation. The reality is that they do not have business exposure and we do not expect them to know. Some techies have picked up this business knowledge over the years and I give them full credit for going that extra mile!

The fundamental principle of SOD is to ensure that in any business process the tasks of “Initiating”, “Authorizing”, “Recording”, “Processing” and “Reporting” are segregated so that no employee has access to any 2 tasks.  The underlying assumption being that if they do, the potential of doing any fraudulent activity increases.

Let me give you an example to drive my point.  Create Material Master Record ‘MM01’ conflicts with Create Purchase Order ‘ME21’, as per Compliance Calibrator or RAR in GRC Access Control. The risk is that the employee who has this access can create a Material and a Purchase Order. The Mitigation Control could be that a Release Strategy has been configured for the Purchase Order to be released, which is given to another employee. It is extremely important that the individual who is reviewing this and granting the authorizations is aware of the risk and whether the mitigation control actually mitigates the risk. If the individual granting authorizations is not aware, the possibility of the organization living with this risk cannot be ignored.

I am only trying to highlight the importance of individuals responsible for “Authorizations” being fully aware of business processes and its related risks. If this does not happen the organization could be exposed to potential risks which the auditors will definitely point out.

The convergence of BPX with GRC could be a solution!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Well said Babu.
      SOD is about mitigating the access risks.The authorization is subject to the " need to know"and the bare minimum activities [ T/codes] essential to exercise this.This means a sound judgement from the business perspective is a significant thing.
      Technology's is just to align with business;thus the role of techies is to support the Business Managers in implementing their decisions.In other words the decision to decide upon SOD should not be driven by the Basis administrator or the security consultant.
      Author's profile photo Former Member
      Former Member

      I thought having business process knowledge was compulsory for authorization resources? It was probably a bad dream 🙂

      On a more serious note, I think you've highlighted something that is absolutely essential! How do you protect systems if you're unable to do a proper impact analysis? Surely you would need to look closely at the touch points of a business process in order to lock things down properly?

      Let's hope that more emphasis is placed on this in the future...

      Author's profile photo Babu Jayendran
      Babu Jayendran
      Blog Post Author

      Thanks for your thoughts.

      I wish it was compulsory....the ground realities are different and that is why I felt I should put my thoughts in this blog.

      I have noticed that in the GRC Access Control space most of the resources are skewed more towards the Technical side than Functional. Technical consultants are more comfortable in dealing with Authorisation Profiles,Authorisation Objects, Authorisation Values, Parameter Settings....etc. The irony is that the impact of the risk is Functional and relates to security & business control related issues.

      I do hope that going forward, the BPX & GRC convergence takes place.

      Author's profile photo Former Member
      Former Member
      I have long been an advocate of business process experience in the hiring of SAP security analysts. It has been my observation over the past 10+ years that, in general, personnel with such business experience make better security analysts than those with only IT training and experience. Yes, such BPX knowledge can be acquired second hand over the years, but I believe that it generally helps to come into the security analyst job with at least some such process expertise. I can train an accounts payable clerk to use PFCG, but to get her to understand PTP processes and controls and, for example, the importance of segregating AP from AR can be a bigger challenge.

      On the other hand, the security analyst herself should not be the person designing end user roles; a designated business process expert should be making such decisions for each process area. Armed with a properly configured SOD ruleset and robust tool for running role modification simulations, either the security analyst or the business process expert should be able to detect proposed authorization changes that would enable access that is a violation of the organization's SOD policies. The key is the accurately and timely maintained ruleset that is continually maintained as processes evolve and new functionality and transactions are enabled.

      Thanks for a thought-provoking post!


      Author's profile photo Babu Jayendran
      Babu Jayendran
      Blog Post Author

      Thanks for your input.

      I totally agree with your statement "The key is the accurately and timely maintained ruleset that is continually maintained as processes evolve and new functionality and transactions are enabled"

      With all the customized code that organizations are generating, mapping the Ycode to the correct functionality, for SOD conflicts, is absolutely important. This requires good business process knowledge, otherwise we could land up with unidentified risks or false positives! That's a nightmare by itself!

      Thanks again and regards.