An approach to SAP SOD Risk remediation on basis of doc types

I wanted to share my experience with regards to Financial doc types and did not find a suitable link on SCN/net in general with regards to usage of Doc types in SAP Security and GRC SOD (Segregation of duties) risk remediation, hereby sharing my observations and proposal below:

Before jumping into the topic, lets take a step back and explore the background and context. A SOD risk is where user has access to more than one part of a business process and thereby have ability to execute malicious activities and cause financial fraud.

For example, a common SAP SOD access risk (P001) pertains to access available with a user to setup vendors AND also pay them. So a user who has access to both functions (i.e create/maintain vendors and also pay vendors) will be able to create fictitious vendors and initiate payment for those vendor account.

When considering overall access design and setup to cover all aspects of business process execution at an Organization, there are almost 200 SAP SOD risks (P001 being just one example) defined in std. SAP GRC Ruleset covering various modules and cross modular access for SAP ECC and HR, that each organization can review from applicability point of view and ensure proper risk tracking is maintained for all applicable risks (ruleset development and methodology followed is a separate topic and outside scope of this blog post). Furthermore organizations, typically define additional risks with respect to custom functionality/business processes incorporated to ensure appropriate coverage across all areas – business + IT.

All in all, considering overall scope and impact of risks at enterprise level – its imperative that organizations need to maintain awareness on all applicable SOD risks and mechanism of controlling them. Obviously organizations need to invest appropriate attention, resources and focus on tracking + creating a framework of managing these risks in their landscape to prevent financial fraud/other negative consequences of SAP SOD risks.

In order to minimize SAP SOD risks, we can either focus on “remediation” which is to split or segregate (thus the term Segregation of Duties) access to different parts of a risk to different users, for instance, in above example – no user in organization will get access to both functions of risk P001 i.e no user should be able to create/maintain vendors (function 1) as well as process payments to vendor (function 2).

Other strategy is “mitigation” and at times, its necessary for organizations esp. in small shop scenarios where a user has to perform both the functions and organization accepts the risk and manages it by assigning “mitigating controls” (for example – design and implement a review process of vendor setup activities and payment activities on periodic basis and have independent sign off to ensure there were no fraudulent activities/financial fraud).

Mitigating controls add costs to organization, as reporting/review/sign offs and mitigating control owner/monitors need to be appropriately setup to ensure controls are working and periodically being checked and executed. That is why, wherever possible, focus should be on SAP SOD risk remediation and hereby I am suggesting an approach towards Remediation of a bulk of SAP SOD risks associated with financial posting access.

How to use Financial doc types in your security and GRC design to remediate some of the the self-conflicting tcode based SOD Risks – SAP NOTE 1600667 and overall create a holistic approach to SOD remediation using doc types

-Discuss with business and process team, generate alignment on usage of doc types as criteria of authorization segregation
-That is, for each doc type associate an auth group via OBA7 tcode, once business and process teams have discussed and reach to an alignment, carry out configuration and also work with stakeholders to align security roles.
-Now your security roles should be segregated on basis of different auth groups based on type of business process area. All PTP roles should be having access to only process PTP doc types and similarly RTR should have access to process RTR doc types only (Auth object F_BKPF_BLA)
-Consequently, in GRC ruleset, you can calibrate object F_BKPF_BLA and align relevant functions to include this object as part of what constitute a risk.

For example, a risk based on FB01 access such as F028 (constituent functions – AP02 and GL01) will only be a risk if user has access to post both doc types i.e PTP and RTR doc types. But if user has only part of processing access then this would not be a risk. As per note SAP note 160066, we can’t differentiate on basis of security authorizations and this risk cannot be remediated. But via this proposal and if business process is aligned with execution on basis of doc types – then we can explore remediation of self conflicting/in general many tcodes in Finance area which all allow posting of doc types can be covered as part of this solution. This approach can lead to reduction of your SAP SOD risk count at role/user level considerably and reduce mitigation cost tied up to previously non-remediable risks attached at role/user.

Ultimately it also pays that your business process is aligned with business requirements, security design is aligned with your business process, GRC ruleset is aligned with security role design and underlying harmony serves to build a suitable design for Financial posting SOD remediation as much as possible.

Hope this solution provides a way forward to remediation of SAP SOD risk at your enterprise/next project.