ISACA Journal Author Blog

ISACA > Journal > Practically Speaking Blog > Posts > Segregating Duties in the IT Function

Segregating Duties in the IT Function

| Published: 12/17/2012 8:41 AM | Permalink | Email this Post | Comments (0)

Tommie W. Singleton, Ph.D., CISA, CGEIT, CITP, CPA

Segregating duties in the IT function is almost as important as segregating duties in the accounting function. The problem is the conflict among effective segregation of IT duties and the way the IT function is normally organized and the manner in which entry-level IT professionals progress in their careers.

Normally, IT staff progression is junior programmer, senior programmer to systems analyst. A focus on these job descriptions leads to a systems analyst who is segregated from the tasks performed by programmers. The system analyst does provide information requirements to the programmers, and usually provides feedback and input into the product being developed. This structure, thus, does provide some segregation.

However, better segregation of duties (SoD) would be to separate new systems development from systems maintenance. This more effective approach has two drawbacks for most IT functions. First, this approach forces the IT function to divide its programming staff. Many, if not most, IT directors will be reticent to divide programmers into the phases of application life cycle. Second, some IT functions believe it provides more quality products to have programmers and analysts focus on a subset of programs. For instance, one group will focus on accounting applications, another on customer service applications and another on some type of internal operations applications. That will probably lead to higher productivity and higher quality. However, it is contrary to effective SoD. In this approach, there is a significant loss of SoD as a small number of IT staff members have almost absolute control over all steps of a set of applications.

Why would the IT auditor insist on SoD that separates new application development from systems maintenance? There are two primary reasons:  First, proper SoD leads to more and better application and systems documentation. If a small group of programmers and a systems analyst are responsible for the accounting applications, they naturally develop some specialization that operationally is efficient and effective. However, the downside is the motivation to properly document the applications and systems—after all, it is within the same group that did the development and the maintenance. But, if a programmer or group of programmers were forced to pass code on from development to a different programmer or group of programmers for maintenance, proper documentation would be necessary for programmers who are unfamiliar with a particular application and were not a direct part of the group that did the coding to perform the required tasks associated with maintenance. Thus, proper SoD leads to better documentation.

Second, without ideal SoD, a programmer could go rogue and put fraud or malicious code into an application, and since the same programmer does the maintenance, there is little or no chance that a “second pair of eyes” will detect the attack—no accountability function. Therefore, the likelihood of fraud or malicious code is higher than with ideal SoD. With ideal SoD, a rogue programmer who puts malicious code in an application runs the risk of being discovered by the independent maintenance programmer.

Thus, ideal SoD as recommended in my recent Journal column is clearly a superior way to organize the IT function.

Read Tommie Singleton’s recent Journal column:
What Every IT Auditor Should Know About Proper Segregation of Incompatible IT Activities,” IT Audit Basics column, ISACA Journal, volume 6, 2012


There are no comments yet for this post.