Home
 > Research and Reports > TEC Blog > Segregation of Duties and Its Role in Sarbanes-Oxley Comp...

Segregation of Duties and Its Role in Sarbanes-Oxley Compliance Issues

Written By: Alexander Hankewicz
Published On: August 27 2008

<

In the aftermath of some highly publicized cases of corporate fraud, the US government announced legislation designed to implement compliance and financial-reporting standards. The most notable of these laws is the Sarbanes-Oxley Act (SOX) of 2002. The primary goal of SOX is to enforce a higher level of transparency into organizations' business processes, financial transactions, and accounting methods, to ensure that known and accepted accounting principles are practiced.

In this new SOX era, the issue of compliance spans several industries, attempting to harmonize evolving standards across both public and private sector organizations. The requirement of standardized reporting of financial information now forces organizations that had once been less transparent to tighten and streamline their audit and control practices on an ongoing basis.

Traditional Audit and Compliance Standards Prior to SOX

Pre-SOX standards were designed to ensure a modicum of corporate governance by focusing on the areas outlined by the Committee of Sponsoring Organizations (COSO) and on an IT system process framework. This framework was provided by the Control Objectives for Information and Related Technology (COBIT) IT process standard, which was developed in 1992 by the Information Systems Audit and Control Association (ISACA). COBIT was to provide adequate control levels for organizational structure, ethical standards, and board and audit committee review. It was the earliest set of audit standards established to cope with IT processes and audit procedures. COBIT focused on application controls, general control of information systems, and security issues.

Reporting standards used prior to SOX remain in place today. Of these, the most notable are the EU's adopted version of the International Financial Reporting Standards (IFRS) and the US's Generally Accepted Accounting Principles (GAAP). In 2002, an accord known in financial industry circles as the Norwalk Agreement was struck. This agreement states that US-based companies' financial-reporting procedures are to be harmonized with the European standard by the end of 2008. The implementation of SOX for firms that import into and export out of the United States is yet another layer of compliance standards recently introduced. Table 1 lists several other audit control standards, both pre- and post-SOX.

Regulation

Purpose/Target Industry

SOX

publicly traded US companies

ISO 17199

IT security standards

Canadian bills 198, 52-109, and 52-111

Canada 's SOX equivalents

Basel II Accords

G8 regulations for international banking

Health Insurance Portability and Accountability Act (HIPAA)

US health and medical industries

Office of Management and Budget (OMB) Circular A-123

US government agency financial standards

Solvency II

European insurance industry standards

IFRS

European accounting standards

Office for Economic Co-operation and Development (OECD) principles

EU agencies of internal controls

GAAP

US-based generally accepted accounting principles

Table 1. Key audit control standards.

Segregation of Duties

Within SOX is a provision entitled Section 404. This section is a comprehensive list of accepted internal controls organizations must have in place to be deemed SOX-compliant. The list targets application internal controls and highlights areas where fraudulent reporting is likely to occur, whether intentional or not. Among key provisions in this section is segregation of duties (SOD). SOD aims to close loopholes that would otherwise permit questionable accounting practices; one of its key attributes is that it allows the monitoring of processes and cross-verification of transactions processed in real time.

In simplified terms, SOD is based on the concept of having more than one person in an organization that is able and mandated to complete a task. SOD is a security principle whose main goals are the prevention of fraud and errors. These two objectives are realized through the reviewing of business processes and the dissemination of tasks and associated authorizations among several levels of hierarchy. Such actions serve as validation—in other words, they are a series of checks and balances.

One way to illustrate the key tenets of SOD is to consider an accounting department in any small to medium business (SMB). Here, some of the day-to-day activities include the receiving of checks as invoice payments, approval of employee time cards, processing of payroll checks, and reconciliation of bank statements. Within these activities a form of SOD is already in place—usually the issuing of checks requires different levels of authorization and more than one signature. In essence, more than one person validates a process or activity.

In terms of IT, SOD issues are not as clearly defined, and in many instances, individuals in an SMB have multiple levels of responsibility, which can call into conflict the stated goals of SOX and SOD.

Following are five circumstances in which IT processes can conflict with the goals of SOD:

  1. Improper account provisioning for change, meaning access rights to applications are not changed (revoked) when employees leave the organization or a department.

  2. Insufficient control of change management issues, meaning a change is made to a financial application or process without documented record of the date the change occurred, the nature of the change, and which persons in the organization are impacted by the change, for quality assurance purposes.

  3. IT departments lack an understanding of key system configuration workflow processes.

  4. No audit logs are used to document unusual system or application occurrences.

  5. No root cause analysis is performed to determine what caused an unusual event.

Twin Pillars of Protection

In any organization, IT serves as both the gatekeeper and the distribution point for information. Financial-reporting serves as the means to support an IT infrastructure. Insofar as systems infrastructure and financial reporting are linked, the requirement to ensure the integrity of the system and the processes that support it are in compliance with accepted standards and practices. Within these twin pillars of protection are principles that must be adhered to in order to ensure the integrity of the system, the public's confidence in the system, and that all key requirements of SOX Section 404 are met. Figure 1 depicts the basic steps to take to meet these requirements.

Figure 1. Key elements to support SOX and SOD.

1. Study business control processes.

Below are three of the primary business control processes essential to support SOX compliance:

  1. Controls found within most ERP systems—these controls reconcile orders processed only with prescribed customer credit limits. All goods shipped have an associated invoice.

  2. General IT controls—these allow authorized individuals access control to order management and receivables applications. This process ensures that system upgrades and fixes are documented.

  3. Manual controls—these controls ensure that only authorized individuals can alter or cancel a customer order.

2. Develop and automate internal testing to support the system.

Most organizations typically run financial reports on a monthly and a quarterly basis, reporting the organization's performance in terms of budget and projected sales. To ensure compliance to SOX-SOD requirements, these two procedures are essential:

  1. Using internal data to ensure that no sales or financial records can be altered without being identified, logged, and reviewed by three levels of authorization.

  2. Reviewing examples of where individuals contravene SOD requirements (e.g., persons who perform procurement activities cannot also be involved in the receiving of inventory and the posting of accounts payable).

The purpose of this exercise is to demonstrate that an internal, documented process exists to segregate responsibilities and prevent any ability to alter or destroy financial-related data.

3. Analyze test results with known compliance standards (e.g., COBIT, COSO).

When organizations are in the process of selecting enterprise software applications (e.g., an ERP system), due diligence is advised as part of the request for proposal (RFP) process to ensure that the proposed vendor's solution adheres to known financial-reporting and compliance standards in its industry. When interfacing a new solution with a legacy application or with an internally developed in-house system, the COBIT and SOX models should be the fundamental criteria for assessing whether the new system meets your organization's compliance and financial-reporting requirements. Following are some additional points to consider:

  • Data revision management—changes to financial-reporting data should be carefully managed, ensuring that all modifications are authorized and documented.

  • Contracts—all IT vendor contracts and service level agreements (SLAs), including their financial implications, must be clearly defined.

  • Third-party equipment—third-party software must abide by known and accepted standards. License and user requirements must be defined in vendors' contracts, as these requirements are also subject to known performance criteria indicated in the vendor SLA at the time of software purchase.

  • Access control—ensure users have an identifiable security password and user code, which tracks access and transactions performed.

  • Security—the system must be in compliance with ISO 17799 and designed in a way that limits disclosure or access to unauthorized parties.

  • Incident management—the system must record all incidents of failure or loss of data, and must support Information Technology Infrastructure Library (ITIL) guidelines. Corrective action to be taken must be documented so that it can be retrieved, and the work performed by another person.

SOD Checklist

If your organization is planning to review its SOX- and SOD-readiness, then a good starting point is to obtain a copy of the ISACA's segregation of duties control matrix to use as a general guideline. If after reviewing the matrix you conclude that your company performs certain tasks that cannot be segregated, then you can implement a series of further controls. Below are a few separate control procedures to help achieve SOX-SOD compliance:

  • Ensure that transparent audit trails are in place, that management is aware of each individual's level of responsibility, and that corresponding authorization is established.

  • Ensure that information related to who did the work, who approved the work, and the date and time the activity was executed are documented in the audit trail.

  • Enable the ability to review transactions at random times, thus instilling confidence in the process.

A Final Word

The introduction of SOX is hoped to bring a new level of accountability to the corporate world. It is believed by many that from the cases of corporate fraud in the United States several years ago, a new opportunity has emerged for corporate America to show integrity and prove that the interests of customers, employees, and shareholders are its primary concern. The positive outcome in all of this has been that those running organizations realize that their companies are part of the community they serve, and unethical behavior will not be tolerated. The compliance aspects of SOX and SOD, though challenging to understand at first, limit the opportunity (or chance) for wrongdoing, and ensure that organizations employ streamlined and verifiable processes to run their business.

Stay tuned for an upcoming blog post that will feature TEC's own SOX-SOD compliance matrix. This checklist will highlight the key areas to review in order to determine your organization’s SOD-readiness, as well as show how your organization compares with industry standards.

 
comments powered by Disqus
Popular Searches

Recent Searches
Others A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

©2014 Technology Evaluation Centers Inc. All rights reserved.