Segregation of Duties
Segregation of Duties (SOD)
Segregation of Duties (SOD) is a basic building block of sustainable risk management and internal controls for a business. The principle of SOD is based on shared responsibilities of a key process that disperses the critical functions of that process to more than one person or department. Without this separation in key processes, fraud and error risks are far less manageable.
Imagine what would happen if the keys, lock and code for a nuclear weapons system were all in the hands of one person! Emotions, coercion, blackmail, fraud, human error and disinformation could cause grave and expensive one-sided actions that can’t be corrected. Or, consider the software engineer who has the authority to move code into production without oversight, quality assurance or access rights’ authentication.
Without SOD, either of these scenarios clearly shows the possibility of disastrous outcomes. As a result, the risk management goal of SOD controls is to prevent unilateral actions from occurring in key processes where irreversible affects are beyond an organization’s tolerance for error or fraud.
Modeling SOD Controls
Take a look at Figure 1. The framework for SOD in developing an accounting and finance report might look like this. The boxes with an ‘X’ represent the functions that cannot be carried out by the same person. For example, the Engineer who develops the queries for a report should not be the one who approves the logic or accuracy of those queries.
Similarly, authorization of Journal Entries cannot be carried out by the same person who posts journal entries from this report. This simple model grows more complex when the “Push to Production” or release management phase comes into play.
SOD in Risk Management
Every organization has a certain tolerance for risk. Risks for successful ventures, risks of losses from fraud or error, market risks and legal risks all have different “preference curves”’ in any given organization.
A preference curve maps out a relationship between the probability of a risk occurrence and the amount of economic value at a point where an organization would be indifferent to the occurrence. So, if a 50 percent probability for a $20,000 loss was on the indifference curve for Company A, then the company may live with that risk without spending resources to create controls to lower the probability of the occurrence. Using SOD control concepts generally lowers risk and helps keep an organization at or under its preference for a given risk type.
Circle of Experts
Subject matter experts in corporate law, information systems and special forensic service providers use SOD tools and frameworks when managing business risks in technology through audit. Here are several examples:
e-Discovery is a records management challenge where SOD principles must be implemented and audited to ensure effectiveness. What’s the risk exposure if this is not handled properly? Serious fines were levied on companies who cannot comply with subpoenas that contain requests for documentation under the new e-discovery laws, including the ability to maintain proper chain of custody protocols. e-Discovery:
- ensures the function of tape librarian is separate from the function of system administration,
- ensures the requests for document preservation of certain records can only come from the general counsel, and
- maintains a document retention program where classifications of documents are maintained for archiving and disposal time periods.
The Management of Access Controls for super administrative rights of operating systems (known as the “root” level access) is a substantial challenge for any IT controls environment. It prevents unauthorized access to key systems and databases because:
- it keeps the group of administrators small and tightly managed (with secure log files to record activities where possible),
- it uses a pseudo root log wherever possible, and
- it supports the activities with policy and procedural statements that prohibit administrators from reviewing files and folders with operational and business content.
Use the “roles and responsibilities” function within software applications wherever possible, and maintain an SOD workbook of each framework (as in Figure 1) for all key processes. An advanced organizational control will interface the Human Resources organization chart with the SOD workbook to create a very strong control mechanism and a simultaneous management tool for allocating resources and managing to budgets. If roles and responsibilities are not followed, the opportunity for collusion cannot be controlled within an organization’s risk preferences or within any acceptable framework.
Figure 1
Managing Change
Change management in software development life cycles, network operations and IT Security Departments use the concepts of SOD to ensure proper approvals and release to production processes. There are five basic steps to all change management that need segregated management and process steps to maintain a proper risk management model:
- initiation of change with appropriate authorization.
- Project management oversight of the change process.
- Tracking of changes to key process steps.
- Corresponding management and risk controls must be developed and documented.
- Management oversight and approval for implementation of changes into “production.”
In addition, the CoBIT ( Control Objectives for Information and related Technology) description for push to production or release management should be well understood: “ In addition, application developers should not be able to promote code into production. If this control does not exist, unauthorized changes to software could result. In addition, uncontrolled and/or unauthorized changes to business information may lead to fraud and irregularities. Finally, malicious programs can be introduced into the production environment, affecting system availability, data integrity and information confidentiality issues.”
Case Study #1: Accounting Software and Operational Systems Control: An Opportunity for Fraud
The general manager of a corporate distribution network of heavy refrigeration equipment found that system inventory counts within the accounting software did not match to physical inventory calculations. Book count is generally expected to equal the system count of inventory as a basic audit check for accuracy in financial reporting. Book inventory accounting is based on the last physical inventory conducted within a business unit. The count is used as a basis to add purchases and subtract cost of sales in order to calculate the current ‘ending’ inventory.
Month after month, the operations manager kept pointing to problems in the old accounting software. The accounting manager kept running the book calculations with variances against the system counts that she could not explain. To help address the issue, the general manager made a business case to corporate executives for a new, integrated accounting software package and requested accounting support from the corporate office for implementation. The software was purchased and implementation was quickly put on track to enable production over the next several months.
When the annual physical inventory came, due within the same annual period, the general manager mandated that the system inventory valuations must equal book inventory valuations at the beginning of each monthly period. The general manager made the operations manager directly accountable for this control from that point forward.
The operations manager suggested that the annual inventory be coordinated with the transition to the new accounting software. In turn, the general manager accepted this suggestion as a pragmatic solution.
The old and new accounting systems ran parallel for a few months and, at the transition point, the operations manager worked closely with the accounting manager to ensure that “Book” matched “System” inventory valuations, and began operating under the new accounting software.
Much to the general manager’s disappointment, variances between the two inventory valuations continued and book value climbed. The operations manager came under severe scrutiny and corporate staff auditors were dispatched to the distribution center. Requests for supporting documentation of the last inventory were requested. At this point, the operations manager stopped showing up for work and was not returning phone calls.
Shortly thereafter, it was discovered that a theft ring was being conducted by the operations manager. The variances described were due to stolen inventory in the amount of several million dollars, or about 3 percent of the assets on the subsidiary’s balance sheet. The fraudulent activity was covered up for two years by the lack of SOD in three areas:
- The operations manager had inventory responsibility and administration access to the accounting software. This gave him the ability to plug the inventory at the point of transition to the new system.
- The data load process from the physical inventory to the new software application was heavily influenced by the operations manager and provided cover to conceal the vast difference between book and systems counts at the point of transition.
- The segregation between review and approval of the data load and final push to production were not conducted correctly. This was an error on the part of the general manager.
SOD in the implementation of new software is where this problem became super charged; the inventory problem was swept under the rug during the data load!
Case Study #2: Sales Processes and Managing Data: A Revenue Recognition Risk
A very technically savvy sales rep for an advertising firm built an advertising revenue model that only he understood. The revenue was based on selling access to a large customer base to potential advertisers and then broadcasting advertising messages to those customers.
The sales rep would sell the deals, write the insertion orders for the broadcasted content and report to accounting on the closed and delivered deals. Many times, these deals were structured with a barter component.
Clearly, the sales rep had too much control over too many of the components of revenue recognition - he created fraudulent insertion orders that he would have his trading partners sign to complete the barter transaction.
However, the trading partners never delivered their commitments to the insertion orders, and the sales rep was the only one who understood the broadcast e-mail system, including how to access log files.
This fraudulent activity went undetected until the trading partner was sold to another corporation. The new management of the trading partner was presented with insertion orders that did not have proper supporting documentation. In turn, management decided to call the sales rep’s company to discuss the matter.
It was only at this time that this $900,000 dollar scheme was uncovered!
What's the lesson? Watch out for the segregation between revenue and technical operations.
Be Wary and Watchful
While SOD seems a simple process, not properly following it can lead to disastrous consequences, evidenced by the two case studies above. As CPAs, you have the knowledge to make certain SOD is properly implemented within your own organization, as well as your clients’ and customers' businesses.
