Segregation of Duties (SoD) separates roles and responsibilities to ensure that an individual cannot process a transaction from initiation through to reporting without the involvement of others and thereby SoD reduces the risk of fraud or error to an acceptable level.
For example, no one individual should be able to set up a new supplier, raise a purchase order for that supplier, post and approve the invoice from that supplier, create, approve and record the payment to that supplier. This is because giving a single individual the ability to perform all of the above operations increases the risk of fraud or error.
A SoD project aims to ensure that conflicting activities that cannot be assigned to the same individual are appropriately segregated.
For example, this is a key part of achieving SOX/MiFID/ISO2100 compliance.
Segregation of duties is helped by the existence of an organisational structure, with defined roles and responsibilities so controls that ensure roles and responsibilities are assigned to individuals in a sufficiently segregated manner can be devised.

This tutorial provides guidance to enable the design of effective segregation of duties into business processes, and then to be able to test that the segregation of duties as designed is operating in practice.
The development and maintenance of effective segregation of duties is not solely an IT problem - some activities are performed outside of the ERP system, while others can be effectively enforced within the system. For example, a payment to a supplier may be authorised and released in the system, but the reconciliation of the bank account from which the payment is made may be performed and authorised manually.
The determination of appropriate segregation of duties is dependent upon the specific roles and responsibilities of individuals and the need to separate those roles and responsibilities appropriately to reduce the risk of error, or fraud. While this guidance has been developed to simplify (wherever possible) the complexities of achieving an appropriate segregation of duties, it will need to be tailored to the specific circumstances of any organisation that uses it by considering the specific conflicts within each process and controls and how those could result in fraud or error.
While this document uses examples and provides an approach for the achievement of an effective segregation of duties within the accounting fuction, and within one of the ERP systems, the principles within this document are applicable to all business processes and systems that require security. For example, extracts of security data can be taken from multiple ERP systems and merged so that SoD checks can take place (either manually or in an appropriate tool).

A SoD project can be split into three main steps:

Step 1 SoD Design Assessment

This step involves assessing the design effectiveness of segregation of duties within each process, whether manual or system based. The SoD design assessment involves the process owners / controllers determining whether their processes are designed such that the activities performed within each process and across each of the processes are appropriately segregated. The segregation achieved should separate roles and responsibilities to reduce the risk of error or fraud to an appropriate level. During this step, each activity will be classified to determine whether the segregation of duties is enforced manually, or whether it is enforced through the system. This classification is important to ensure that the design of the segregation of duties can be tested, in steps 2 and 3.

Step 2 SoD Operating Effectiveness (System)

The system based segregation of duties conflicts that are recorded from the design assessment will usually be tested using an IT tool (if it is one of the large ERP systems like SAP or Oracle, JD Edwards). This will involve running the tool and reviewing the resulting exception report to clear any SoD conflicts. The tool identifies conflicts by checking that the system accesses have been provided in accordance with the SoD requirements.
Note: In, for example, a branch office there may be difficulty in having meaningful segregation of duties of important tasks as these operations often do not have sufficient staff between which duties can be segregated. In these instances it is necessary to establish mitigating controls, usually after the checks that have been documented and operated. These checks are usually manual.

Step 3 SoD Operating Effectiveness (Manual)

This will involve checking that the manual segregations that have been documented are operating in practice. For example, if the SoD matrix identifies that the preparation of a bank reconciliation and its review are to be segregated manually, the person leading the SoD project needs to ensure that self-testing includes checking that there is clear evidence that the preparation and review of the bank reconciliation have been segregated, such as separate signatures. Subsequently, the SoD auditor will need to ensure that the testing results confirmed that appropriate segregation is being operated in practice.

1. Review the processes / controls / activities defined as in scope.
The review will not necessarily need to incorporate all the controls that exist but those that that require an authorisation/segregation of duties.
2. Identify the roles that are relevant to each process / control / activity, for example, the Budget Holder, Financial Controller, Senior Management, and so on. Once the relevant roles are identified, a matrix will need to be updated to reflect how the controls / activities are assigned across the roles that have been identified.
3. Categorise the type of controls / activities into manual (M) or system (S). The matrix will need to reflect how the activities / controls are performed in practice.
4. Evaluate the SOD. The determination of an appropriate segregation of duties is dependent upon the specific roles and responsibilities of individuals and the need to separate those roles and responsibilities appropriately to reduce the risk of error, or fraud.

A reasonable segregation of duties is:

• Having at least two people involved within each sub-process
• Having two people involved in certain controls (i.e. at times a single control is split into activities which have been assigned to different individuals, for example, preparation and review of a bank reconciliation)

Avoiding cross process conflicts

Exceptions that are identified as causing this risk should be noted. Not all occurrences where the actual segregation differs from the guideline segregation will result in exceptions. Exceptions need to be reviewed to determine if they, individually or in combination, create a unacceptable risk of fraud or error. 

Dealing with exceptions

An exception may or may not be a SoD issue and hence may or may not require some remediation to occur. An exception is not an issue if it has a satisfactory compensating control.

If a SoD exception has been identified and there is a need for remediation, the remediation plan needs to be documented, reviewed and authorised by a relevant individual. The remediation action should also have a target date and the reviewer of the remediation plan to ensure satisfactory completion should conduct relevant follow up.
If a SoD exception has been identified that has sufficient compensating controls, this must be sufficiently documented. The control is now one that is being relied upon to achieve compliance and hence should be included in the risk register.

Transition from design effectiveness review to operating effectiveness testing

Once the above steps related to design effectiveness are completed, the following should have been achieved:

• SoD matrix that details the correct roles for each control / process has been created.
• Any remediation issues should have been identified and an action plan developed
• Conflicts should be identified as a system-system, a system-manual, or a manual-manual conflict

Therefore, it should be clear which SoD controls are to be tested and how (manual or system). Manual and system operational testing provides assurance over the operating effectiveness of the segregation of duties that have been designed into processes

Regular analysis of application embedded segregation of duties controls is possible with the major main ERP systems, i.e. SAP, Oracle, JDE. This type of enterprise software provides tools to ensure that those carrying out the reviews and responsible for setting up security in each of the application systems can identify all users who are carrying out incompatible tasks in each of the ERP application and identify user accesses that violate SOX related segregation of duties.

Use of the system Tool

Each of the above systems have tools that work in the same manner. The following points should be noted prior to performing testing:

SoD testing that is to be performed using a system tool essentially involves reviewing system access settings to ensure they are in accordance with SoD requirements.

Testing for system-based SoD will have to be carried out for each different ERP system

The system reports, should list the following pieces of information:

• All user profiles that cause segregation of duties issues
• All individual users who's profile causes segregation of duties issues
• A report by individual conflict of all users who cause the conflict
• All users who can perform critical activities (explained below)
• All profiles included in the exclusion table
• The transactions assigned to system job roles and also the access to transactions of User ids of individual users and reports
• Relevant authorisations/roles which have conflicting transactions
• Users with access to conflicting transactions due to access to multiple roles.

System SoD testing should be performed by individuals with the appropriate technical expertise required to understand and run the tool.

Please note:

Deployment of a ERP system like SAP is almost always modified to cater to the local requirements of each business. This modification involves applying customised or bespoke transactions, which can either be based on a standard transaction or created specifically to suit local requirements. This analysis often has to be performed manually.

The two most common areas of focus for system testing are:

• Custom transaction codes being added to the system transaction groups, and
• Reviewing role pairs to formulate an accepted risk register.

System testing will provide a report listing all conflicts that are identified by the tool. It is expected conflicts will exist, particularly in small operations where it may be difficult to have meaningful segregation of duties. All conflicts identified can be dealt with in either one of the following ways:

The system access conflict that has been identified should be rectified, i.e., the access where the conflict exists should be changed.

A sufficient compensating control should be identified, documented and tested as part of the manual self-testing (explained below).

Manual SoD will need to be tested through the manual testing of controls. This involves:

Reviewing the documentation:

The manual testing of controls involves obtaining an understanding of the controls and ensuring that the appropriate individuals are involved and appropriate steps are followed in the operation of the process and controls as detailed within the process notes and other relevant documentation. For example, a walkthrough like this is used to verify that appropriate individuals have been involved in approving bank reconciliations through the inspection of signatures.

Testing for operating effectiveness enables process owners to conclude on SoD effectiveness within a process.

All SoD should have been tested via two means:

• Using the ERP system tool for testing system enforced segregation of duties
• Performing a walkthrough of manually enforced segregation of duties

Concluding on the above work will require the following steps to be followed:

1. The results of the design assessment exercise include listing of exceptions and relevant remediation plans will need to be prepared. Effective implementation of these remediation plans will allow conclusions to be drawn on the design effectiveness of SoD.
2. The results of the system testing should be available in the form of reports listing all exceptions that have been identified either by User, by Profile or by conflict. These exceptions have to be mitigated. The extent that these items are mitigated will govern the extent to which system based SoD can be deemed to be effective.
3. Manual SoD testing is performed separately to the above two steps. Hence, concluding on effectiveness of controls tested in this mode will require individuals responsible for SoD testing to refer to the results of the manual testing performed for the relevant controls.
4. Authorisation / Custody of assets / Recording / Control procedure: A 4-way segregation that needs to be achieved within each process. Every activity / control will fall into one of these four 'segregation types'

System testing is performed in 3 main instances:

1. Every time a new user is added to the system to determine if the profile that has been requested for the user is not in conflict of the SoD requirements.
2. Every time a user's profile is amended to determine if the change would cause a conflict with the SoD requirements.
3. On a periodic basis to review SoD in the relevant ERP system.

In each of the above instances, a specific process should be followed. This process and the relevant roles to execute these processes have been detailed below.

The requester should create a request containing the following information:

• The user's name
• The user's department code
• The roles required by the user

The requester will send the request to the user's Manager for approval.

The Manager will forward the request to the security team for approval.

The security team should vet the request for reasonableness, and verify that the resulting authorities will not contravene segregation of duties rules (by running the system tool).

If the request results in an identified risk, the security team would escalate the request to the process owner or any other delegated authority for approval.

If approved, the compensating controls would be logged by the security adviser.

After approval, the security adviser would file a copy of the request and forward it to the user administrator to be actioned.

Periodic testing of SoD

Every three months, the security team should carry out a segregation of duties scan of all users. The Security team and the relevant Process Owner should examine all reported exceptions and decide on an appropriate course of action. Exceptions identified in this scan would be dealt with in the same manner as defined above for new user additions.

It is important to maintain proper control and segregation of duties over performance of the testing. In particular, the testing procedures should involve at least three people under the following recommended roles:

Security Officer

The security officer for each application should directly report to the controller representing the organisation(s) using the application. The SO has following tasks/responsibilities

• Set security policy for the business aligned with company policy. Advisor for appropriate controls in the business processes
• Reviews changes that have been made by the profile and user administrators to make sure they comply with policy.
• Monitoring and follow up of emergency situations
• Provide evidence that compensating controls are in place when approving SoD violations.
• Checks if the access request contains critical access, which shouldn't be given to the user.
• Requesting role/profile changes to the security officer when existing roles/profiles do not exist or are not appropriate for granting the requested access. Organizes profile testing
• Regularly producing a list of all users with their roles, and forwarding this to departmental managers for review.
• Regularly scanning the user community for segregation of duties by running the SoD monitoring tool for the ERP system.

Role Administrator (IT)

who makes approved changes to roles and profiles on the development system and arranges for them to be tested and transported. The main duties of the Role Administrator are:

• Advising on the feasibility of proposed profile changes
• Devising the best method of achieving new requirements
• Making changes to roles and profiles and assist in the testing of them.
• Arranging for modified profiles to be transported to the test systems for testing and approval by the security officer and process owner

User Administrator (IT)

who creates and maintains user master records. The main duties of the user administrator are:

• Registering, maintaining and deleting users based on approved requests (line manager approval for the account and all used roles/profiles).
• Running SoD monitoring and critical access monitoring tool and submitting report to security adviser of all conflicts for all changes and additions to users before the changes can be used by the user.

These are transactions that can be classed as critical and users should have either limited or no access to these. In all system tools, these critical transactions feature in reports that detail each user who has access to them (either at transaction level or at a process level). The critical transactions list will need to be reviewed by the SoD security team for system-manual conflicts. For example, an appropriate segregation of duties is implemented between updating the vendor master (system), and reviewing the edit reports of updates to the vendor master (manual). If the individual who approves the edit report also had access to the update the vendor master then there would not be effective segregation of duties. Therefore, where there is a system-manual conflict, it would be necessary to review the access list to ensure that an appropriate segregation of duty is in place.