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.
cancel
Showing results for 
Search instead for 
Did you mean: 
FilipGRC
Contributor
Part # 2/5 – When is it worth to create and when should we avoid mitigating controls?

In the previous part (#1) of our Mittigation control series of articles  we concluded that managers responsible for business operations 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.

Mitigating controls are a common management response to the access risk coming from conflicting system authorizations 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. In this part (#2) we will debate about when it pays off to implement a mitigation control and when it is better to remove user access.

One million dollar question is: is there 'some' algorithm for dealing with the new access risk of excess rights? What is the best way to proceed? When and what activities to execute? In this article, I share my knowledge and experience in respec to approach to SOD security and access risks.

When is it worth using mitigating controls?

While working on audit and consulting projects, I observed that the business management team, while working on the company best response to the access risk, more often than required, uses the creation of mitigating controls. Often this happens under pressure and a strong need to meet the audit requirements coming from external or internal auditors that are general in nature, served to customer without paying attention to specific situation.Should having more & more controls, which are very costly to maintain in long run, be the first management's choice? How to design a control mechanism so that it brings a real benefit to the internal control system and significantly reduces the risk for which it was created?

This is the question that we will answer in this part of the article too add my part to our series of five articles – see a list here. Our observations of the controls life cycle show that it is definitely worth to use mitigation controls in the following situations:

  1. Conflicting user access activity are required to perform system tasks assigned to user and specified by the HR department at a given job-position. Introducing changes in such a situation is a difficult and complicated task.

  2. Access risk are coming from wrong process design and it is not possible to change process design or the scope of activities to be performed, or separating these activities into another organizational area.

  3. There are limited human resources and access risk related user responsibilities can not be delegated to another person in the department.


The presence of the above-mentioned situations makes the application of mitigating controls more justified. However, the order in which to proceed is important in determining the Organization's best response to a segregation of duties conflict. A model sequence of operation is presented below.

  1. Conflicting access risks are part of HR defined user responsibilities


The first step in any authorization redesign project is the removal of redundant (not used) user access rights. The access rights defined as redundant are those assigned to the user authorization profile, while in practice (e.g. for the last 12 months) they are not used at daily employee ERP (SAP) system operations. Often, but not always, this system access are also not defined in the scope of the employee's responsibilities in its HR job-position description. Identifying and then removing this authorization, from my experience, eliminates about 50-60% of all risks identified in the user's permissions. In any case, this should be the first step in remediating the problem coming from redundant permissions. Skipping this step means that we begin to develop control mechanisms for risks that do not require it (have not been ‘materialized’ since last 12 months, as transaction was not executed) or there is an alternative, cheaper to maintain and more effective in operation, that the company has failed to implement. If there is a valid business reason to believe that the authorizations are being used to fulfill the daily job tasks, as described in job description, there is a need to conduct a detailed analysis. The analysis is not always simple, because the "general business description language" in which the user responsibilities are described, often cannot be directly translated into the SAP business process activities executed by user in the SAP S/4 Hana system. Those are often defined using specific activities (transactions) that are executed during day-to-day system operations. To prepare such a content manager needs SAP system experience and technical system understanding. Helpful here maybe the key user or application consultants engagement.

  1. Organizational change in the business process is not possible


If all not needed user access authorizations have been revoked, and there is still an access risk of segregation of duties, it means that at the stage of designing business processes flow, the segregation of duties risk matrix was not taken into account. The team that designed the processes or target responsibilities of employees did not consider the fact that some activities in business processes in ERP systems should not be performed by the same person. In such a case, company management should consider changing the way the business process is carried out. Consider whether the conflicting scope of access authorities may be switch to another HR job position in the department or another organizational unit. Best practice here is to move authorization for working with process master data (business partners, material indexes, a chart of accounts, the structure of controlling objects,) to dedicated teams, that are not responsible for business process day-to-day transaction processing.

  1. Limited human resources


If the assigned user authorizations are consistent with the scope of HR job responsibilities and the process itself cannot be redesign / changed in a short period of time, the next step should be to analyze whether the resources that the Organization has at its disposal are able to delegate these duties to another employee. These types of changes do not require a comprehensive reorganization of the processes, but a different distribution of responsibilities in the department. In practice, it can be difficult to implement. The "simulation" functionality is very helpful in implementing such a change, in which the GRC system creates a preview of the theoretical situation in which the given authorizations will be assigned to another employee. You can read more about the features of the GRC system on our website (#grcadvsory, #smartGRC). Coming back to the often-emerging challenge of limited human resources, it is worth following the example of one of our projects. An employee of a local, small Customer Service Department, which employs 2 people, is responsible for recording sales orders from customers that flow from various sales channels and ensuring (by verifying and, if necessary, correcting) that the prices on sales orders are in line with the company's current price list. The scope of duties defined in this way means that an employee in the SAP system, in addition to access to work with orders, must have access to correct valuable conditions. Combining these two activities in the system creates a risk that the prices entered on the orders will be incorrect and the company will lose the trade margin due to incorrect information entered on the sales order. Organizational change is not possible, because the department employs only two people who know the specifics of the local market and customers. The scale of operations means that without employment or centralization of this function, it will not be possible to divide responsibilities. Applying mitigating control in such a situation is the most beneficial decision from a business point of view.

Let's summarize when it is not worth implementing mitigating controls:

  • In a situation where in the SAP / ERP system it is possible to partially limit or revoke user rights

  • The organization accept the possibility of changing the current business process in place, to include segregation of duties requirements in the process design

  • User permissions can be delegated to another employee, thus avoiding new risks or segregation of duties conflicts.


In the next part of Mittigation control series of articles, we will describe what are the best practices and how to build a mitigation control repository.  We will deal with the Bermuda Triangle(also know as Devil's Triangle), where all our SoD conflicts and access risks 'magically' disappear and then return during the financial audit😊 How to avoid their delay in time and sudden appearance during an audit? How to avoid the risks of their materialization?

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