Systems Development,Program Changes, and Application Controls:Systems Development Controls

Systems Development Controls

Chapters 13 and 14 presented the systems development life cycle (SDLC) as a multiphase process by which organizations satisfy their formal information needs. An important point at this juncture is that specific SDLC steps will vary from firm to firm. In reviewing the effectiveness of a particular systems development methodology, the accountant should focus on the controllable activities common to all systems development approaches. These are outlined in the following section.

CONTROLLING SYSTEMS DEVELOPMENT ACTIVITIES

This section and the one that follows examine several controllable activities that distinguish an effective systems development process. The six activities discussed deal with the authorization, development, and implementation of new systems. Controls over systems maintenance are presented in the next section.

Systems Authorization Activities

All systems should be properly authorized to ensure their economic justification and feasibility. This requires a formal environment in which users submit requests to systems professionals in written form.

User Specification Activities

Users need to be actively involved in the systems development process. The technical complexity of the system should not stifle user involvement. Regardless of the technology involved, the user should create a detailed written description of his or her needs. The creation of a user specification document often involves the joint efforts of the user and systems professionals. However, this document must remain a statement of user needs. It should describe the user’s view of the problem, not that of the systems professionals.

Technical Design Activities

The technical design activities translate user specifications into a set of detailed technical specifications for a system that meets the user’s needs. The scope of these activities includes systems analysis, feasibility analysis, and detailed systems design. The adequacy of these activities is measured by the quality of the documentation that emerges from each phase. Documentation is both a control and evidence of con- trol and is critical to the system’s long-term success. We discussed specific documentation requirements including designer, operator, user, and auditor documentation in Chapter 14.

Internal Audit Participation

To meet the governance-related expectations of management under SOX, an organization’s internal audit department needs to be independent, objective, and technically qualified. As such, the internal auditor can play an important role in the control of systems development activities. The internal auditor can serve as a liaison between users and the systems professionals to ensure an effective transfer of knowledge. An internal audit group, astute in computer technology and possessing a solid grasp of the business problems to be solved, is invaluable to the organization during all phases of the SDLC. Internal auditors should therefore become formally involved at the inception of the systems development process to oversee the definition of user needs requirements and appropriate controls. Furthermore, this involvement should continue throughout all phases of development and maintenance activities.

Program Testing

All program modules must be thoroughly tested before they are implemented. Figure 17-1 shows a pro- gram testing procedure involving the creation of hypothetical master files and transactions files that the tested modules process. The results of the tests are then compared against predetermined results to identify programming and logic errors. For example, a programmer testing the logic of the accounts receivable update module illustrated in Figure 17-1 might create an accounts receivable master file record for John Smith with a current balance of $1,000 and a sales order transaction record for $100. Before per- forming the update test, the programmer concludes that a new balance of $1,100 should result. To verify the module’s internal logic, the programmer compares the actual results obtained from the test with the predetermined results. This is a very simple example of a program test. Actual testing would be extensive and involve many transactions that test all aspects of the module’s logic.

The task of creating meaningful test data is time-consuming. This should not, however, be considered a single-use activity. As we shall later see, some aspects of application control testing require test data. To efficiently meet future audit objectives, test data prepared during systems implementation should be preserved. This will give the auditor a frame of reference for designing and evaluating future audit tests. For example, if a program has undergone no maintenance changes since its implementation, the test results from the audit should be identical to the original test results. Having a basis for comparison, the auditor can thus quickly verify the integrity of the program code. On the other hand, if changes have occurred, the original test data can provide a baseline for assessing the impact of changes. The auditor can thus concentrate tests of application controls on areas where computer logic was changed.

User Test and Acceptance Procedures

Prior to system implementation, the individual modules of the system need to be formally and rigorously tested as a whole. The test team should be composed of user personnel, systems professionals, and internal auditors. The details of the tests performed and their results need to be formally documented and analyzed. Once the test team is satisfied that the system meets its stated requirements, the system can be transferred to the user.

Many consider the formal testing and acceptance event to be the most important control over the systems development process. This is the last point at which the user can determine the system’s acceptability prior to it going into service. Whereas discovering a major flaw at this juncture is costly, discovering it during day-to-day operations may be devastating.

Audit Objectives Relating to Systems Development

The auditor’s objectives are to ensure that (1) systems development activities are applied consistently and in accordance with management’s policies to all systems development projects; (2) the system as originally implemented was free from material errors and fraud; (3) the system was judged necessary and

justified at various checkpoints throughout the SDLC; and (4) system documentation is sufficiently accurate and complete to facilitate audit and maintenance activities.

Tests of Systems Development Controls

The auditor should select a sample of completed projects (completed in both the current period and previous periods) and review the documentation for evidence of compliance with stated systems development policies. Specific points for review should include determining that:

• User and computer services management properly authorized the project.

• A preliminary feasibility study showed that the project had merit.

• A detailed analysis of user needs was conducted that resulted in alternative conceptual designs.

• A cost-benefit analysis was conducted using reasonably accurate figures.

• The detailed design was an appropriate and accurate solution to the user’s problem.

• Test results show that the system was thoroughly tested at both the individual module and the total system level before implementation. (To confirm these test results, the auditor may decide to retest selected elements of the application.)

• There is a checklist of specific problems detected during the conversion period, along with evidence that they were corrected in the maintenance phase.

• Systems documentation complies with organizational requirements and standards.

CONTROLLING PROGRAM CHANGE ACTIVITIES

Upon implementation, the information system enters the maintenance phase of the SDLC. This is the longest period in the SDLC, often spanning several years. Most systems do not remain static throughout this period. Rather, they undergo substantial changes that often constitute, in dollars, an amount many times their original implementation cost.

Little is served by designing and implementing controls over systems development activities if control is not continued into the maintenance phase. Maintenance access to systems increases the risk that logic will be corrupted either by accident or intent to defraud. To minimize the risk, all maintenance actions should require, as a minimum, four controls: formal authorizations, technical specifications, testing, and documentation updates. In other words, maintenance activities should be given essentially the same treatment as new development. The extent of the change and its potential impact on the system should govern the degree of control applied. When maintenance causes extensive changes to program logic, additional controls, such as involvement by the internal auditor and additional user test, and acceptance procedures may be necessary.

SOURCE PROGRAM LIBRARY CONTROLS

Even with formal maintenance procedures in place, individuals who gain unauthorized access to pro- grams threaten application integrity. The remainder of this section deals with control techniques and procedures for reducing this risk.

In larger computer systems, application program modules are stored in source code form on magnetic disks called the source program library (SPL). Figure 17-2 illustrates the relationship between the SPL and other key components of the operating environment. This material presumes an understanding of the program compilation process. If you are uncertain about the meaning of the terms source program, compiler, and load module, review the section on language translators on the book’s Web page located at www.cengage.com/accounting/hall.

Executing a production application requires that the source code be compiled and linked to a load module that the computer can process. As a practical matter, programs in their compiled state are secure and free from the threat of unauthorized modification. At this point, the source code is not needed for the application to run. In fact, we could destroy it if no future changes were ever to be made to the application. To make such a change, however, requires changing the logic of the source code on the SPL. This is then recompiled and linked to create a new load module that incorporates the changed code. Clearly, protecting the source code on the SPL is central to protecting the production application.

Figure 17-2 shows the SPL without controls. In this situation, access to application programs is completely unrestricted. Legitimate maintenance programmers or others may access any programs stored in the library, which has no provision for detecting an unauthorized intrusion. Because these programs are open to unauthorized changes, no basis exists for relying on the effectiveness of controls designed into them. Even testing these controls proves only that they work now, but says nothing about how they worked last week or last month. In other words, with no control over access to the SPL, a program’s integrity during the period in question cannot be established.

A CONTROLLED SPL ENVIRONMENT

Controlling the SPL requires SPL management system (SPLMS) software. Figure 17-3 illustrates this approach. The black box surrounding the SPL signifies the SPLMS, which controls four critical functions:

(1) storing programs on the SPL, (2) retrieving programs for maintenance purposes, (3) deleting obsolete

programs from the library, and (4) documenting program changes to provide an audit trail of the changes.

You may have recognized the similarities between the SPLMS and a database management system (DBMS). This is a valid analogy, the difference being that SPL software manages program files and DBMSs manage data files. The computer manufacturer may supply SPLMS software as part of the operating system, or the software may be purchased through vendors.

The mere presence of an SPLMS does not guarantee program integrity. Again, we can draw an analogy with the DBMS. To achieve data integrity, the DBMS must be properly used; control does not come automatically—it must be planned. Likewise, an SPL requires specific planning and control techniques to ensure program integrity. The control techniques discussed in the following section address the most vulnerable areas and should be considered minimum SPL controls.

Password Control

Password control over the SPL is similar to password controls in a DBMS. Every financially significant program stored in the SPL can be assigned a separate password. As previously discussed, passwords have

drawbacks. When more than one person is authorized to access a program, preserving the secrecy of a shared password is a problem. Because responsibility for the secrecy of a shared password lies with the group rather than with an individual, personal accountability is reduced.

Separation of Test Libraries

Figure 17-3 illustrates an improvement on the shared password approach through the creation of separate password-controlled libraries (or directories) for each programmer. Under this concept, a strict separation is maintained between the production programs that are subject to maintenance in the SPL and those being developed. Production programs are copied into the programmer’s library for maintenance and test- ing purposes only. Direct access to the production SPL is limited to a specific librarian group that must approve all requests to modify, delete, and copy programs.

An enhancement to this control feature is the implementation of program-naming conventions. The name assigned to a program clearly distinguishes it as being either a test or a production program. When a program is copied from the production SPL to the programmer’s library, it is given a temporary test name. When the program is returned to the SPL, it is renamed with its original production name. This technique greatly reduces the risk of accidentally running an untested version of a program in place of the production program.

Audit Trail and Management Reports

An important feature of SPL management software is the creation of reports that enhance management control and support the audit function. The most useful of these are program modification reports, which describe in detail all program changes (additions and deletions) to each module. These reports should be part of the documentation file of each application to form an audit trail of program changes over the life of the application. During an audit, the reports can be reconciled against program maintenance requests to verify that only approved changes were implemented. For example, if a programmer attempted to use a legitimate maintenance event as an opportunity to commit program fraud, the unauthorized code changes would be documented in the program modification report. These reports can be produced as hard copy or digital and can be governed by password control, thus limiting access to management and auditors.

Program Version Numbers

The SPLMS assigns a version number automatically to each program stored on the SPL. When pro- grams are first placed in the libraries (at implementation), they are assigned version number zero. With each modification to the program, the version number is increased by one. For instance, after five authorized maintenance changes, the production program will be Version 05, as illustrated in Figure 17-3. This feature, when combined with audit trail reports, provides a basis for detecting unauthorized changes to the application program. An unauthorized change is signaled by a version number on the production load module that cannot be reconciled to the number of authorized changes. For example, if 10 changes were authorized but the production program is Version 12, then two possible control violations may have happened: (1) authorized changes occurred, which for some reason went undocumented, or (2) unauthorized changes were made, which incremented the version numbers. We will discuss this issue in more detail later.

Controlling Access to Maintenance Commands

Powerful maintenance commands are available for most library systems that can be used to alter or eliminate program passwords, alter the program version number, and temporarily modify a program without generating a record of the modification.

There are a number of legitimate technical reasons why systems designers must sometimes use these commands. If not controlled, however, maintenance commands open the possibility of unauthorized, and perhaps undocumented, program modifications. Hence, access to the maintenance commands themselves should be password controlled, and management or an IT security group should control the authority to use them.

Audit Objectives Relating to Systems Maintenance

The auditor’s objectives are to determine that (1) maintenance procedures protect applications from unauthorized changes, (2) applications are free from material errors, and (3) program libraries are protected from unauthorized access.

The tests of controls necessary to achieve each of these objectives are examined in the following section. The discussion assumes that the organization employs SPL software to control program maintenance. Without such software, achieving the audit objectives may be impossible. The procedures described here are illustrated in Figure 17-4.

Audit Procedures for Identifying Unauthorized Program Changes

To establish that program changes were authorized, the auditor should examine the audit trail of program changes for a sample of applications that have undergone maintenance. The auditor can confirm that authorization procedures were followed by performing the following tests of controls.

RECONCILE PROGRAM VERSION NUMBERS. The permanent file of the application should contain program change authorization documents that correspond to the current version number of the production application. In other words, if the production application is in its tenth version, there should

be ten program change authorizations in the permanent file as supporting documentation.1 Any discrepancies between version numbers and supporting documents may indicate that unauthorized changes were made.

CONFIRM MAINTENANCE AUTHORIZATION. The program maintenance authorization should indicate the nature of the change requested and the date of the change. The appropriate management from both computer services and the user departments should also sign and approve it. The auditor should con- firm the facts contained in the maintenance authorization and verify the authorizing signatures with the managers involved.

Audit Procedures for Identifying Application Errors

The auditor can perform three types of tests of controls—reconcile the source code, review the test results, and retest the program—to determine that programs are free from material errors.

RECONCILE THE SOURCE CODE. Each application’s permanent file should contain the current program listing and listings of all changes made to the application. These documents describe in detail the application’s maintenance history. In addition, the nature of the program change should be clearly stated on the program change authorization document. The auditor should select a sample of applications and reconcile each program change with the appropriate authorization documents. The modular approach to systems design (creating applications that comprise many small discrete program modules) greatly facilitates this testing technique. The reduced complexity of these modules enhances the auditor’s ability to identify irregularities that indicate errors, omissions, and potentially fraudulent programming codes.

REVIEW THE TEST RESULTS. Every program change should be thoroughly tested before being implemented. Program test procedures should be properly documented as to the test objectives, test data, and processing results. The auditor should review this record for each significant program change to establish that testing was sufficiently rigorous to identify any errors.

RETEST THE PROGRAM. The auditor can retest the application to confirm its integrity. We examine several techniques for application testing later in the chapter.

Audit Procedures for Testing Access to Libraries

The existence of a secure program library is central to preventing errors and program fraud. One control method is to assign library access privileges only to system librarians. Their function is to retrieve applications from the program libraries for maintenance and to restore the modified programs to the library. Thus, maintenance programmers test applications in their private libraries but do not have access to the program library. The auditor may perform the following tests of controls to assess program library security.

REVIEW PROGRAMMER AUTHORITY TABLES. The auditor can select a sample of programmers and review their access authority. The programmer’s authority table will specify the libraries a programmer may access. These authorizations should be matched against the programmer’s maintenance authority to ensure that no irregularities exist.

TEST AUTHORITY TABLE. The auditor may violate the authorization rules in an attempt to access unauthorized libraries to test the programmer’s access privileges. The operating system should deny any such attempt.