Why Organisational Level Controls are Important for Effective Access Risk Management.
What are Organisational Level Controls?
SAP users can be restricted to perform certain functions or activities in SAP by limiting which Transaction Codes (or Fiori Applications) they get access to. This can be considered the primary control.
Each Transaction Code has associated SAP authorisation objects and fields. The purpose of these authorisation objects and fields are to limit SAP users who are able to execute the Transaction Code, to only execute that Transaction Code for specific Organisation Levels, such as Company Codes, Plants, Purchasing Organisations, Sales Organisations etc. This functionality was developed by SAP to provide very granular level of control at the Organisational level and can be considered a secondary level of control.
Why are SAP Organistional Levels Controls Important?
Without proper Organisational level control, SAP users have the ability to perform certain functions for Company Codes, Plants etc which they do not belong to.
Deficient Organisation level controls can potentially lead to fraudulent activities, but the more likely scenario is erroneous postings to incorrect Company Codes, Plants etc.
Incorrect postings can negatively impact company reporting and associated decision making, as well as the cost of reversing these transactions / postings.
The importance of Organisational level control has increased as data privacy regulations have come into effect. Historically, many companies have been more liberal in the granting of Display access, where SAP users are granted many Display Transaction Codes often with minimal Organisation level restrictions i.e. SAP users are able to view data for all Company Codes, Plants etc. For companies that have a presence in countries that have data privacy regulations, there is a requirement that data associated with those citizens are adequately restricted from SAP users belonging to other countries and regions. This restriction is done by implementing effective Organisation level control.
Why are Organisation Level Controls more challenging to Implement?
As mentioned earlier, each Transaction Code has associated SAP Authorisation Objects and Fields. These ‘associated’ SAP Authorisation Objects and Fields are determined by the ‘authority-check’ statement in the ABAP program, in other words, when running a Transaciton Code, the ABAP program checks whether the SAP user has the SAP Authorisation Objects and Fields defined in the authority-check statement assigned to them (in their SAP user buffer).
Transaction Codes are associated with a varying number of SAP Authorisation Objects. If a Transaction Code does not have any ‘associated’ authorisation objects, it is not possible to restrict it at an Organisational level. If an SAP User has that Transaction Code, they can run it with no restrictions. However, the vast majority of SAP standard Transaction Codes have at least one associated SAP Authorisation Object (one to many relationship). The Authorisation Fields linked to the SAP Authorisation Object are then what can be controlled on.
Using the example below, if an SAP user is assigned Transaction Code FB01, as one of the ‘associated’ SAP Authorisation Objects is F_BKPF_BUK with contains the SAP Authorisation Object Fields ACTVT (Activity) and BUKRS (Company Code), it is possible to restrict an SAP user to only post documents to specific Company Codes.
| Transaction Code | SAP Authorisation Object | SAP Authorisation Object Filed |
| FB01 | F_BKPF_BUK | Activity and Company Code |
The technical challenge from an SAP authorisation concept perspective is that the same SAP Authorisation Object has been linked or associated with many Transaction Codes. As an example:
| Transaction Code | SAP Authorisation Object | SAP Authorisation Object Filed |
| FB01 | F_BKPF_BUK | Activity and Company Code |
| FV50 | F_BKPF_BUK | Activity and Company Code |
An SAP user’s authorisations are merged together in their SAP authorisation user buffer and there is no reference or linkage between the values defined for each of the SAP authorisation Object Fields and the Transaction Code. In other words, if the values are defined in the SAP user’s roles as per the below:
| Transaction Code | SAP Authorisation Object | SAP Authorisation Object Filed |
| FB01 | F_BKPF_BUK | 01 (Create) and 1000 (Company Code) |
| FV50 | F_BKPF_BUK | 03 (Display) and 2000 (Company Code) |
This SAP user will be able to Create (01) for Company Code 1000 when using Transaction Code FV50. Although incredibly granular level control is possible with SAP Authorisation Object and Fields, there are limitations due to different Transaction Codes sharing the same SAP Authorisation Objects.
Another challenge is the sheer volume of data. A typical SAP user may be assigned over 100 Transaction Codes, and each of these linked to 2 or 3 SAP Authorisation Objects. SAP Users are assigned thousands of instances of SAP Authorisation Objects making it very difficult identify deficiencies.
Why is less emphasis placed on Organisation Level Controls?
One of the primary reasons why less emphasis is placed on Organisation level controls is due to the organisation not knowing how bad the situation is. Reporting on Organisation level control deficiencies is extremely difficult. Audit may highlight SAP users who have posted documents into Company Codes for which they do not belong, but seldom does audit highlight which SAP users have the ability to post to Company Code that they do not belong. This is partly due to many access control solutions not having the ability to report on Organisation level control deficiencies. The access control solution will be able to analyse at the SAP Authorisation Object Field level, but the rule set does not cater for this type of check, or they are unable to link the SAP user to an Organisational Level group.
How to Implement Effective Organisational Level Controls?
Unfortunately, rectifying Organisational level control deficiencies is challenging. As SAP users inherit SAP Authorisation Objects from so many Transaction Codes, performing role remediation or clean-up projects can be time consuming and cumbersome, especially if the organisation has an out-dated or inappropriate role design. The reality is that resolving Organisational level control deficiencies may require a complete role redesign.
However, the starting point is to understand the state of the Organisational level controls at your organisation. Or in other words, the degree of the deficiency of this control. Once this is understood, the organisation will know what options are available to them (role clean-up vs role redesign), and can decide whether the cost of embarking on such a project is worth it.
If an organisation is embarking on an S/4 transformation project, this is a great opportunity to ensure that the new role design adequately caters for Organisation level control.
Partner with Soterion to help you manage your Organisational Level Controls
Soterion’s access risk reporting functionality not only highlights SAP users and roles that have segregation of duty violations, but also those SAP users who have the ability to perform functions for Organisational Levels for which they do not belong.
Contact us today for a Soterion access risk assessment of your Organisational Level access.
