For the segregation of duties (SoD) library review to be thorough, the SAP user and approver community needs to have motivation, competence, and time to partake in the process. If any of the three prerequisites are lacking in quality or quantity, the SoD library review will be incomplete. For the SAP approver community to be motivated to review the SoD risk rules, they first need to understand the importance of the SoD principle.

Ensuring SoD Library Review Quality

Reviewing the SoD risk rules is not easy. Some training to pump up the competence is needed before anyone can do it. There are not many people who have intimate knowledge on end-to-end processes, let alone on parallel or possibly even overlapping processes. In matrix organizations, where people not only work for a unit but also a region or process, it is always better to have too many than too few people do the review. This way, different viewpoints are utilized. For the selected reviewers to have time for the review, it is paramount for companies to nominate correct people as reviewers. Reviewers should not act as “rubber stamps,” that is,  just approve anything suggested to them by SAP Notes or by IT teams to keep on top of their too numerous and varied tasks. When a possible risk rule reviewer is located, it may be a good idea to nominate someone from his or her team instead of the first person who comes to mind. That person will get the needed support from the person one level higher.

How to Educate the SAP User and Approver Community about the Importance of the SoD Principle

To put it simply, SoD is an internal control principle that needs to be considered when designing access to SAP systems. No SAP users should be able to change any data that is not related to their tasks, and no users should be able to manipulate consecutive steps in a chain of activities. Otherwise, money or goods might end up at incorrect addresses. Compromised access to SAP data could happen accidentally or on purpose (fraud). By complying with the SoD principle, companies make deliberate fraud more difficult because it requires collaboration of two or more persons. Another problem caused when users have maintenance access to data they are not supposed to be able to change is that incorrect data leads to incorrect reports. Some examples of possible SoD conflicts:

• Jussi can process vendor invoices and do goods receipt on a purchase order. In this example, Jussi would be able to enter fictitious vendor invoices and accept the goods via goods receipt.
• Ying can maintain the customer master and process customer invoices. In this example, Ying could make a change to the master data record (payment terms, tolerance level) in favor of the customer and enter an inappropriate invoice.

To help the SoD risk rule reviewers understand why SoD risks should not exist, it is important to speak their language. The following explanation makes sense to many business users: If SoD conflicts are not detected in time and accesses are misused, it could endanger the correctness of our financial data, cause financial losses for the company, and make the SAP environments unstable. Moreover, on top of sharing the SoD risk rules, it is worthwhile to show matrices of the risk functions conflicting with each other. Figures 1 and 2 are examples of such risk function matrices used in Nokia Siemens Networks.    

Scoping the SoD Library Update Project

A standard SoD library provided by SAP is meant to be used as the basis for a company-specific rule set. In 2008, Nokia Siemens Networks decided it was safer to start with the full rule set and disable rules it thought did not apply in its system. Nokia Siemens Networks’ team thought that by creating the risk rules from scratch it might overlook something and thus risk Sarbanes-Oxley compliance. It was a lot of work finding the correct people to participate, educating them about what needed to be done, and then reviewing the risk rules. In addition, a lot of time and effort was needed to clean up the accesses user accounts had, initiate process changes, and mitigate unavoidable SoD risks. After approximately two years of using the SoD library, Nokia Siemens Networks realized that in order to get full benefits out of the SoD detection tool, it needed to add its custom transaction codes into the SoD library. The company also needed to set up a process that ensured the risk rules stay up to date. It already had missed some update suggestions from SAP that were delivered via the SAP Notes since the IT users scanning them were not aware of whom to notify about such SAP Notes. How the risk rule changes are implemented into the SoD library affects the way that suggested changes can and should be reviewed. Because Nokia Siemens Networks had edited the risk rules, it decided it did not want to upload the newest SoD library from SAP (a .txt file) and thus override its custom changes. Instead the Nokia Siemens Networks team decided to look at each suggested risk rule change separately and enter the needed changes manually. This way, any changes already done to the risk rules were kept. Actions and permissions were visible before the updates, but actual effects on SoD count could only be seen after the SoD library was updated. Had Nokia Siemens Networks chosen to upload the latest SoD library from SAP, all its custom changes would have been overwritten, and it would have had to reenter them.

Reviewing the Possible SoD Risk Rule Changes

To review the needed changes to the SoD library, those changes have to be readily available. Nokia Siemens Networks split the work into two work packages: (1.) a review of the risk rules concerning standard SAP transactions and (2.) an assessment of the SoD relevance of custom transaction codes. After these lists were available, people were chosen to do the risk rule review in Nokia Siemens Networks. SAP Authorization responsibilities in Nokia Siemens Networks are split into four modules: IT, Finance and Control, Shared Accounting Services, and Logistics. Each module has a global authorization concept owner. These four persons coordinated the review with the template role owners and the composite role approvers. The project team made sure there were people looking at the risk rules from different viewpoints: conceptual, process related, and regulatory. The project team downloaded the current SoD library and compared it with the latest rule set, using the following SAP Notes released after Nokia Siemens Networks deployed the SoD library:

• 1604722 (Risk Analysis and Remediation Rule Update Q3 2011
• 1446680 (Risk Analysis and Remediation Rule Update Q2 2010
• 1326497 (Risk Analysis and Remediation Rule Update Q2 2009

Most of the updates were Microsoft Word documents providing detailed summaries of changes. SAP suggested three types of updates: transactions added to risk functions, authorization object or permission changes, and suggestions to delete transactions from risk rules. Table 1 shows an example of each type.   To review the SoD relevance of custom transaction codes, the Rulebook update project team in Nokia Siemens Networks first downloaded all the transactions starting with letters Y or Z. These were found in table TSTC, using the field TCODE, which contains the technical name of transaction codes, and the field PGMNA, which shows programs linked to those transaction codes. Most of Nokia Siemens Networks’ custom transactions start an executable program. Examples of these programs are reports with data entry (selection screen) or data outputs (lists). Custom transactions may trigger standard reports, standard transactions, or custom reports or transactions. To narrow down the list of custom transaction codes Nokia Siemens Networks needed to review for SoD relevance, the Rulebook update project team excluded the transactions not assigned to a role, and thus not assigned to any user accounts currently. The team completed this step “manually” by looking at the tables. Only custom transactions that could cause harm were listed for addition to the SoD Library. Nokia Siemens Networks then outscoped reports located in the reporting tree from the SoD risk review because in its SAP system, reports are display only, without embedded functionality that enables creation or maintenance. On the remaining list of tailored transaction codes, Nokia Siemens Networks used the following criteria to identify SoD relevant custom transaction codes (further analysis was done on each of the short-listed transaction codes):

• Custom transaction code descriptions containing Create/Maintain/Changes/Upload
• Custom transaction codes triggering a standard transaction code that was already assigned to a risk function

Examples of custom transaction codes that were not listed for addition to the risk functions include custom transaction codes that upload data from Excel sheets. The actual postings are done by standard transaction codes. The team manually identified which custom transaction codes act as middlemen (i.e., trigger standard transaction codes). Concept owners and IT support teams were asked which transaction codes had caused a hassle before, and then tracing was used in nonproduction systems to establish what the custom transaction codes actually do. The next step was to identify which risk function each SoD relevant custom transaction belonged to. Nokia Siemens Networks initially looked at the naming of transaction codes. If the transaction description included pricing, for example, the project team reviewed the possibility to add the transaction code to risk function pricing. Unfortunately, Nokia Siemens Networks found that its naming convention was not bullet-proof and with some tailored transaction codes, many comment rounds were needed to find the correct risk function. The final decision on the SoD relevance was made by the risk owner of the possible SoD risk. SoD risk owners are listed in the RAR tool. For each risk function, Nokia Siemens Networks finally held a change approval meeting with the relevant risk owner. The other participants were the authorization concept owners, IT security experts, and the internal controls team members. Nokia Siemens Networks is only now deploying compliant user provisioning (CUP) so the workflow options there could not be utilized.

Dealing with SoD Conflicts Emerging after an SoD Library Update

After the SoD library was updated, the work was not done. A lot of new SoD conflicts were detected on the SAP user accounts. To deal with them Nokia Siemens Networks used the following action paths (sometimes more than one alternative was needed to deal with the reported SoD conflicts):

1. Removing false positives (i.e., working with SoD risks being reported due to incorrect risk rule modifications)
2. Removing one or more of conflicting roles from user accounts where the accesses are not needed
3. Removing one or more transaction codes from the (template) roles, possibly by transferring them to other (template) roles
4. Initiating process changes (i.e., transferring tasks from one team or unit to another)
5. Editing the SoD Library (e.g., disabling a risk rule that does not apply in an SAP system)
6. Starting an SoD conflict mitigation process for conflicting accesses that cannot be avoided

Removing False Positives

As with all applications, human errors are possible, and sometimes the SoD count shown may be incorrect. An SAP BusinessObjects Access Control tool only reports what it is configured to report. In the first SoD conflict report after the SoD library update, the SoD count was a lot higher than Nokia Siemens Networks had expected. After investigation, Nokia Siemens Networks realized that the people entering the risk rule changes to the SoD library had not been trained well enough, and some of the risk rules had only been entered on the transaction level, not the permission level. When the permission levels (activity values) were added, the SoD count was significantly lower.

Removing One or More Roles from User Accounts

I believe that in many companies, more emphasis is placed on accesses missing from a user account than on assigned accesses that are not being used. Sometimes roles or accesses just are added as organizations or task splits change, without removing the accesses that become unneeded. In these cases, getting rid of the SoD conflicts is quite easy.

Removing Transaction Codes from Template Roles

The process of setting up and maintaining a SAP security structure is like playing with a puzzle. It is necessary to keep the number of roles down to a manageable level while giving all the access needed by end users. Several users with different access needs may have similar role assignments, but actually have different tasks. Nokia Siemens Networks’ role setup was done way before Nokia Siemens Networks took the SAP BusinessObjects GRC tools into use, and the “logic” of how transaction codes are assigned to template roles is not fully compatible with the risk function setup in the SoD library. In many cases replacing a template role with another, or even splitting a template role into two and only assigning both of them to users that actually need them, helped in removing multiple SoD conflicts from user accounts.

Initiating Process Changes

Detecting SoD risks may make process flaws visible and several adjustments of processes may need to be initiated. Nokia Siemens Networks’ team put a lot of effort in helping the user community see that global processes need to be followed because silo thinking can result in many SoD conflicts. For example, if a team makes shortcuts to speed its own processes up, such as taking on tasks that should be done by someone else, it may result in multiple unnecessary SoD conflicts. Nokia Siemens Networks also learned that when trying to clean up problematic transaction accesses, some time allotment needs to be reserved for snowball effects – a small change somewhere might mean that bigger adjustments are needed elsewhere.

Editing the SoD Library

The SoD library can be edited so that access combinations of specific transactions or functions are not reported as a violation of the SoD principle. Nokia Siemens Networks disabled some risk rules on transaction or permission level without actually removing the risk rules. In the future Nokia Siemens Networks’ needs and views may change, and thus, it wants to keep the door open for taking those risk rules back to use.

Mitigating Unavoidable SoD Risks

In Nokia Siemens Networks, SoD conflicts can be mitigated using operative internal controls, if the conflicting accesses are actually controlled via a control point (i.e., any suspect data changes will be discovered). For some of the newly emerged SoD conflicts that were somewhat related to SoD conflicts Nokia Siemens Networks’ user community already had had before, Nokia Siemens Networks already knew which internal control points could be used.

Making Sure the SoD Library Stays Up-to-Date

As part of the RAR Rulebook Update project Nokia Siemens Networks set up a process for semiannual reviews of the SoD library. The project team identified that the roles shown in Figure 3 have responsibilities in the maintenance process.  

• System administrators check for possible rule updates in SAP Notes. System administrators list the custom transaction codes created after the last update approval.
• The internal controls team ensures SoD risk owner nominations are up-to-date.
• The internal controls team invites an access and authorization governance body to a meeting where they review what needs to be done and decide on who does what. As important as sticking to the update process is, making sure the role approver and end-user community understand why the SoD principle exists and identifying and involving the correct people in different parts of the organization in the SoD risk rule review are just as important. This means educating any newcomers on authorization principles and processes and making sure everyone understands their role in keeping access to SAP systems clean.

It is easy to agree that company data needs to be protected against fraud and mistake. However, finding the balance between data security and the ease of end users’ daily tasks is not always easy to accomplish. Nokia Siemens Networks put a lot of emphasis on making the risk rule reviewers see that if the accesses were reviewed well now, and any unneeded accesses removed, requests for added accesses in the future could be handled faster. If shortcuts are used and too many SoD risks mitigated as unavoidable in the review and clean-up phase, the number of SoD conflicts will only increase when a new transaction access is needed owing to a process change.