February 2009

Segregated Duties in Fashion

Auditors help Benetton tailor an automated process for greater control over conflicting functions.

Roberto Taiariol, CISA
Chief Internal Auditor

In 2007, Japan-based electronics company NEC discovered a US $18 million fraud carried out by 18 people. “The fraudulent transactions involved the trading of intangible assets such as services and construction,” according to a May 31, 2007, CFO.com report. “The company explained that the fraud was not discovered for some time because the system enabled validation of the orders through confirmation by the same employees that made the orders.”

This kind of fraud, where an individual has the ability to perform conflicting functions — such as receiving cash and performing the bank reconciliation, or having custody of inventory and approving write-offs — has been a common problem for organizations around the world for many years. Examples range from an embezzlement of US $16,000 by a cashier at an Indonesian automotive dealership to the activities behind a €4.9 billion (US $6.9 billion) fraud allegedly committed last year by a trader at French bank Société Générale. The control required to prevent individuals from having conflicting functions is commonly referred to as segregation of duties (SOD).

In addition to the business need to limit fraud risk, the U.S. Sarbanes-Oxley Act of 2002 and similar regulations in other countries have compelled companies to focus on SOD controls to meet internal control over financial reporting requirements. Organizations must find a way to turn such regulatory requirements into a strategic advantage; otherwise, the project simply will be treated as yet another tactical compliance issue. However, establishing SOD controls is not easy. There is not always a clear owner for a SOD control. The IT function generally is responsible for the security of the network but typically does not own the data or know who should be assigned what role (i.e., combinations of functions that can be performed within the systems). Similarly, business process owners are responsible for staffing and performing the work but may not understand the technology within the applications.

Moreover, building a SOD control process that is effective, efficient, and adds value to the business is a challenge with multiple dimensions:

  • Responsibilities for performing functions within an organization change constantly. People leave or are transferred, and new staff are hired. This can result in SOD conflicts that require continual monitoring and correction.
  • A conventional SOD program involves identifying and reporting SOD conflicts, to which management has to react. This involves understanding the nature of the conflicts and removing unnecessary capabilities, without impacting the users’ ability to perform their assigned duties. In a conventional SOD program, there are almost always some level of conflicts, which may be an issue for Sarbanes-Oxley compliance.
  • A conventional SOD process can be a heavy consumer of limited resources.

Benetton, a fashion apparel company listed in Milan, implemented a successful SOD process in response to an internal audit that identified the need for improved SOD controls. Benetton management decided to optimize the company’s SAP enterprise resource planning (ERP) system’s security and access rights by implementing a continuous monitoring system with the audit function’s aid.


Because implementing an effective solution would require the involvement of all groups that were potentially responsible for SoD compliance, management saw that there would be a risk to the project if there was not solid program management and leadership. Benetton’s SAP financial manager was made project leader, with a strong advisory role for internal auditing. The auditors’ first question was “who is responsible for SOD compliance?” Potential answers included: 

  • Process owner. Certainly, the process owner has a role to play, but a SOD project involves many processes and requires knowledge of the IT environment. For example, what is an SAP profile, what are the data objects, and what access rights have been granted?
  • IT security manager. Similarly, IT security should be involved, but its personnel doesn’t necessarily have detailed knowledge of the processes and the access rights to be granted to each user.
  • SAP financial manager. As the interface between users and the IT department, this person is responsible for ensuring the best solution for the business. The financial manager has more of a facilitating role than one where ownership of user access rights and SOD compliance should be placed.
  • IT people. IT personnel may be responsible for access rights administration, but they often have limited knowledge of business processes and user access needs.

The project team concluded that SOD is a collective responsibility, with different departments responsible for functions such as administration of the access entitlement process and validating rights. Although some aspects of SOD were not automated (e.g., custody of assets), the project focused on managing the risk of incompatible access rights in the ERP system. The project’s deliverables were to implement access controls to prevent SOD problems. This system encompasses a wide range of business transactions and provides a security mechanism that enables a granular level of user access. Benetton has about 400 users of the SAP Financial modules, with approximately 50 commonly used transactions. Each transaction requires at least two authorization objects. When combined with the number of roles and profiles, there is an enormous number of possible access combinations.

To help resolve these issues, the project team installed SAP’s Access Control solution and its Risk Analysis and Remediation module, which enables real-time management and prevention of SOD problems. The project was implemented in phases to minimize business disruptions.

Identification of Key SOD Requirements
Some organizations use a checklist or catalog of typical SOD conflicts to determine which potential conflicts to monitor. Benetton used a risk-based process to identify the combination of ERP functions that would represent a risk to the business. These combinations were then converted to rules that defined the mix of functions to be monitored.

Preliminary Analysis of the Conflict Rules
Analysis of the status of the conflict rules for each user yielded surprising results. The software identified profiles with a wide range of object authorizations (i.e., users with multiple access rights) and no clear linkage between user responsibilities and the access profiles they had been assigned. That situation was resolved by reviewing and rationalizing the profiles. The project team removed from profiles access to transactions that were unrelated to the tasks users were required to perform. Before modifying the profiles, the team took the precaution of verifying that the user had not performed those transactions in the past six months. These first fixes did not create any problems for the users, who typically were not aware they had unnecessary, and potentially conflicting, access rights.

Process Owner Risk Acceptance
The remaining conflicts were reviewed one-on-one with each process owner. A report showing the authorized transactions for each profile and usage statistics allowed the process owners to know which transactions needed to be maintained in the profiles and which could be removed. In addition, minor changes in the flow of the process or some organizational adjustments were made to reduce the number of conflicts. Further, the process owner was required to approve the remaining risks and sign a list of the conflicts not yet resolved. Managing the project this way made the process owner the true project leader for his or her process, responsible for ongoing changes to that process.

New Profiles
In parallel to previous steps, the IT Department built a large number of more narrowly defined SAP objects authorizations. This allowed the team to design each user’s access profile very precisely and to manage SOD by ensuring each user or group of users had a profile to meet its business needs.

Fine Tuning
After a monitoring period, a second cleanup phase was performed with the process owners. This phase built on the lessons learned during the previous activities, as well as the redesign of some organizational processes and their related business functions. Where an SOD conflict could not be avoided — due to organizational constraints, for example — the risk was assessed and manual compensating controls were defined.


Since the project’s implementation, Benetton has used continuous access rights monitoring to provide real-time alerts to the IT department, which are reviewed and resolved with the process owners. In addition, each month, the IT security manager circulates to all process owners a report detailing the number of users with role conflict rules — highlighting the differences from the previous month’s report — and a list of SOD conflict alerts for the month, ranked by level of importance, showing which users and transactions were involved.

Benetton’s SOD project has reduced the level of SOD conflict rules in the SAP Financial modules by 98 percent. Throughout the project, internal auditing advised the project team, demonstrating its ability to influence change within the organization, as well as to reduce the risk of fraud and other potential risks. Benetton is now checking SOD in one of its mainframe systems.
Although a software tool will not solve all SOD issues, it helps in identifying them precisely and quickly. Management must be proactive in resolving the conflicts as they are identified by the tool.

Roberto Taiariol, CISA, is chief internal auditor for Benetton in Ponzano Veneto, Italy.

To comment on this article, e-mail the author at roberto.taiariol@theiia.org.

Share This Article:    


Internal Auditor is pleased to provide you an opportunity to share your thoughts about the articles posted on this site. Some comments may be reprinted elsewhere, online, or offline. We encourage lively, open discussion and only ask that you refrain from personal comments and remarks that are off topic. Internal Auditor reserves the right to edit/remove comments.





To make something bold:
<strong>Text to bold</strong>

To make something italic:
<em>Text to italicize</em>

To make a hyperlink:
<a href="URL">Text to link</a>


Subscribe_June 2014 



IIA Academic_Nov 2013

IIA SmartBrief

 IIA Vision University



facebook IAO