Segregation of Duties (also known as Separation of Duties) is a never-ending topic when it comes to ERP systems such as SAP, as segregation of duties is an elementary component of any system of internal control. This blog post will help you to assess how well your business is performing in this area. I would like to show you a maturity model for the separation of functions, which you can also use to assess your own company’s performance!
Why Segregation of Duties?
Many companies rely on standard business software to implement business processes and integrate business data right across the value chain. Trust in such systems can, however, only be justified, if they are sufficiently secure. In order to ensure system security, an authorization concept is required, which provides a carefully implemented segregation of duties. Many companies have difficulties implementing segregation of duties. One major cause lies in the inherent complexity of ERP systems. The comprehensive scope of the applications and the high degree of process integration require not only a strong understanding of business-processes, but also system-specific know-how. The high complexity of segregation of duties, increased awareness of the importance of quality and the need to adopt the most efficient approach all mean that there is an ever greater call for standards and methods of assessment for the segregation of duties. Through the use of maturity models, it is possible to measure the quality of segregation of duties. On the basis of the degree of maturity attained, management and other interested parties are informed of the extent to which the company has the ability to successfully implement segregation of duties in ERP systems. The definition of the degree of maturity determines what is to be considered “good practice”. A maturity model is thus not only an assessment approach, but also serves as a framework for the continuous improvement of processes. This article sets out a maturity model for the segregation of duties, which can be used as a basis for the management of access authorizations.
The basics of Segregation of Duties
One prerequisite for the proper operation of a business application is the allocation of user rights on the basis of an authorization concept. The authorization concept should ensure that only necessary authorizations are assigned to users in order to avoid unauthorized access to a system. Thus, the IDW RS FAIT 1 (German Audit Standard) makes the following provision: “Employees are only to be given the entitlements required to perform their tasks” (FAIT 1, paragraph 84). In practice, user rights are assigned on the basis of user roles, which should bundle the rights in a task-oriented manner. Within the framework of the administration of access rights, a role thus functions as an administrative unit.
The segregation of duties represents a specific aspect of the authorization concept. Apart from the access rights needed by the employees to do their work, it is considered here that the tasks to be performed or the functions required for them are not in a conflicting relationship. The Global Technology Audit Guides (GTAG) issued by the Institute of Internal Auditors (in particular IIA 2007, GTAG 9: Identity and Access Management, p. 7) require compliance with segregation of duties.
Originally, the principle of segregation of duties originates from organizational theory and is better known as the “four-eyes principle”. The aim of the “Four-Eyes-Principle” is to prevent errors and misuse during critical activities. Meanwhile, segregation / separation of Duties (SoD) is well-known as a basic principle of IT security, even though the explicit reference to information technology is absent in most cases. In its simplest form, this principle states that a sensitive task is to be divided into two steps, carried out by different people. The Institute of Certified Public Accountants in Germany (Institut der Wirtschaftsprüfer – IDW) defines the separation of functions as a set of control activities which ensure that approving, executing, managing and accounting functions are performed by different persons. A typical example of a required separation of functions is the maintenance of the vendor master data on the one hand, as well as the recording of outgoing payments on the other hand. In order, for example, to avoid the bank details of certain creditors being manipulated for outgoing payments, the corresponding authorizations must be assigned to different persons.
Maturity models have their roots in quality management. The concept is used for quality measurement and as an approach to continuous improvement. The fields of application of such models are now diverse. The idea of the maturity model is to describe the typical characteristics of an organization with regard to a particular application at different maturity levels. This makes it clear what is to be considered to “good practice” or “bad practice” with regard to the scope of application, and how the differing degrees of graduation between them are determined. Perhaps the best-known maturity model is the Capability Maturity Model (CMM) for software development. It was presented in 1991 by the Software Engineering Institute (SEI) in version 1.0. In the meantime, the SEI has developed additional reference models for product acquisition and the provision of services. The structure and the core of the content are common to all models. Processes are defined in each model. The process areas include objectives and best practices to achieve these objectives. All practices are further explained by typical work steps and related work results. Another well-known maturity model is the Business Process Maturity Model (BPMM). Based on this approach, the Object Management Group (OMG) contributes to the evaluation of process management. The BPMM is congruent with the CMM in that the focus is clearly on the process-oriented nature of the application area to be evaluated. The CMM, on the other hand, focuses more on project organization. Thanks to its process-oriented approach, the BPMM is not limited to one company with regard to the value chain, but can also be used across companies.
A maturity model for the management of Segregation of Duties
When developing a maturity model, a specific type of model is first selected. In the literature, maturity grids, Likert questionnaires, hybrid models (combination of maturity grids and Likert questionnaires) and CMM models are distinguished as possible types of model. The maturity model presented below is based on the so-called Likert questionnaire. The Likert questionnaire, unlike the other models, is characterized by its low complexity and ease of use, as well as a good blend of detail and precision. These characteristics can be decisive for the successful application of such a model.
The first step is to determine the number of maturity levels. In principle, any number can be selected here. As a rule, the models have between three and six degrees of maturity. We have opted for five levels of maturity. In a second step, criteria are set out which can be used to assess the different degrees of maturity. In the case of a Likert questionnaire, the criteria are assessed on the basis of questions. The scaling available to answer the questions may differ. The number of complexity levels in our model ranges from two to five depending on the question. In total, 31 questions have been developed to determine the degree of maturity of Segregation of Duties in standard business management software. For better structuring of the maturity model, the criteria are assigned to the categories of rules, control, SoD reporting and organizational framework. When determining the degree of maturity, it is possible to distinguish between two methods. On the one hand, there is the possibility of quantifying the criteria using a scoring model. A certain degree of maturity is in this case assigned on the basis of the determined scores. On the other hand, there is a method which is referred to as the “staged” method in the literature. Here, for each degree of maturity, the criteria which must be at least fulfilled, or the degree of complexity that these criteria must at least present, is indicated. With regard to the graduation of the degrees of maturity, the definitions are to be understood as meaning that a degree of maturity must always fully meet all criteria of the degrees of maturity below it. In our maturity model, the latter method is used. In what follows, the four categories and the criteria assigned to them are explained in more detail.
‘Rules’ category
The rules are the basis for SoD analysis. The segregation of duties to be considered are defined here. They form the design principles for the design of the SoD controls. The quality of the segregation of duties in standard business management software therefore depends, in particular, on the rules used. Specific characteristics of the set of rules play a role here, and can be used as criteria for the maturity model. These include the completeness of the rule set. In the case of a SoD analysis, in the end, it is only conflicts which are defined in advance that can be found. A further criterion besides completeness is the actuality of the rule set. As a result of the risk identification process, the rules must be continuously checked for completeness and correctness in order to ensure the quality of the SoD process. Accordingly, the development of a SoD matrix is also a continuous, ongoing task. A further aspect is the system compatibility of the respective rule set. This involves the assignment of the individual functions from the rules set to the corresponding functions or transactions of the relevant ERP system. In the case of larger groups with a heterogeneous IT system landscape, for example, it may be necessary to apply the rules to several systems in order to ensure the functional separation is complete. Altogether, we have formulated four questions to determine the degree of maturity of the functional separation for the category of rules. The unit of measure is either their existence or their degree of complexity.
‘Control performance’ category
In the ‘controls’ category, the criteria are summarized, dealing with guidelines and procedures for addressing the identified risks. Following the phases of the SoD process, it is possible to use these criteria to assess the extent to which compliance with the previously defined rule set is checked with the aid of the various controls. Essentially, three criteria can be used to measure the degree of maturity of the inspection: the timing, the type, and the frequency of control.
Concerning the timing of the control, it is possible to distinguish between preventive and detective checks. For example, a check can either prevent the risk from occurring at all (ex ante), or, retroactively, determine whether a risk has occurred (ex post). Detective and preventive control activities should be used together and complement each other in order to allow for a process of continuous improvement in SoD controls. The process weaknesses, which are detected by detective controls, should be permanently eliminated or avoided by preventive controls. Thanks to this interaction, not only can individual irregularities be identified and corrected, but the preventive measures can also be continuously optimized. In the long run, the detected error rate is significantly reduced. Accordingly, a preventive control may, for example, mean ensuring that only those authorization combinations which do not contain any SoD conflicts can be allocated to employees. In practice, role management concepts are predominantly used for authorization management in ERP systems. A role summarizes the permissions required to process a task. This form of authorization is less labor-intensive and thus reduces the error rate within the framework of administration of authorizations. In this case, a preventive check could, for example, be designed in such a way that only functions that do not contain conflicts can be combined into roles. It is also feasible to implement preventive checks when maintaining authorizations.
The compensating control is a special case of the detective or preventive control. If a control in the controls framework cannot be implemented, it may be appropriate to carry out a compensatory check in order to minimize the risk arising from the elimination of the original control. In contrast to checking the authorizations, the master and transaction data of an ERP system can primarily be used to carry out detective compensatory checks. An analysis of the master data and transaction data is necessary in order to check both for possible misuse of incorrectly configured authorizations, as well as to identify errors or misuse of critical individual authorizations (ex-post analysis). Here, the aim is therefore not to investigate what an employee could do but what has actually been done. In this way, it is possible to identify steps in the process which have not been carried out in accordance with the defined rules. An example of a possible process anomaly in purchasing is the issuing of an order and the corresponding invoice by the same person. If analyses of master data and transaction data are carried out on a regular basis, control violations can be detected promptly and corrected. In addition, systematic weaknesses in processes can be eliminated by means of such analyses.
| ERP-System | ||
| Authorization | Master and Transaction Data | |
| Preventive Controls | Detective Controls | Detective Controls |
Another feature is the way controls are performed. Thus, a distinction can be made between manual and automatic controls. Especially in the case of SoD checks, an automated procedure is recommended. There are basically two reasons for this. On the one hand, due to the inherent complexity of ERP systems, there is often a very complex set of rules which must be taken into account when implementing the controls. On the other hand, the implementation of the SoD controls can be described as a very structured procedure, which means automation is an option. By using automatic controls, efficiency is increased, on the one hand; while, on the other hand, the error rate, which tends to be relatively high when checking a complex set of rules manually, due to human error, can be significantly reduced. In order to automate control activities, the use of software for checking the authorizations for standard business software is a prerequisite. With the aid of such applications, it is possible, for example, to match the assigned authorizations with the defined functional separations automatically in order to identify possible SoD conflicts.
Regardless of whether they are preventive, detective, manual or automatic controls, it is crucial for the sustainable implementation of segregation of duties that control activities are carried out on a regular basis and not just once. This is because authorization management is also an area that is subject to permanent changes due to changes of personnel, as well as adaptations to processes and related ongoing developments in standard business management software. In order to be able to provide a clear statement of current conflicts of functions and eliminate possible conflicts in a timely manner, the separations must be checked continuously.
‘SoD-Reporting’ category
The SoD reporting category includes both criteria that describe the analysis results, and criteria that address the cleaning up of the functional separation conflicts identified. This category is therefore also concerned with the sustainable implementation of the defined control framework. If, for example, the results of the most recent SoD analyses are compared with one another, the success or failure of SoD activities can be seen over the course of time. The timely elimination of identified conflicts is also taken into account. In this way, indicators for possible process improvements can be identified. In order to tackle the elimination of the identified weaknesses in a structured manner, it is also useful to prioritize individual SoD conflicts. Ideally, this is to be done by assessing the risks of the various SoD conflicts. It is important to assess these risk indicators according to the risk management process when changes are made to the rules and to adjust them if necessary. Depending on the risk indicators determined, escalation mechanisms should be implemented, which will lead to the elimination of the evaluated conflicts. It is useful to differentiate between the escalation mechanisms that address the actual risk indicators and the development over time of these risk indicators. For example: A high level of escalation must be selected for conflicts which have a high risk level and have already been present over a longer period of time in order to proceed with elimination with the corresponding degree of priority.
Providing the reporting system with additional key figures relating to process improvement, e.g. the number of duplicate payments leads to increased acceptance of the SoD process, in particular with the business unit responsible. Thanks to these key figures, the business departments are given new insights into their business processes. The resulting added value of the reporting ensures that an institutionalization of the SoD process within the company is pushed forward more intensively, particularly with regard to the maturity model.
‘Organizational Framework’ category
The criteria, which are summarized in the “Organizational Framework” category, are primarily related to assessing the awareness of the issue of process security within the respective company. This category plays a major role in the quality of the implementation of SoD processes, as it shows the extent to which the employees of an organization have internalized the importance of the topic and document this in their daily work. Even if so-called Computer Assisted Audit Techniques (CAATs) are used to support the above-mentioned automation of SoD activities, the dedication of employees is still essential in many areas. After all, all the rules, controls and reporting are only as good as the employees who are responsible for their design and implementation.
One criterion for the assessment of the degree of maturity is organizational responsibility for the SoD process. This is often problematic in the area of segregation of duties. The employees of the IT department are typically responsible for the topic of “ERP security”. However, since they are not owners of the operational processes, they cannot adequately assess who is to be assigned what rights or where possible conflicts may arise. The employees of the business departments as business process owners are generally lacking the technical understanding necessary for the maintenance, allocation and verification of authorizations. Therefore, the separation of duties in standard business management software is also a task that should be firmly rooted in the way things are done throughout the whole company. Such an integrated approach will also be evident in any authorization allocation process that has been properly implemented from an audit perspective. The responsibility for the assignment of authorizations should be assigned to the respective business area, while, due to the technical complexity of the task, their implementation should be assigned to employees of the IT department. There should also be an active separation of duties in this process. If changes occur in the ERP system, approval by the business unit is not sufficient due to the far-reaching consequences. For such purposes, so-called “Role Owners” must be defined according to the data-owner concept, who, thanks to the competence at their disposal, are qualified to assess the necessity and the consequences of a role change.
Other criteria that can be used to assess the SoD process are the definition of objectives, as well as the involvement of company management. If management is kept regularly informed about the development of SoD conflicts, this topic can end up being given increased priority within the company. Most importantly, in the case of the elimination of weaknesses, support from the company management is necessary, since such alterations to processes often meet with resistance within the company. By devoting closer attention to such issues, management can have a positive impact on employee attitudes. If, in addition, incentives are set to achieve objectives, for example, through bonus payments, which are linked to key figures, such an approach strongly emphasizes the interest that the company management takes in the area of SoD. Furthermore, it is also a clear statement of company’s intention is to continually improve its performance with regard to SoD. A process-oriented incentive system is an indicator of a mature organization.
What solutions does zapliance offer?
Zap Audit contains a comprehensive set of rules for the analysis of the actual segregation of duties in SAP. We don’t simply tell you what could happen and then just leave it at that. Instead, we allow you to gain a full picture of the actual segregation of duties within your company, based on your SAP data. It is this approach that makes us absolutely unique on the market.
In the next blog post, you will learn more about maturity levels and the 31 questions to carry out a self-assessment.
