11/10/2020 Segregation of Duties

AICPA.org

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 nance 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:

https://www.aicpa.org/interestareas/informationtechnology/resources/value-strategy-through-segregation-of-duties.html 1/4
11/10/2020 Segregation of Duties

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 nes 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 classi cations 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 les 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
les 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
Authorization Custody of Assets Dev.

Create queries X X S/W Engineer

Approve calculations & logic X QA X

Approve Sys. access Security / Controller X X

Push to Production

Post journal entries Controller Staff Accountant X

Approve journal entries Sr. Accounting Mgr. Controller X

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 ve
basic steps to all change management that need segregated management and process steps to maintain a
proper risk management model:

https://www.aicpa.org/interestareas/informationtechnology/resources/value-strategy-through-segregation-of-duties.html 2/4
11/10/2020 Segregation of Duties

1. initiation of change with appropriate authorization.

2. Project management oversight of the change process.
3. Tracking of changes to key process steps.
4. Corresponding management and risk controls must be developed and documented.
5. 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 con dentiality 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 nancial
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 o ce 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:

1. 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.

https://www.aicpa.org/interestareas/informationtechnology/resources/value-strategy-through-segregation-of-duties.html 3/4
11/10/2020 Segregation of Duties

2. The data load process from the physical inventory to the new software application was heavily in uenced
by the operations manager and provided cover to conceal the vast difference between book and systems
counts at the point of transition.
3. The segregation between review and approval of the data load and nal 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 rm 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 les.

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.

Association of International Certi ed Professional Accountants. All rights reserved.

Terms & Conditions (/privacyandterms/website-terms- Privacy Site Map
conditions.html) (/privacyandterms/privacy.html) (/content/aicpa/sitemap.xml)

https://www.aicpa.org/interestareas/informationtechnology/resources/value-strategy-through-segregation-of-duties.html 4/4