IT Controls Part I,Sarbanes-Oxley and IT Governance:IT Governance Controls

IT Governance Controls

IT governance is a broad concept relating to the decision rights and accountability for encouraging desirable behavior in the use of IT. Although important, not all elements of IT governance relate specifically to control issues that SOX addresses and that are outlined in the COSO framework. In this chapter, we consider three governance issues that do: organizational structure of the IT function, computer operations, and disaster recovery planning.

The discussion on each of these governance issues begins with an explanation of the nature of risk and a description of the controls needed to mitigate the risk. Then, the audit objective is presented. This establishes what needs to be verified regarding the function of the control in place. Finally, example tests of controls are offered that describe how auditors might gather evidence to satisfy the audit objective. These control objectives and associated tests may be performed by internal auditors providing evidence of management’s compliance with SOX or by external auditors as part of their attest function. In this regard, we make no distinction between the two roles.

Organizational Structure Controls

Previous chapters have stressed the importance of segregating incompatible duties within manual activities. Specifically, operational tasks should be separated to:

1. Segregate the task of transaction authorization from transaction processing.

2. Segregate record keeping from asset custody.

3. Divide transaction-processing tasks among individuals so that fraud will require collusion between two or more individuals.

The tendency in an IT environment is to consolidate activities. A single application may authorize, process, and record all aspects of a transaction. Thus, the focus of segregation control shifts from the operational level (transaction processing tasks that computer programs now perform) to higher-level organizational relationships within the IT function. The interrelationships among systems development, application maintenance, database administration, and computer operations activities are of particular concern.

The following section examines organizational control issues within the context of two generic models—the centralized model and the distributed model. For discussion purposes, these are presented as alternative structures; in practice, the IT environments of most firms possess elements of both.

SEGREGATION OF DUTIES WITHIN THE CENTRALIZED FIRM

Figure 15-3 presents an organizational chart of a centralized IT function. A similar organizational chart was presented in Chapter 1 to provide the basis for discussing IT tasks. It is reexamined here to study the control objectives behind separating these tasks. If the positions represented in this chart are unfamiliar, you should review the relevant sections in Chapter 1 before continuing.

Separating Systems Development from Computer Operations The segregation of systems development (both new systems development and maintenance) and operations activities is of the greatest importance. The responsibilities of these groups should not be com- mingled. Systems development and maintenance professionals acquire (by in-house development and purchase) and maintain systems for users. Operations staff should run these systems and have no involvement in their design and implementation. Consolidating these functions invites fraud. With detailed knowledge of an application’s logic and control parameters along with access to the computer operations, an individual could make unauthorized changes to application logic during execution. Such changes may be temporary (on the fly) and will disappear with little or no trace when the application terminates.

Separating the Database Administrator from Other Functions

Another important organizational control is the segregation of the database administrator (DBA) function from other IT functions. The DBA is responsible for a number of critical tasks pertaining to database se- curity, including creating the database schema, creating user views (subschemas), assigning access authority to users, monitoring database usage, and planning for future expansion. Delegating these responsibilities to others who perform incompatible tasks threatens database integrity. Figure 15-3 shows how the DBA function is organizationally independent.

SEPARATING THE DBA FROM SYSTEMS DEVELOPMENT. Programmers create applications that access, update, and retrieve data from the database. Chapter 9 illustrated how database access control is achieved through the creation of user views, which is a DBA responsibility. To achieve database access, therefore, both the programmer and the DBA need to agree as to the attributes and tables (the user view) to make available to the application (or user) in question. If done properly, this permits and requires a formal review of the user data needs and security issues surrounding the request. Assigning responsibility for user view definition to individuals with programming responsibility removes this need to seek agreement and thus effectively erodes access controls to the DBMS.

Separating New Systems Development from Maintenance

Some companies organize their systems development function into two groups: systems analysis and programming. This organizational alternative is presented in Figure 15-4. The systems analysis group works with the user to produce a detailed design of the new system. The programming group codes the programs according to these design specifications. Under this approach, the programmer who codes the original programs also maintains them during the maintenance phase of the systems development life cycle. Although a popular arrangement, this approach promotes two potential problems: inadequate documentation and fraud.

INADEQUATE DOCUMENTATION. Poor-quality systems documentation is a chronic IT problem and a significant challenge for many organizations seeking SOX compliance. There are at least two explanations for this phenomenon. First, documenting systems is not as interesting as designing, testing, and implementing them. Systems professionals much prefer to move on to an exciting new project rather than document one just completed.

The second possible reason for poor documentation is job security. When a system is poorly documented, it is difficult to interpret, test, and debug. Therefore, the programmer who understands the system (the one who coded it) maintains bargaining power and becomes relatively indispensable. When the

programmer leaves the firm, however, a new programmer inherits maintenance responsibility for the undocumented system. Depending on its complexity, the transition period may be long and costly.

PROGRAM FRAUD. When the original programmer of a system is also assigned maintenance responsibility, the potential for fraud is increased. Program fraud involves making unauthorized changes to pro- gram modules for the purpose of committing an illegal act. The original programmer may have successfully concealed fraudulent code among the thousands of lines of legitimate code and the hundreds of modules that constitute a system. For the fraud to work successfully, however, the programmer must be able to control the situation through exclusive and unrestricted access to the application’s programs. The programmer needs to protect the fraudulent code from accidental detection by another programmer performing maintenance or by auditors testing application controls. Therefore, having sole responsibility for maintenance is an important element in the duplicitous programmer’s scheme. Through this maintenance authority, the programmer may freely access the system, disabling fraudulent code during audits and then restoring the code when the coast is clear. Frauds of this sort may continue for years without detection.

A Superior Structure for Systems Development

Figure 15-3 presents a superior organizational structure in which the systems development function is separated into two independent groups: new systems development and systems maintenance. The new systems development group is responsible for designing, programming, and implementing new systems projects. Upon successful implementation, responsibility for the system’s ongoing maintenance falls to the systems maintenance group. This structure helps resolve the two control problems described previously.

First, documentation standards are improved because the maintenance group will require adequate documentation to perform their maintenance duties. Without complete documentation, the formal transfer of system responsibility from new systems development to systems maintenance cannot occur.

Second, denying the original programmer future access to the application code deters program fraud.

Fraudulent code in an application, which is out of the perpetrator’s control, increases the risk that the fraud will be discovered. The success of this control depends on the existence of other controls that limit, prevent, and detect unauthorized access to programs such as source program library controls discussed in Chapter 17. Whereas organizational separations alone cannot guarantee that computer frauds will not occur, they are critical to creating the necessary control environment.

THE DISTRIBUTED MODEL

Chapter 1 examined the impact on organizational structure of moving to a distributed data processing (DDP) model in which end-user departments control IT services. The effect of this is to consolidate some computer functions that are traditionally separated and to distribute some activities that are consolidated under the centralized model. In spite of the many advantages DDP provides, the approach carries IT control implications that management and accountants should recognize. These are discussed in the following sections.

Incompatibility

Distributing responsibility for the purchases of software and hardware can result in uncoordinated and poorly conceived decisions. Organizational users, working independently, may select different and in- compatible operating systems, technology platforms, spreadsheets, word processing, and database pack- ages, which can impair internal communications.

Redundancy

Autonomous systems development activities throughout the firm can result in the creation of redundant applications and databases. Programs that one user creates that could be used with little or no change by others will be redesigned from scratch rather than shared. Likewise, data common to many users may be reproduced, resulting in a high level of data redundancy.

Consolidating Incompatible Activities

The redistribution of IT functions to user areas can result in the creation of many very small units. Achieving an adequate segregation of duties may be economically or operationally infeasible in this set- ting. Thus, one person (or a small group) may be responsible for program development, program maintenance, and computer operations.

Acquiring Qualified Professionals

End users are typically not qualified to evaluate the technical credentials and relevant experience of prospective IT employees. Also, because the organizational unit into which these candidates are entering is small, opportunities for personal growth, continuing education, and promotion are limited. For these rea- sons, distributed IT units may have difficulty attracting highly qualified personnel.

Lack of Standards

For the aforementioned reasons, standards for systems development, documentation, and evaluating performance tend to be unevenly applied or nonexistent in the distributed environment.

CREATING A CORPORATE IT FUNCTION

The completely centralized and the fully distributed models represent extreme positions on a continuum of structural alternatives. The needs of most firms fall somewhere between these end points. For these firms, the control problems associated with DDP can, to some extent, be overcome by implementing a corporate IT function. Figure 15-5 illustrates this organizational approach.

The corporate IT function is a leaner unit with a different mission than that of the centralized IT function shown in Figure 15-4. This group provides technical advice and expertise to the various distributed IT functions, as the dotted lines represent in Figure 15-5. Some of the support services provided are described in the following section.

Central Testing of Commercial Software and Hardware

The corporate IT group is better able to evaluate the merits of competing vendor software and hardware. A central, technically astute group such as this can evaluate systems features, controls, and compatibility with industry and organizational standards most efficiently. After testing, they can make recommendations to user areas for guiding acquisition decisions.

User Services

A valuable feature of the corporate group is its user services function. This activity provides technical help to users during the installation of new software and in troubleshooting hardware and software problems. The creation of an electronic bulletin board for users is an excellent way to distribute information about common problems and allows the sharing of user-developed programs with others in the organization. User services staff often teach technical courses for end users, which raises the level of user aware- ness and promotes the continued education of technical personnel.

Standard-Setting Body

Establishing central guidance can improve the relatively poor control environment common to the distributed model. The corporate group can establish and distribute to user areas appropriate standards for systems development, programming, and documentation that will be compliant with SOX requirements.

Personnel Review

The corporate group is better equipped than users to evaluate the technical credentials of prospective systems professionals. Although the prospective IT hires will work for the distributed user groups, the involvement of the corporate group in hiring decisions can render a valuable service to the organization.

AUDIT OBJECTIVES RELATING TO ORGANIZATIONAL STRUCTURE

The auditor’s objective is to verify that individuals in incompatible areas are segregated in accordance with the level of potential risk and in a manner that promotes a working environment. This is an environment in which formal, rather than casual, relationships need to exist between incompatible tasks.

AUDIT PROCEDURES RELATING TO ORGANIZATIONAL STRUCTURE

The following tests of controls would enable the auditor to achieve the control objectives.

• Obtain and review the corporate policy on computer security. Verify that the security policy is communicated to responsible employees and supervisors.

• Review relevant documentation, including the current organizational chart, mission statement, and job descriptions for key functions, to determine if individuals or groups are performing incompatible functions.

• Review systems documentation and maintenance records for a sample of applications. Verify that maintenance programmers assigned to specific projects are not also the original design programmers.

• Through observation, determine that the segregation policy is being followed in practice. Review operations room access logs to determine whether programmers enter the facility for reasons other than system failures.

• Review user rights and privileges to verify that programmers have access privileges consistent with their job descriptions.