Segregation of Duties in SAP
Following the financial scandals (e.g. Enron, Parmalat) of the 2000s and the mistrust in the market that they generated, governments decided to define rules to protect investors.
Each state, starting with the United States, has defined its own legislation in this regard. The main objectives are as follows:
- Empowering companies on accountability and financial reporting issues
- Increase penalties due to crimes or accounting offences
The lead legislation, that of the United States, is the Sarbanes and Oxley act proposed by Congressman Oxley and Senator Sarbanes, in fact, and commonly known as SOX. In Italy, the reference regulations are Law 262/2005 (Provisions for the protection of savings and the regulation of financial markets) and Legislative Decree 231/2001 (Regulation of the administrative liability of legal persons, companies and associations even without legal personality, pursuant to Article 11 of Law No. 300 of 29 September 2000).
Specific regulations of the same nature also exist in other countries, for example for the Japanese area FIEA or J-SOX (Financial Instruments and Exchange Act: Financial Services Agency), C-SOX for Canada. Europe has also decided to regulate these aspects by means of a specific directive (8th Directive – The Eighth Council Directive 84/253/EEC of 10 April 1984). Not least reference frameworks such as IFRS Internal Controls/Financial Reporting. There are several requirements that the regulations listed above require to be met. These include the protection of separation of tasks, also known as Segregation of Duties (SoD) or Separation of Duties.
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 array
- Represents the set of risks or rules (in the case of SAP's SAP Governance Risk and Compliance, Access Control tool, the array is called ruleset).
- Identify a set of tasks
- It is a set consisting of pairs or more of conflicting functions
- Represents a set of tasks that form a business process
- 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
- Countervailing 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 SoD management process does not end with the introduction and system verification of the matrix, this is only the beginning of a path.
- The steps for managing the SoD are in fact the following:
- Definition of the Risk analysis matrix of the system
- Remediation activity
- Mitigation activity
- Definition of Continous compliance procedures
- The various activities in the "Matrix Definition" phase
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.
Risk analysis tools
In the case of very small volumes (users and roles defined in the system), risk analysis could be carried out, albeit without a few difficulties, manually. In most situations, however, it is necessary to have an ad hoc instrument. What are the main tools?
- SAP Governance Risks and Compliance – Access Control (SAP)
- Approve (Infor)
- Security Analyzer (Talia Security)
- IBM IGI (Identity Governance & Intelligence)
It is important to note that the choices made when defining the array will affect the outputs produced by the tools. It may happen that unwanted or unexpected results are caused by technical errors of the matrix. In this case, the array itself must be corrected. Some of the above tools have a starting "standard" matrix inside them, to be used as a reference. Customer customizations must be analyzed and integrated into the matrix if they have SoD impacts.
The result of SoD risk analysis can be of two types:
- No risk detected (a very rare situation)
- Risks to be managed (a most likely situation)
The subject analyzed must be both the user and the SAP technical role. In the event that there are risks to be managed, a remediation plan must be defined.
How to make remediation of risks?
This phase can be addressed in two steps:
- No business interaction
- With business interaction
Often, in the first case, the removal of everything that has never been used alone can greatly reduce the number of risks that emerged during the analysis phase. While in the second case, where there is an interaction with the business normally carried out following the first step, action is taken by modifying organizational aspects. Let us remember that changing the organizational aspects is never immediate and often difficult to achieve.
In the event that it is not possible to proceed at a technical or organizational level it is necessary to maintain the risk situation but to control it. This can be done by defining a control process.
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 organisationally. 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 very 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.
How can Aglea help you simplify the management of Segregation of Duties?
We have defined many segregation of duties matrices over the years. These can be used as a starting point to adapt them to business reality.
We can help you verify that the matrix conforms to business processes, limiting the number of false positives. Often the result of risk analysis, being very technical, is difficult to read. We are able to produce reports that allow us to understand who needs to do what and in what order, giving a clear and precise view of the result of risk analysis.
In the remediation phase it is often unclear where and how to start. Aglea has defined a remediation management model that can be applied to small companies (where segregation of duties is more complicated to manage), but also for very structured industrial groups.
The definition of compensatory controls is always a critical point of the project, which is often not addressed. The definition of mitigations involves the knowledge of business processes (not only standard but also custom) and the functional and technical implementation of mitigating control. For this reason, Aglea has defined a library of compensatory controls to be adapted to the reality of customers, without having to start from a blank sheet.