Financial Management Blogs by Members
Dive into a treasure trove of SAP financial management wisdom shared by a vibrant community of bloggers. Submit a blog post of your own to share knowledge.
Showing results for 
Search instead for 
Did you mean: 
Part # 1/5 - The challenge for mitigation controls.


In my previous post I introduced the blog post series we preapre together with andrzejpartyka. I want to discuss the topic further to challange aproach where by default mitigation controls are used to to eliminate the excessive authorization risks. Are we eliminating the root cause of the problem or are we just dealing with its side effects? Let’s debate whether it is the right and well-thought approach. What are the negative consequences of doing so, are there any?

Mitigating controls are control mechanisms implemented in business processes, for the purpose of limiting the access risk coming from the user excessive authorizations granted in ERP systems. These are activities, in most cases, outside the ERP system (SAP) and conducted in a manual manner, usually based on SAP reports or other statements generated from the IT systems. Mitigating controls are a common management response to the access risk coming from conflicting authority assigned to users in SAP. Removing user access rights or modifying access via role change management process is a difficult, time-consuming and very often under appreciate response to the problem.

Considering the access risk of excessive or incorrect authorizations in the SAP system as a serious disease, it should be remembered that each treatment requires, first of all, a full spectrum diagnosis. Next using the doctor's knowledge and practice experience, appropriate diagnostic facilities and treatment plan, the disease (excessive authorization in SAP), can be cured.

As in the case of any disease, also in this area, anyone who faced the problem of wrong user access management process may consider applying short-cut solution. However, it is only a painkiller that will be a temporary solution to a serious problem, remediating a problem output not dealing with a root-cause of the problem. Sometimes such choice may prove to be beneficial but should not be considered as a long-term solution, like a painkiller can not be a substitute to doctor treatment. Are mitigating controls only a pain killer to excessive user system access or is it a remedy to the root cause of the SAP authorization problem?

Project implementation practice

A properly carried out project of rebuilding user roles and authorizations in SAP should be based on a segregation of duties matrix for user responsibilities in business processes designed during business workshops. The SoD matrix is ​​a key product in such project, often overlooked during the implementation of a new SAP system. The project team focused on the quick and cost-effective launch of the new S/4 Hana system, ignores the security aspects, shifting the effort for their implementation to the period after the go-live of new SAP system. The segregation of duties matrix is, however, ​​a key product that summarizes the requirements for building authorizations from the perspective of the specificity of the company that implements the new SAP system. These requirements are the foundation for the future authorization architecture, which is derived from the method of executing activities in business processes. This product considers how the company: allocates documents, works with master data, controls data through Workflow system, carries out payments, warehouse, and logistics operations, etc. It is acting as an access risks security repository with guidelines and principles on how SAP users should be assigned to access rights and authorities in SAP system. Preparation of this information is a considerable investment, but from our experience it is worth doing it during the system implementation project to better prepare for the ongoing new ERP system operation and exploitation phase. This approach ensures the security of financial data from the very first day of the system operation, which is a huge benefit in comparison to alternative approach, where after go-live system is being secured and security breaches are closed. Solving these problems later causes additional work in needed to assess whether in the period from system go-live to security issues remediation, wrongly assigned, excessive permissions have not been misused by internal or external users. In case of such problems, it is possible to act on an ad hoc basis by implementing additional mechanisms in the form of mitigating controls, but it is worth considering beforehand whether it is a beneficial solution in the long term?

Over the last few years, our company carried out several dozen projects to rebuild authorizations in various organizations. We have cooperated with private enterprises as well as public administration units. We also had the opportunity to cooperate with widely recognized, international corporations.

Among many conclusions from such projects, the topic of mitigating controls seems to be an interesting aspect, and more precisely, the visible tendency to address these unnecessary risks in SAP authorizations by introducing additional control elements, the so-called "Mitigating control". Is this the correct approach? What are the consequences of doing so? Is there one answer that is right for all organizations or situations?

What is the challenge?

Excess user access authorities in the SAP system are circumstances in which a given user has unnecessary access in the SAP system that generates a risk to the company. Additionally in common practice the user usually does not even use these risky access. The Company is exposed to additional risk with a significant weakness withing security model and becomes for this exposure no rewards or benefits (e.g. replacement in the absence of another employee). This situation generates segregation of duties  risk with potential exposure to fraud or company assets misuse. In our projects, we introduce mechanisms that allow us to determine which authorization or transaction the user has executed in the past period to justify if access is really needed.  As a result, it allows to report information about transaction and system usage. This is useful, however this does not respond to the main question if used access is need by user or not, and if access was assigned based on minimal required access to perform user responsibilities and business process duties. This creates a challenge for both IT and business management.

An example from a project

To better understand the challenge of mitigating controls, let's use an example from the sales area. The price at which the Company sells its product to its Client should be carefully monitored and it is usually copied (imported with display access) from the price master data lists prepared by the team responsible for the pricing policy. It is carefully prepared based on the current market situation, labor costs and inventory, as well as the forecasted demand for goods and services. Then the sales price proposals undergo a detailed verification and approval process. At the end of each week, the list of applicable prices is sent to the system for the next billing period. Access to these operations should be monitored and restricted.

In the SAP sales process, the price information is presented on a sales order document processed by an employee of the Customer Service Department. One of the values ​​that he can modify (intentionally or accidentally) is the price of the product. This creates vulnerabilities in the sales process with access risk of sales prices being modified during sales order creation of throwing all the work (prices validation, approval, etc) of the pricing team into the bin, but what is worse, there is also the risk that prices will not be adjusted to market conditions. This will also directly cause the risk of a falling trading margin and, consequently, net profit, which is the basic indicator analyzed by investors and company owners. Of course, there are many arguments for such a situation, the most frequently mentioned ones are the possibility of correction in the event of an error or a special sale for an 'exceptional' customer.

A natural action (or best practice advise) would be to not allow to change sales order price for users in Customer Service Department. In practice, however, it is much convenient for business users to propose a new mitigating control in which another user will, on systematic basis execute control action. This activity will focus on comparing the prices used in the sales orders to those in the price lists. This control will be random, and the method of its implementation will be a time-consuming operation with the nature to find out difference between two sources of information. Of course, this initial control will be optimized and evolved during control life cycle, new automation elements will be introduced, e.g. in the form of a price discrepancy report, which will be generated automatically after a few weeks or months. But is it really the right way? Would it be possible to simply 'avoid' such operations instead of automating such operations? Should automation capabilities replace thinking about the method and how to design business processes to be secured?

Often, instead of considering changing the approach to the access risk of wrong system user access rights, companies develops further automation: new reports or systems are created that compare these two statements faster and cheaper.

The find a right solution we need to take a look at the problem from a broader perspective and do not consider other solutions from the scope of the entire internal control system. It is also a problem because many business owners, under the influence of strong pressure from internal or external audit, convinced that the more controls there are to mitigate the operations in business processes, make the business process safer. However, it is worth considering whether the choice of this route will not cause a continuous appearance of new problems, "fires" requiring extinguishing and generating unnecessary costs? Are there other methods and ways that will allow the effective and safe use of the SAP system by users inside the organization?

Are the all user accesses in SAP required?

The above example concerns on granted broad authorization to users, but much more often we deal with a situation in which access is granted less intentionally. Excessive access is often unnecessary and unused (e.g. logs from SM19 or SM20 transactions do not indicate use for the last 12 months) by the user, and its presence in the permissions poses a significant threat to the company. Thus, we refute the popular myth that often appears in our clients' concerns that the SOD risk resolution project is directly related to the fact that users will lose the rights to transactions they need to work. Often, an allowance rebuilding project begins with the removal of permissions that have been previously granted to users that you do not use in their daily work SAP operations. Based on our design observations, these powers account for approximately 50-60% of the risks of redundant access.

The challenge faced by the organization is that managers responsible for business processes must decide when and in what situations the system access risk should be remediated by access removal, and when it should remediated by assigning compensating controls.

Summary & Conclusion

Often the solution is to involve people from different departments with the appropriate competencies and link them with technical competencies that are knowledgeable about roles and authorization best practices. Such a combination is a basic element of an efficient response to the presented problem of excess access or the abuse of risk-reducing controls. The problem resolution decision can not be found working in company or process structure silos – cross organizational team will have more chances to find better solutions.

In the next, second part, we will briefly present the GRC procedure for dealing with the new risk of excesive access rights. As can be seen from the problem description so far, this algorithm should not start and end with creating a new mitigating control. So how do you react? What to pay special attention to? About this in the next part of the article. We highly recommend reading and leaving a thought or two on the subject.

Please share feedback or thoughts in a comment section.

Read more on related topic in SAP Solutions for Governance, Risk, and Compliance Topic Page

  • See our introductory post with link to other articles in this series prepared together with andrzejpartyka

  • Ask questions about Governance, Risk, Compliance (GRC), and Cybersecurity and follow us

  • Read other Governance, Risk, Compliance (GRC), and Cybersecurity and follow blog post

  • Please follow my profile for future posts fnowak

Filip Nowak
Top kudoed authors