At Soterion, a study was recently conducted to find out how many organisations have customised their SAP access risk rule set.
We were surprised to find out that more than half of the companies we surveyed haven’t customised their rule sets and are using the vendor’s out-the-box standard rule set. Interestingly, SAP access risk rule set customisation is a common recommendation by many of the Big 4 audit firms.
SAP access risk rule sets typically contain risks for the following categories:
- Segregation of Duties (SOD)
- Critical Transactions
- Data Privacy
There are a number of benefits to customising these rule sets – and yes, some of these are obvious. But for many organisations, the advanatges of customising your SAP access risk rule set aren’t immediately apparent.
Here are some reasons to customise your SAP access risk rule sets that you might already know about (and some you might not have considered).
Benefit 1: Reduce the cost and effort of managing irrelevant risks
The out-the-box rule set has been defined for all industries and chances are these are not all going to be applicable to your unique business. Every access risk in the rule set requires some level of effort (which has a cost implication) to manage. By removing risks that are not applicable to your business, you will reduce the effort and cost to manage those risks.
Benefit 2: Get better coverage of all your processes
The out-the-box rule sets generally cover the main business processes such as Procure to Pay, Order to Cash, Finance, Materials Management, and Hire to Retire. But some of the not-so-common business processes such as IS Health, Media, Insurance, and Global Trade Services are not included in many of the out-the-box rule sets. By adding these risks to the rule set, your organisation has better coverage of all your processes.
The more common scenario with regard to updating the rule set is adding any custom functionality. As out-the-box rule sets do not contain any custom (Z tcodes) transactions, it is important to add these to the rule set. For example, if the organisation has created a custom version of VA01 (e.g. ZVA01) if this performs a similar function to VA01 and allows the users to create Sales Orders, it should be added to the rule set.
Benefit 3: Get more business buy-in for GRC activities
As detailed above, when using an out-the-box rule set, many of the risks are not relevant to your organisation. What often happens is business users lose confidence in GRC activities because they don’t agree with the risk that they are being asked to monitor.
For those organisations who struggle to get the necessary business buy-in and participation from their business users in GRC activities, a rule set customisation exercise has significant benefits to addressing this challenge in a number of ways:
Monitoring relevant and applicable risks: monitoring risks that the business believe in will enhance their participation and buy-in. This will raise the organisation’s risk awareness.
Building understanding of business impact: A big challenge for many organisations is that business users do not understand the SOD access risks, resulting in actions being taken without understanding the consequences or impact on the business. Rule set projects are usually workshop based where business users and functional consultants discuss each risk. This is a useful educational exercise where each SOD risk is explained in detail and how fraud can potentially be committed with the conflicting combination of access. Once business users understand the SOD risk, they will have a better understanding of the impact of this on the organisation, and thus be able to make a more informed decision as to whether users should have that access or not.
Defining a Standard Operating Procedure (SOP): As it is unlikely that the organisation can operate without any risk violations, there will be a number of end users who will have access risks. When a user requests additional access that is in conflict with access they already have, it’s unclear whether it can be approved. As a result, these types of requests often sit in the reviewer’s inbox for a number of days.
It’s important to define a policy for risk levels i.e. what is the rule for a simulation for each risk level? Part of the rule set customisation is to define these rules (SOP).
An example here is:
– If risk = Critical – access cannot be assigned
– If risk = High – access can be assigned but with Mitigating Control
– If Risk = Medium – access can be assigned without Mitigating Control
By defining these types of guidelines, your business users are able to make quicker decisions on whether the additional access requested can be approved. This reduces the time that SAP access change requests sit in a manager’s inbox waiting to be approved, which ultimately reduces the business downtime (end-user waiting for requested access).
Whether you need assistance with customising your out-the-box SAP access risk rule set or advice on where to start, Soterion’s team of SAP experts can assist with your unique requirements and help you implement more effective GRC. Email us at [email protected] to get started