Separation of Duties

Separation of duties is used to restrict work and system access to a narrower focus. This principle is more difficult to provide in a smaller organization than in a larger organization, but it is an important concept to understand and to address. Read the section on separation of duties to understand how this concept prevents individuals from attacking systems on their own and requires collusion with other individuals to commit fraud. How does separation of duties protect against fraud? What are some mechanisms that can be used to enforce separation of duties?

Separation of duties (SoD) is the concept of having more than one person required to complete a task. It is alternatively called segregation of duties or, in the political realm, separation of powers.

***WARNING*** WARNING about SOD possible shortcomings ******

This approach can lead to a high level of difficulty when trying to determine the underlying causes of errors or failures in a large-scale entity's production automation as no person will be able to view the information flow process from the "big picture" and how an automated program starts an application that is not creating the correct output data but not clearly failing to an error message alert running on a Virtual Server client that transports the data file that is created to an outside client and etc. etc. etc. Especially as each separated department individual will just glance at their application software used to manage their specified section on their monitor screen and seeing no obvious errors assume the unknown error causing complete system or process failure problem is not within their section and go back to the practice of effective communicating while writing all the great accomplishments they delivered that furthered the entity's stated goals to have available for their next review with management because that's what HR told them to do. (Not that this behavior is faulty or wrong in any sense and it is actually doing what the entity's incentives are geared to encourage not only for advancement but to keep a job as well.)

Without those few and far between expert level techs who can have (or get) the administration rights to view all aspects of any given production process it will be nearly impossible to determine the underlying cause and can lead to outrageous decisions as to what the problem must have been. (For example: deciding to quit using all virtual servers and go back to multiple actual server machines with each connected to it's on monitoring all because no error handling was encoded in the in-house written .net program.) (Or nobody realizing the automated software machine was running into RAM issues because every automated job was set to auto start at exactly 6:00 and MS Windows has a built-in limit of a maximum of 10 network connections at one time even at the enterprise level and so forth.) ***These SOD positions are of no interest to those high-level technical experts who seek to be constantly challenged.***


  • SoD in basic terms that is no single individuals should have controls over two or more phases of a transaction or an operation so that a deliberate fraud is more difficult to occur because it requires collusion of two or more individuals or parties.
  • With the concept of SoD, business-critical duties can be categorized into four types of functions, authorization, custody, record keeping, and reconciliation. In a perfect system, no one person should handle more than one type of function.
  • In information systems, segregation of duties helps reduce the potential damage from the actions of one person. IS or end-user department should be organized in a way to achieve adequate separation of duties

Control Mechanisms to enforce SoD

There are several control mechanisms that can help to enforce the segregation of duties:

  • Audit trails enable IT managers or auditors to recreate the actual transaction flow from the point of origination to its existence on an updated file. Good audit trails should be enabled to provide information on who initiated the transaction, the time of day and date of entry, the type of entry, what fields of information it contained, and what files it updated.
  • Reconciliation of applications and an independent verification process is ultimately the responsibility of users, which can be used to increase the level of confidence that an application ran successfully.
  • Exception reports are handled at the supervisory level, backed up by evidence noting that exceptions are handled properly and in a timely fashion. A signature of the person who prepares the report is normally required.
  • Manual or automated system or application transaction logs should be maintained, which record all processed system commands or application transactions.
  • Supervisory review should be performed through observation and inquiry and the trust built with directory one-level up managers.
  • To compensate for repeated mistakes or intentional failures by following a prescribed procedure, independent reviews are recommended. Such reviews can help detect errors and irregularities but are usually expensive can raise questions as to how much can an outside independent review once a quarter know about your processes compared to people within and what level of trust can be built with those independent reviewers.

Creative Commons License This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Last modified: Thursday, April 15, 2021, 3:54 PM