Challenges of Using Standard Business Templates for SAP Security Activities

SAP will not provide maintenance support for SAP ECC after 2027, effectively forcing customers to migrate to S/4HANA before this date. Currently, less than 40% have completed this transition, leaving thousands of customers facing the need to migrate in the coming years. This impending wave of migrations poses a substantial challenge for SAP and its partners, potentially causing a shortage of resources to meet the prescribed deadlines.

To mitigate this, SAP have initiated the development of several accelerator tools to aid these projects. However, due to the sheer volume of companies that still need to embark on this journey, many of them may resort to using pre-built Standard Business Templates for various functions during their S/4HANA project. In our discussion here, we’ll delve into the potential challenges that arise when using these pre-built Standard Business Templates for SAP security and GRC (Governance, Risk, and Compliance) activities.

Two typical Standard Business Templates for SAP security and GRC activities that will be discussed in this article include:

  1. SAP Standard Business Roles
  2. Standard ‘out-the-box’ rule sets

SAP Standard Business Roles

These predefined SAP roles are created to cover the necessary functions for specific job roles, like an Accounts Payable Clerk. They consist of various standardised SAP single roles, potentially sourced from multiple SAP systems. Business roles, when designed and implemented correctly, can be greatly  improve the efficiency of access management activities like users access requests and User Access Reviews.

What are the Pros and Cons of using SAP Standard Business Roles?

  • Pros:
    • Utilising pre-built SAP Standard Business roles reduces the effort needed during the project phase to create roles. If the security team faces delays or lacks expertise, these roles can ensure that testing can be done earlier and end users are assigned access to carry out their job functions at go-live.
  • Cons:
    • Organisations differ significantly in their operations, making Standardised Business roles potentially unsuitable for specific user groups or job functions. Not only can a Standard Business Role result in over assignment of specific functions, but also lead to end users being assigned multiple standardised Business Roles, resulting in broad and inappropriate access. This not only increases the organisation’s access risk exposure, but also complicates compliance tasks such as User Access Reviews.

    Standardisation of job roles often leads to SAP users having broader access, thereby increasing the organisation’s exposure to access-related risks. Organisations must weigh the advantages of provisioning efficiencies due to standardised job roles against the heightened access risk exposure.

    The extent to which an organisation standardises its job roles can differ, presenting in two main variations:

    1. The proportion of Business Roles to SAP Users. For instance, Company A with 2,000 SAP users has 50 Business Roles (a ratio of 1 business role per 40 SAP users) compared to Company B with the same number of users but have 100 Business Roles (a ratio of 1:20). Company B is likely to have fewer access risk violations as the larger number of Business Roles to SAP Users will allow them to assign more appropriate access to each group of SAP Users.  
    2. Whether a Business Role only encompasses core or common activities, with any unique functionality used by a sub-set of the group assigned directly to those users who need them. This approach avoids including unique functionality in the Business Role, which would otherwise lead to all users assigned to that Business Role inheriting this access.

    Determining the extent of standardisation varies across companies and hinges on several factors, including organisational size, industry, and risk tolerance. A common hurdle for many organisations is the decisions to standardise is often made by senior management who grasp its advantages, but lack comprehensive awareness of the associated challenges and risks. To address this, SAP security professionals must enhance their ability to educate senior management about these potential issues.

    A suggested approach involves conducting a thorough access risk analysis for each business role within SAP to identify their level of access risk. Role Owners can then make informed choices about whether the access risk associated with each Business Role is acceptable to the organisation. If deemed unacceptable, modifications can be made to the Business Role until the associated access risk meets the organisation’s access risk appetite.

    However, equipping role owners with access risk information before SAP go-live necessitates the SAP security team responsible for role building to have access to an access control or GRC solution. Unfortunately, many organisations undergo the role build phase in an SAP implementation or upgrade project without such a solution in place, overlooking potential access risks. Consequently, roles are transported thorough the SAP landscape (DEV, QAS, PRD) for end-user testing and eventually assigned to SAP users in the Production environment. It’s not until the roles are in SAP Production that an access risk assessment of SAP roles and users occur.. At this stage, it is too late to make any meaningful changes, considering the impact on the pending go-live.

    Addressing role deficiencies in SAP Production becomes complex and challenging, as making substantial changes post go-live can disrupt business operations. Consequently, organisations often persist with inappropriate roles and the associated risks for extended periods, accepting the potential consequences due to the reluctance to cause business disruption.

    Standard ‘out-the-box- rule sets

    These rule sets are typically furnished by the Access Control or GRC solution provider, constituting built-in rules within the specific solution. Additionally, third-party rule sets are available from external sources like the audit firms.

    Out-of-the-box rule sets consist of predetermined rules that identify SAP users and roles violating certain conditions. For instance, a common standard rule within most software vendor rule sets includes the permissions to generate and release a Purchase Order. The SAP User and Role data from the SAP systems are analysed in the access control solution against the rule set to highlight SAP users and roles that breach any of the rules.

    What are the Pros and Cons of using SAP Standard ‘Out-the box’ rule sets?

    • Pros:
      • Standard ‘out-the-box’ rulesets enable organisations to perform an access risk analysis and start monitoring them immediately. These standard rule sets, which are now well-established (mature), typically encompass a wide range of business processes.
    • Cons:
      • Standard ‘out-the-box’ rulesets lack coverage for risks that might be specific or exclusive to an organisation. They also do not accommodate any custom functionality (custom transaction codes or Fiori apps). Consequently, this absence leads to the organisation being unaware of unique access risks stemming from their customisation.
      • Additionally, Standard ‘out-the-box’ rulesets encompass risks across multiple industries, potentially including irrelevant risks for certain organisations. Consequently, this results in the organisation expending effort monitoring risks that do not pose real threats within their environment.

    Utilising a standard ‘out-of-the-box’ rule set is relatively common among many organisations. Although the customisation of the standard ‘out-the-box’ rule set is strongly encouraged, it is generally accepted that the organisation can make use of the out-the-box rule set for a period before they embark on a rule set customisation project. On the other hand, the customisation of the Business Roles prior to go-live is highly recommended.

    To learn more about how Soterion can assist you with your SAP security and GRC requirements, please reach out to us at [email protected].

    You may find this interesting