Segregation of Duties in SAP
The purpose of SoD (Segregation of Duties) is to ensure that only persons deemed eligible can perform "sensitive" transactions; it is therefore necessary to break the process so that a user does not pose a risk of fraud.
A technical model for dealing with segregation of duties involves the use of the following two sets:
- The duties library, which are transaction families (business actions in SAP. For example: create a purchase requisition, make a change to the material data, etc..).
- The risk library, i.e. the conflicting duties between them
A DUTY (or function) represents a certain set of transactions that make up a part of a process. In other words, duty represents, as already mentioned, a certain business activity performed in SAP (creation of suppliers, issue of blocked invoices, creation of sales orders, etc.)
The risk library defines the process parts that conflict with each other. The following image shows an example of acquired process risks. In the case of SAP, in addition to the standard activities envisaged, all customer customizations must also be considered, i.e. all custom transactions that have an impact on processes declared as sod relevant.
We therefore see that in the Table Conflict List (Risks) we find the risk called RISK01 which consists of two parts of the acquisition process: PR Creation and PR Release.
These two duties in turn contain the set of activities (technical transactions in SAP) that allow you to carry out that certain functionality within the application. What are the terms used in the management of the Segregation of Duties?
- Ruleset or Matrix
- Represents the set of risks or rules (in the case of SAP's SAP Governance Risk and Compliance, Access Control tool, the SoD matrix is called ruleset).
- Process
- Identify a set of tasks SoD relevant
- Risk
- It is a set consisting of pairs or more of conflicting functions
- Function/duties
- Represents a set of tasks that form a business process
- Action/Permission
- They are the technical detail of the activities (transactions) and authorization objects used in sap environment to be able to carry out a business activity within the system
- Mitigation controls
- Define a sequence of actions used to verify and control real-world evidence of risk
What are the management steps of the Segregation of Duties?
- The steps for managing the SoD are in fact the following:
- Definition of the Risk matrix
- Risk Analysis
- Remediation activity
- Mitigation activity
- Definition of Continuous compliance procedures
Of fundamental importance is the process scooping phase. Right now, you need to identify the SoD-relevant processes involved, which are those that have a direct impact on your balance sheet.
For each process defined in the scooping phase, it is necessary to identify the risks of fraud within it.
One of the classic examples is as follows: a user cannot at the same time create or modify suppliers and start a payment to them. In this case, you could define a fictitious supplier by moving money illegally as a result.
It is important not to overdo it in the initial definition of risks within the various processes. Moreover, while it may seem premature, defining risk owners can be a strength for subsequent steps.
The construction of risks can also involve pairs (or ennuple) of conflicting functions or duty. Be careful, again, not to overdo it: better to use pairs or at most triplets of conflicting functions to describe a risk situation.
The concept of risk can be declined in several types:
- Business risk or SoD Risk: When you expect multiple process parties to merge to carry out fraud or damage
- Information Technology (IT) or Critical Actions (IT) Risk: When it expects that only a specific part of the process is sufficient to carry out a fraud or damage
- Technical risk or critical permission: When it provides that only a specific technical authorization is sufficient to carry out a fraud or damage After the matrix definition phase, it is necessary to analyze the system or systems involved.
How to manage the mitigation phase?
At the end of the 'cleaning' phase, there may remain cases of risk that cannot be eliminated, either by technicality or organizationally. This is the case, for example, with a small branch with a limited number of people operating on all processes.
In these cases, it is necessary to define a compensatory control or mitigation control which represents a test to be put in place to govern the occurrence of one or more risks. Controls can be mainly of two types:
- Preventive – That is made in advance
- Detective –That is, carried out after the event
Preventive checks are more difficult to carry out than detective controls which generally account for most of the compensatory controls adopted. In very complex contexts, naming compensatory controls can also be especially important. Often, corporate software already exists as a compensatory control repository.
If the analysis and remediation phases has not been carried out properly, the definition of compensatory controls may be too great an obstacle to overcome. It is important to stress that the definition of mitigations represents a cost in terms of monitoring and maintenance: they often have to be created from scratch and also concern customized processes. The latter are normally more complicated to manage.
At the end of the remediation and mitigation phase, any risk has been removed or placed under control. It is essential to remember that the management of the SoD does not end with the definition of compensatory controls.
For example, transactions are created or modified every day, if they are SoD relevant, it is important to manage them in the array. New users can join the staff or be removed or moved. Periodic re-validation of access and risks plays an important role.
It is therefore essential to establish a series of procedures to ensure that changes to the system comply with the requirements of the Segregation of Duties.