Segregation of duties (SoD) is a hot topic of conversation among a range of professionals, from compliance managers to executive officers. The outpouring of interest in SoD is due, in part, to the requirements of the Sarbanes-Oxley Act in the US and other similar control-driven regulations worldwide. However, the key factor at work here is the principle that no individual should have excessive system access that enables him/her to execute conflicting end-to-end transactions.

 It is a basic internal control that attempts to ensure that no single individual has the authority to execute two or more conflicting sensitive transactions with the potential to impact the financial statements or confidential information. Without proper guidance and a sound approach, SoD testing, remediation and mitigation may appear to be a huge challenge. Sensitive transactions drive processes with the potential to impact a company’s financial statements. Though companies strive for zero SoD conflicts in their user population, separating discrete job responsibilities into task-oriented roles can often result in inefficiencies and unnecessary costs.

However, a risk-based methodology can make the effort manageable.

A Risk-Based Methodology

A risk-based methodology focuses on the issues that pose the greatest threat to the business and company’s financial statements. Whether the drivers for investing in SoD compliance are fraud prevention, regulatory compliance or a new enterprise resource planning (ERP) system, a company cannot eliminate every potential risk. The goal is to drill down on the issues that meet predefined thresholds of risk. These should be determined at the outset of the SoD initiative. Materiality, fraud thresholds or financially significant value limits are examples of thresholds that serve to measure the sensitivity of SoD conflicts.

The SoD Road Map

Most SoD initiatives consist of five phases:

1. Business Definition

The objective of this phase is to gain an understanding of the scope of sensitive transactions and conflicts that drive the company’s key business processes. These are the transactions that pose the greatest fraud risk to the organization should someone possess excessive access. For example, a company may be concerned about allowing the same individual to both create a vendor purchase order and modify the customer pricing master file. However, the combination of the two may constitute such a low risk that it does not warrant inclusion in the company’s conflict matrix
The matrix and corresponding risk statements differ among companies, industries, business models and even locations within the same company,

2. Technical Definition

The testing phase draws on data from the business definition and technical definition phases to produce an analysis of users with SoD conflicts. This report highlights the SoD conflicts in a number of ways, such as by user and by role/group, and shows the extent of the conflicts among the company’s user population.

The completed conflict matrix should help answer the identify applications that are able to execute the defined sensitive transactions and how are they executed in the system.  The company or business unit must map each sensitive transaction to its associated access rights in the application that enables that transaction. This critical step feeds the data analysis to yield the testing results.

3. Testing

The testing phase draws on data from the business definition and technical definition phases to produce an analysis of users with SoD conflicts. This report highlights the SoD conflicts in a number of ways, such as by user and by role/group, and shows the extent of the conflicts among the company’s user population.

4. Mitigation

The mitigation phase is completed concurrently with remediation, or, depending on the objectives and compliance time frame, mitigation can be performed last, once conflicts have been reduced to their absolute minimum. Mitigation has several critical success factors. Many companies choose to mitigate every potential conflict to establish a safety net of control should a conflict arise. This is a sound and practical strategy for companies looking to control unforeseen or unpredictable risk.

5. Remediation

The goal of this phase is the permanent correction of SoD conflicts. Remediation techniques include role redesign, role cleanup, user appropriateness review and SoD tool implementation. A combination of people, process and technology changes help sustain compliance.

There is no prescribed road map or universal method for remediation of conflicts. Each scenario is unique, depending on the degree of complexity and extent of the conflicts in a given environment. While the appropriate level of effort and emphasis needs to be placed on SoD compliance, companies must also strive for simplicity and precision in the execution of their controls. SoD presents a unique challenge to control compliance as it requires close alignment of business and IT stakeholders to identify, assess, reduce and monitor the risk of fraud or deceptive material.

Determining the right sample size for IT controls testing, Insights into industry standards / best practices

For manual controls, the frequency of the occurrence of the control is taken into consideration (daily, weekly, monthly, quarterly, and yearly). Also taken into account are the risks placed on the control (High/Medium/Low) and other factors based on the understanding of the control environment. These factors, listed below, drive the auditor to select a higher sample size

1. Complex controls prone to failure.
2. Controls where the significance of the judgments must be made in connection with its operation.
3. Controls over significant processes where the assessed risk of failure of the controls to operate effectively is higher than normal.
4. Controls that have a pervasive effect on other controls or processes.
5. Controls that are relatively more important (e.g., some controls may address multiple control area components).
6. Controls that are not protected by multiple layers of redundant controls.
7. Controls recently implemented or remediated.
   

Alternatively develop a simple matrix to select your sample size based on the risk ranging High-Medium-low and sample size also from small to high. 

The Modified Pareto's principle is also used for sample selection. In this, if the sample size exceeds 20 then random 20% of the dataset as sample size. If the number is <=20 take 100% as sample size. The dataset size/population is for the period under consideration (preferably >=quarter).

Another factor affecting sample size selection is the appetite for risk of organization to start with. Assess the risk and subsequently that would determine the amount of testing to be done.

There should be a separate plan to select controls that are being retested and this calls for a minimum time period and a minimum number of samples to be tested. For example...If a Daily Control is being retested there must be a minimum 20 day test period with a minimum of 10 samples pulled.

For automated controls reduce the sample size to what is appropriate to audit risk. If this is an environment that has a “good history” of audits IT Controls that have traditionally demonstrated high compliance ratios then the sample size is reduced based on good judgment. However, every automated control has some risk of failure and hence one needs to vary the sample size accordingly. It is also important to auditors that automated controls are operational and effective since this will provide assurance to auditors that information generated from the system is valid, accurate and complete. Based on this assurance from the system, auditors can then place the appropriate level of reliance on the controls of the information system.