CHAPTER 17

Chapter 17 Page 558Chapter 17 Page 645

CHAPTER 17

IT Controls Part III: Systems Development, Program Changes, and Application Controls

REVIEW QUESTIONS:

1.Systems development controls:

a.systems authorization activities

b.user specification activities

c.technical design activities

d.internal audit participation

e.program testing

f.user test and acceptance procedures

Systems maintenance controls:

a.technical specifications, authorization, testing, and documentation

b.source program library controls

2.All program modules must be thoroughly tested before they are implemented. The test data must be designed such that all modules are tested. Oftentimes, hypothetical master files and transactions are created so that every possible situation can be tested. The results of the test are compared against predetermined results to identify programming and logic errors.

3.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 users view of the problem, not that of systems professionals alone.

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

5.The purpose of program testing in the SDLC is to test and verify all aspects of the program modules' logic.6.The simplest form of check digit is to sum the digits in the code and use this sum as the check digit. This allows the integrity of the code to be established during subsequent processing and for transcription errors and transposition errors to be detected.

7.All program modules must be thoroughly tested before they are implemented. A program testing procedure involving the creation of hypothetical master files and transactions files. The results of the tests are then compared against predetermined results to identify programming and logic errors.

8.Source program library (SPL) is a disk repository for storing application program modules in source code format. To make a program change requires first 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.9.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.10. When using 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 programmers 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.11.The SPLMS assigns a version number automatically to each program stored on the SPL. When programs 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.12.a.reconcile program version numbers

b.confirm maintenance authorization

13.a.reconcile the source code

b.review test results

c.retest the program

14.Auditing around the computer involves black box testing in which the auditors do not rely on a detailed knowledge of the applications internal logic. Input is reconciled with corresponding output. Auditing through the computer involves obtaining an in-depth understanding of the internal logic of the computer application. As transactions become increasingly automated, the inputs and outputs may become decreasingly visible. Thus, the importance of understanding the programming components of the system is crucial.

15.a.authenticity tests

b.accuracy tests

c.completeness tests

d.redundancy tests

e.access tests

f.audit trail tests

g.rounding error tests

16.EAM techniques use one or more specially programmed modules embedded in a host application to select and record predetermined types of transactions for subsequent analysis. This method allows material transactions to be captured throughout the audit period. The auditors substantive testing task is thus made easier since they do not have to identify significant transactions for substantive testing.

17.GAS allows auditors to access electronically coded data files of their clients, both simple and complex structures, and to perform various operations on their contents. GAS is popular for the following reasons:

a.the languages are easy to use and require little EDP background on the part of the user

b.it may be used on any form of computer because it is hardware-independent

c.auditors can perform their tests on data independent of a computer services professional

d.it can be used to audit the data files of many different applications

18.

Access tests, validity tests, accuracy tests, completeness tests, redundancy tests and audit trail tests.

19.Many times data have upper and lower limits to their acceptable values. For example, if the range of pay rates for hourly employees in a firm is between 8 and 20 dollars, this control can examine the pay rate field of all payroll records to ensure that they fall within this range.

20.The test determines that a value in one field, which has already passed a limit check and a range check, is reasonable when considered along with data in other fields of the record.

DISCUSSION QUESTIONS

1.An SPL environment can help to deter unauthorized changes to programs by implementing password-controlled libraries for each programmer where the passwords are frequently changed. Program modification reports are a powerful control for detecting and deterring any unauthorized program changes. These reports describe in detail all program changes that have been made. These reports should be reconciled against program maintenance requests to verify that only the changes requested were made. Another control SPLMS provides is the automatic assignment of a new program version number each time a program is changed. Maintenance commands can be used to mitigate all of the above controls since the commands can be used to alter/eliminate passwords, alter the program version number, and temporarily modify a program without generating a record of the modification. Management, or some security group, should tightly control the authority to use maintenance commands.

2.One example would be students grades. This information is considered confidential and private. The student, his/her advisor, and his/her professors should have access to this data. Other students should NOT have access to any students grade other than their own. Prospective employers or other universities should not have access to the grades without the permission of the student. Health information kept at the university health center should be considered private. Only the student and the health professionals should have access to these individual records unless consent is given by the student. University officials may receive summary health data regarding all students, but not individual students. Also, student transcripts that contain information regarding disciplinary probation should only be accessed by the student unless permission is granted by the student to release this transcript.3.Prior to system implementation, User Test and Acceptance Procedures provide formal and rigorous testing of the the individual modules of the system. 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 systems acceptability prior to it going into service. Whereas discovering a major flaw at this juncture is costly, discovering it later, during day-to-day operations, may be devastating.4.Prior to system implementation, User Test and Acceptance Procedures provide formal and rigorous testing of the the individual modules of the system. 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 systems acceptability prior to it going into service. Whereas discovering a major flaw at this juncture is costly, discovering it later, during day-to-day operations, may be devastating.

5.The salami fraud affects large numbers of victims, but each in a minimal way. The fraud scheme takes its name from the analogy of slicing a large salami (the total fraud) into many thin pieces. Each victim gets one of these small pieces and is unaware of being defrauded. For example, a programmer, or someone with access to the rounding program can modify the rounding logic to perpetrate a salami fraud as follows: at the point in the process where the algorithm should increase the current customers account (that is, the accumulator value is > +.01), the program instead adds one cent to the perpetrators account. Although the absolute amount of each fraud transaction is small, given the hundreds of thousands of accounts processed, the total amount of the fraud becomes significant over time.

6.The black box approach (also called auditing around the computer) does not require the auditor to create test files or to obtain a detailed knowledge of the applications internal logic. Instead, auditors analyze flowcharts and interview knowledgeable personnel in the clients organization to understand the functional characteristics of the application. With an understanding of what the application is supposed to do, the auditor tests the application by reconciling actual production transactions processed with output results. The output results are analyzed to verify the applications compliance with its functional requirements. Black box testing is feasible for applications that are relatively simple, with inputs and outputs that are easily reconciled. More complex applications, however, often draw input data from multiple sources, perform a variety of complex operations, and produce multiple outputs. These applications demand more intensive through-the-computer testing to provide the auditor with evidence of application integrity. Through-the-computer testing employs computer-assisted audit tools and techniques (CAATTs) and requires an in-depth understanding of the internal logic of the application under review.7.Test data should consist of a complete set of valid and invalid transactions. Incomplete test data may fail to explore critical branches of application logic and error checking routines. Test transactions should be designed to test all possible input errors, logical processes, and irregularities pertinent to the audit objective. Gaining knowledge of the applications internal logic sufficient to create meaningful test data represents a considerable investment in time. The efficiency of this task is improved, however, through careful planning during systems development. Systems designers should save for future use the test data created to test program modules during the implementation phase of the SDLC. If the application has undergone no changes since its initial implementation, then the current audit test results should equal the original test results obtained at implementation. If the application has been changed, the auditor need only create additional test data that focus on the areas of the program changes.

8.The primary disadvantage of test data techniques is that auditors rely on the clients IT personnel to obtain a copy of the production application under review. The risk here is that the IT personnel may intentionally or accidentally provide the auditor with the wrong version of the application. Audit evidence collected independently is more reliable than evidence the client supplies.

9.Auditors need to ensure that systems being developed in-house serve the needs of all users and that the risk of material errors in the systems being developed and those in use is acceptable.

10.a.Detecting that inadequate segregation of functions exists between programmers and operators

b.Finding different program versions running than expected based on documentation

c.Finding undocumented program maintenance

11.Embedded audit module (EAM) techniques use one or more specially programmed modules embedded in a host application to select and record predetermined types of transactions for subsequent analysis. As the selected transaction is being processed by the host application, a copy of the transaction is stored in an audit file for subsequent review. The EAM approach allows material transactions to be captured throughout the audit period. Captured transactions are made available to the auditor at period end or at any time during the period, significantly reducing the amount of work the auditor must do to identify significant transactions for substantive testing.

12.The test data method is used to establish application integrity by processing specially prepared sets of input data through production applications that are under review. The results of the test are compared with the expected results. The base case system evaluation extends the test data method; the test data set constrains all possible transaction types. Tracing is an electronic walk-through of the applications internal logic and analysis of the execution of each program command line for a specific transaction. An integrated test facility is an automated technique that enables the auditor to test an applications logic and controls during its normal operations by creating dummy transactions and files. This method promotes ongoing application auditing. Parallel simulation involves creating a simulation of the transaction processing system and then using actual transactions to determine if the results of the auditors processing reconcile with the organizations results.

13. When auditors rely on client IT personnel to produce flat files from their databases, they run the risk that database integrity will be compromised. For example, if the auditor is confirming accounts receivable, certain fraudulent accounts in the original database may be intentionally omitted from the flat file provided to the auditor. Auditors skilled in relational and object database technology can avoid this problem. Not surprisingly, public accounting firms are aggressively seeking employees with strong computer skills to accompany their accounting training.MULTIPLE CHOICE

1.D2.C3.C4.D5.E6.D7.A8.E9.C10.EPROBLEMS

1. The auditor will create the following test data and perform the following tests to evaluate the accuracy of inventory receipts in the receiving department.

a. Test data should consist of a complete set of valid and invalid inventory receiving transactions. Test transactions should be designed to test all possible input errors, logical processes, and irregularities pertinent to the audit objective. Results from testing will be in the form of routine output reports, transaction listings, and error reports that are normally produced by the application. In addition, the auditor must examine the updated master files to determine that inventory records have been correctly updated. The test results are then compared with the auditors expected results. The auditor will examine error report of rejected transactions, and a listing of the updated AR master file. Any deviations between the actual results and those the auditor has predetermined may indicate a logic error or control problem.

b. TESTING ACCURACY OF POSTINGS TO INVENTORY ACCOUNTS. The auditor would create a master file of inventory records (AR). The transactions would consist of a wide range of transactions to see if the control is functioning properly. This test data is used to see if approved transactions (are accurately posted to the inventory accounts in the test master files. The auditor verifies their accuracy by reviewing account balance reports produced by the inventory receiving application and reconcile them with the predetermined results. Discrepancies would indicate a logic error in the math calculation or an error that posts transactions to the wrong accounts.

c. TESTING THE THREE-WAY MATCH. This test involves creating two test master files: a purchase order file and a receiving report file. The transaction in this case is the suppliers invoice. The test data should be designed to contain discrepancies that fall both within and outside of acceptable limits, based on company policy. When the invoice is entered, the AP system should match the three documents (create a digital AP packet) and reconcile the quantities ordered with those received, and the invoice amount with the expected price. The auditor will reconcile both rejected and accepted invoices to determine that the control is functioning in accordance with company policy.

d. TESTING MULTILEVEL SECURITY AND ACCESS PRIVILEGES IN THE PURCHASES/AP SYSTEM. This test involves creating several master files: purchase order file; inventory file; receiving report file; and general ledger accounts for cash, inventory control, and AP control. The auditor then logs into the system under different roles and attempt to perform tasks and access data that are not authorized by the various roles. Failure to detect or prevent such attempts indicates a control weakness in the system.2.

Type of FraudExplanationIdentification and Description of

Protection Methods

a. Input

ManipulationInput manipulation requires the least amount of technical skill and almost no knowledge of how the computer system operates. Input documents are improperly altered or revised without authorization, e.g., payroll time cards/time sheets can be altered to pay overtime or an extra salary.Documentation and Authorization

Data input formats properly documented and authorized

Programmed terminal/user protection

Programs designed to accept only certain inputs from designated users, locations, terminals, and/or times of the day.

b. Program AlterationProgram alteration requires programming skills and knowledge of the program. The program coding is revised for fraudulent purposes, e.g., ignore certain transactions such as overdrafts against the programmers account, draw checks and have them sent to a falsely constructed account, grant excessive discounts to certain specified trade accounts, etc.Programmers should only make changes to copies of production source programs and data files, never to the actual production files.

Segregation of Duties

Computer operators should not have direct access to production programs or data files.

Periodic Comparisons

Internal Audit or some other independent group should have copies of the official programs, or access to the master programs, so as to periodically process actual data and compare the output with output obtained from normal operations. Any output changes would be indicative of unauthorized program changes.

Periodic comparisons of online programs to offline backup copies to detect changes.

c. File AlterationFile alteration occurs when the defrauder revises specific data or manipulates data files, e.g., fraudulently changing the rate of pay of an employee in the payroll master file via a program instruction; or transferring balances among dormant accounts to conceal improper withdrawals of funds.Restricted Access to Equipment/Files

Restrict access to the computer center.

Programmers, analysts, and computer operators should not have direct access to production data files.

Production data files are maintained in a library under the control of a librarian or database administrator.

Computer operators should not have access to applications documentation, except where needed to perform their duties, to minimize their ability to modify programs and data files.

d. Data TheftData theft can be accomplished by data interception over a network, by access to files and central databases, and by physical removal of data files and of hard copies of reports. With considerable amounts of information being transmitted over the Internet and private networks, data are vulnerable to interception. Data stored in corporate databases are subject to theft from privileged employees and external hackers. Individuals with physical access to secure areas may remove reports and hard copy printouts of files.Electronic sensitization of all library materials for detection if unauthorized removal from the library is attempted.

Sensitive transmitted and stored data should be encrypted using secured encryption methods such as RSA.

Access to data files should be password protected and authority tables should be created for personnel that accurately reflect their access needs and legitimate authority levels.

Audit trail software can be installed to monitor access attempts via networks and offsite locations.

e. SabotageThe physical destruction of hardware or software.Terminated employees immediately denied access to all computer equipment and information to prevent their ability to destroy or alter equipment or files.

Maintain backup files at secure off-site locations.

3.

Audit Plan

Operating System Controls

AUDIT OBJECTIVES RELATING ACCESS PRIVILEDGES

The objective of the auditor is to verify that access privileges are granted in a manner that is consistent with the need to separate incompatible functions and is in accordance with organizational policy.

AUDIT PROCEDURES

Review the organizations policies for separating incompatible functions and ensure that they promote reasonable security.

Review the privileges of a selection of user groups and individuals to determine if their access rights are appropriate for their job descriptions and positions.

Review personnel records to determine whether privileged employees undergo an adequately intensive security clearance check in compliance with company policy.

Review employee records to determine whether users have formally acknowledged their responsibility to maintain the confidentiality of company data.

Review the users permitted logon times. Permission should be commensurate with the tasks being performed.

AUDIT OBJECTIVES RELATING TO PASSWORDS

The auditors objective here is to ensure that the organization has an adequate and effective password policy for controlling access to the operating system.

AUDIT PROCEDURES

Verify that all users are required to have passwords.

Verify that new users are instructed in the use of passwords and the importance of password control.

Determine that procedures are in place to identify weak passwords.

Assess the adequacy of password standards such as length and expiration interval.

Review the account lockout policy and procedures. The auditor should determine how many failed-logon attempts are allowed before the account is locked.

AUDIT OBJECTIVE RELATING TO VIRUSES AND OTHER DESTRUCTIVE PROGRAMS

The auditors objective is to verify that effective management policies and procedures are in place to prevent the introduction and spread of viruses and other destructive programs.

AUDIT PROCEDURES

Through interviews with operations personnel, determine that they have been educated about computer viruses and are aware of the risky computing practices that can introduce and spread viruses and other malicious programs.

Review operations procedures to determine if floppy disks are routinely used to transfer data between workgroups.

Verify that system administrators routinely scan workstations and file servers for viruses.

Verify that new software is tested on standalone workstations prior to being implemented on the host or network server.

Verify that the current version of antiviral software is installed on the server and that upgrades are regularly downloaded to workstations.

AUDIT OBJECTIVES RELATED TO AUTOMATED AUDIT TRAILS

The auditors objective is to ensure that the auditing of users and events is adequate for preventing and detecting abuses, reconstructing key events that preceded systems failures, and planning resource allocation.

AUDIT PROCEDURES

The auditor can use general-purpose data extraction tools such as ACL for accessing archived log files to search for defined conditions such as:

Unauthorized or terminated user.

Periods of inactivity.

Activity by user, workgroup, or department.

Logon and logoff times.

Failed logon attempts.

Access to specific files or applications.

The auditor should select a sample of security violation cases and evaluate their disposition to assess the effectiveness of the security group.

AUDIT OBJECTIVES RELATED TO FAULT TOLERENCE

The auditors objective is to ensure that the organization is employing an appropriate level of fault tolerance.

AUDIT PROCEDURES

The auditor should determine if the level of RAID in place is adequate for the organization, given the level of business risk associated with disk failure.

If the organization is not employing RAID, the potential for a single point of system failure exists. The auditor should review with the system administrator alternative procedures for recovering from a disk failure.

Determine that copies of boot disks have been made for each server on the network in the event of a boot sector failure. Ensure that the disks are secured and access to them restricted to the system administrator.

System Maintenance Controls

AUDIT OBJECTIVES RELATED TO SYSTEMS MAINTENANCE.

The auditors objective is to detect unauthorized program maintenance (which may have resulted in significant processing errors or fraud) and 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.

AUDIT PROCEDURES FOR IDENTIFYING UNAUTHORIZED PROGRAM CHANGES.

To establish that program changes were authorized, the auditor should examine the audit trail of program changes and 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. 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 auditor should confirm the facts contained in the maintenance authorization and verify the authorizing signatures with the managers involved.

AUDIT PROCEDURES FOR IDENTIFYING APPLICATION ERRORS

Reconcile the Source Code.Each applications permanent file should contain the current program listing and listings of all changes made to the application. These documents describe in detail the applications maintenance history.

Review Test Results.Every program change should be thoroughly tested before being implemented. The auditor should review the 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.

AUDIT PROCEDURES FOR TESTING ACCESS TO LIBRARIES

The auditor should establish that the program library and private libraries are protected from unauthorized access by performing the following tests of controls.

Review Programmer Authority Tables.The auditor can select a sample of programmers and review their access authority. The programmers authority table will specify the libraries a programmer may access. These authorizations should be matched against the programmers maintenance authority to ensure that no irregularities exist.

Test Authority Table.The auditor should simulate the programmers access privileges and then violate the authorization rules by attempting to access unauthorized libraries. Any such attempts should be denied by the operating system.

Organizational Structure Controls

AUDIT OBJECTIVES RELATED TO ORGANIZATIONAL STRUCTURE

The auditors 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.

AUDIT PROCEDURES

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

4.One area to examine is whether Golden Gate has purchased and received a material amount of inventory and/or machinery in the last month and not yet received or paid the invoice. One plan would be to trace all (or a sample) of receiving reports during the last month and make sure that they are either included in an accounts payable journal entry (if invoice has been received) or in an adjusting entry for accruals (if invoice has not yet been received). Another area to examine is whether interest on notes, bonds, etc. have been accrued. An examination of all debt instruments will be necessary to determine if the appropriate interest has been accrued.

5.Potential exposureunauthorized changes to the application programs have been made, and that the EAMs have been turned off while the unauthorized application programs were being run.

The external auditors should make sure that:

1.strict control procedures are in place regarding program changes; all such changes should be authorized and documented. The program version numbers should reconcile to the number of changes made.

2.the programmers should only have access to source code, not the running copy or the compilers.

3.if CASE tools are being used, the auditors should verify that controls are built-in regarding the documentation of program changes.

6.Potential exposure:1.The internal auditors should NOT report to the controller. This could cause a conflict of interest. The internal auditors should report to the CEO or the Board of Directors.

2.The controller and the internal auditors may be covering up fraudulent activities by having the new test data set rigged so that certain branches of the application logic are not tested.

The external auditors should:

1.Create a new test data set and examine the results.

2.Maintain a copy of the new test data set at home office.

3.Process the data test set created by the internal auditor with the accounting firms library copy of the application program and compare with the results of the current application program.

4.Recommend that the internal auditors report to the Board of Directors in the future or disregard any work provided by them.

5.Examine the program version numbers and change requests to assess whether any program changes have been made.

7.The concern is that many immaterial invoices may add up to a material amount. If an organized, carefully planned scheme to embezzle numerous small payments by customers is in effect, then the confirmation process will not catch the scheme since small invoice amounts will not be subjected to the confirmation process. An elaborate lapping of accounts receivable can escape detection if no further detection techniques are employed. The auditors should first investigate the current years accounts receivable balance. A sample of immaterial invoices should be investigated and subjected to the confirmation process. Only if discrepancies are found should the prior years accounts receivable be considered for investigation.

8.The auditor must sometimes rely on computer services personnel to produce a flat file from the complex file structures. There is a risk that data integrity will be compromised by the procedure used to create the flat file. In this case, where the auditors objective is to confirm accounts receivable, certain fraudulent accounts in the complex structure may be intentionally omitted from the flat-file copy that is created. The sample of confirmations drawn from the flat file may therefore be unreliable. Auditors skilled in programming languages may avoid this potential pitfall by writing their own data extraction routines.

9.Internal control issues:

Organizational Structure

Programmers and operators who perform incompatible functions may perpetrate program fraud.

The functions of programming, computer operations, tape librarian, and database administration should be organizationally segregated.

Systems Development

The development of unauthorized projects can result in the misappropriation of financial resources. Inefficient allocation of resources during development, lead to poorly developed systems.

Systems authorizations, user specification activities, technical design activities, internal audit participation, program testing, and acceptance procedures need adequate time and resources for proper completion.

Systems Maintenance

Unauthorized changes can result in program errors, fraud, incorrect information presented in financial statements and to users, systems failures, and severe disruptions to operations.

Program maintenance authorization, user involvement, technical specifications, program testing, documentation and program source code library access control need to be identified and maintained appropriately.

Internal Audit Participation

Though often overlooked, the internal audit should be involved as an outside view and a form of independent verification. Specialized audit groups that understand and have experience with systems in programming languages can be deployed through all process of development and maintenance.

Testing procedures

This is considered to be the most important part of SDLC. Testing should ensure:

Transaction Authorization: All transactions by the system are valid and legal.

Access Control: Once the system is operational, who will have access to it. This also constitutes allowing logins and password protection at differentiated levels.

Segregation of duties: Do the programmers have access to the system later? Do the operators have access to the source code (refer to the figure on the next page)?

The main issues that all systems should account for are:

1.Unauthorized access for financial gain or other illicit purposes

2.Intentional or unintentional insertion of viruses into the operating system

3.Loss of data due to system malfunction that goes unnoticed

Separating new systems development from Maintenance

1.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. These two duties should be separated and segregation of duties is very important at this stage. (Also refer to answer for question 2, for further details about segregation of duties and its importance).

2.Under the current system, the programmer who codes the original program (Siman II) also maintains the program later. This can lead to the following problems:

Program Fraud

Since the programmer also has full access to the program source code, he can implement hidden subroutines and access points that will allow him to use the program for personal benefits. In this case, since the company deals with managing wealth and money market accounts, the programmer can easily have funds diverted to his personal account. Lack of such segregation of duties can lead to further weaknesses in internal controls such as:

Access Control: The programmer now has access to all files and sensitive data of the company and the clients. Given his expertise he can manipulate that information without knowledge of management.

Transaction Authorization: He might perform transactions that are not valid such as investing for personal gains. Since, the programmer will have access to the maintenance of the program after the development stage; he can access these hidden routines and run them unnoticed to management.

Documentation Inadequacy

As mentioned in the case, the programmers were under heavy pressure to code the new version of Siman as competitors were ahead. The two major problems that occurred here were that they skipped the quintessential step of proper documentation while coding. And secondly, since they are also going to be working as maintenance for the system later, the documentation will be sparse and only meant to refresh their memory about specific routines and procedures. Thus, the documentation would almost be like a set of personal notes for the programmers. This defeats the purpose of documentation. The documentation is intended to allow future programmers to read and understand the system so they can work on it as efficiently as the original programmer.

This leads to a second problem of dependency where the programmers are now indispensable to the company as they are the only ones who understand the system. This places significant responsibility in the hands of management presenting the following internal control issues:

Audit Trail: The documentation is intended to be part of the audit trail to suffice in terms of validation of costs and resource implementation. It also enables auditors to track personnel utilization and need for systems that could be expensive.

Independent Verification: The documentation provides a key resource for independently verifying the protocols and procedures of the system. Improper documentation could lead to this step being avoided, which gives more autonomy to the programmers.

10.a.Advantages of using audit software to assist with audits include the following:

Audits can be more efficient, saving labor and time spent on routine calculations. The routine operations of footing extensions, transcription between reports, and report generation are computer generated as a result of the software.

The auditor's time spent on the audit is more analytical than clerical.

The auditor is able to examine more records and extract desired data more readily through ad hoc reporting.

Computer-generated reports and schedules are more objective and professional, improving data communication.

Audit sampling is improved. Any bias in sample selection is eliminated because of assured randomness. This has a direct effect on sampling precision, reliability, and audit accuracy.

Examples of use include:

1.Footing and balancing entire files or selected data items.

2.Selecting and reporting detailed data contained on files.

3.Selecting stratified statistical samples from data files.

4.Formatting results of tests into reports.

5.Printing confirmations in either standardized or special wording.

6.Screening data and selectively including or excluding items.

7.Comparing two files and identifying any differences.

8.Recalculating data fields.

b.

1.Integrated Test Facility

The integrated test facility (ITF) approach is an automated technique that enables the auditor to test an applications logic and controls during its normal operation. The ITF involves one or more audit modules designed into the application during the systems development process. In addition, ITF databases contain dummy master file records integrated among legitimate records.

The steps involved in performing ITF testing are:

ITF transactions must be created to test all logic branches in the application.

During normal operations, the test transactions are merged into the input stream of regular (production) transactions and are processed against the dummy accounts.

After processing, the auditor compares the processing results with predetermined results to verify that processes and controls function as expected.

2. Embedded Audit Module

Embedded audit module (EAM) techniques use one or more programmed modules embedded in a host application to select, for subsequent analysis, transactions that meet predetermined conditions. As the selected transaction is being processed by the host application, a copy of it is stored on an audit file for subsequent review. The EAM approach allows material transactions to be captured throughout the audit period. Captured transactions are retrieved by the auditor at period end or at any time during the period, thus significantly reducing the amount of work the auditor must do to identify significant transactions for substantive testing. Though primarily a substantive testing technique, EAMs may also be used to monitor application controls on an ongoing basis as recommended in the COSO framework.

The steps involved in performing parallel simulation testing are:

The auditor specifies to the EAM system the parameters and materiality threshold of the transactions set to be captured. Transactions equal to or greater than set threshold will be copied to the audit file. Transactions that fall below this threshold will be ignored by the EAM.

From the set of selected transactions, the auditor will choose a subset to be used for substantive tests.

For example, transactions selected by the EAM can be reviewed for proper authorization, completeness and accuracy of processing, and correct posting to accounts.

3.Parallel Simulation

Parallel simulation involves creating a program that simulates key features or processes of the application under review. The simulated application is then used to reprocess transactions that were previously processed by the production application. The results obtained from the simulation are reconciled with the results of the original production run to determine if application processes and controls are functioning correctly.

The steps involved in performing parallel simulation testing are:

The auditor must first gain a thorough understanding of the application under review. Complete and current documentation of the application is required to construct an accurate simulation.

The auditor must then identify those processes and controls in the application that are critical to the audit. These are the processes to be simulated.

The auditor creates the simulation using a fourth-generation language or generalized audit software.

The auditor runs the simulation program using selected production transactions and master files to produce a set of results.

Finally, the auditor evaluates and reconciles the test results with the production results produced in a previous run.

11.a.

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. User involvement should not be stifled by the technical complexity of the system. Regardless of the technology involved, the users should create detailed written descriptions of their 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 users 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 users needs. The scope of these activities includes systems analysis, feasibility analysis, and detailed systems design. The adequacy of these activities is reflected in the quality of the documentation that emerges from each phase.

Internal Audit Participation

To meet the governance-related expectations of management under SOX, an organizations 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. 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.

Program Testing

All program modules must be thoroughly tested before they are implemented. The results of the tests are then compared against predetermined results to identify programming and logic errors. The auditor should verify that all braches of the application's logic has been tested. The task of creating meaningful test data is time consuming. The data should therefore be saved and 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.

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

b.

In meeting the audit objectives the auditor would select a sample of system projects completed during the period and verify that they were properly authorized , that users were involved in specifying their needs, and that the internal auditor was actively involved in all decision phases of the project. The auditor would also verify that each phase of the SDLC was followed and evidenced with the appropriate documentation. The auditor should verify that applications were tested and that the test data and results were preserved as evidence. The auditor would determine that the overall system underwent formal test and acceptance procedures.

The auditors would also examine the audit trail of program changes by reconciling program version numbers and confirming maintenance authorizations. The auditors identify application errors by reconciling the source code, reviewing test results, and re-testing the program. 12.a. Five different areas in this payroll application with inadequate controls.

i. The payroll processing system violates the principle of segregation of duties in several areas as the same individual verifies the time cards, inputs payroll information into the master file, prints the checks, machine-signs the checks, distributes the checks, and prepares the payroll journal entry.

ii. There is no authorization of employees time cards by a supervisor or other objective party such as a time keeper.

iii. The payroll checks are not prenumbered nor are they properly stored. As a result, there is no audit trail to verify check usage.

iv. There is no control over the machine-signing of checks such as control of the signature plate by a second party or the use of a log to record activity.

v. The data processing department appears to have full access to the payroll files and checks, which could lead to sensitive payroll information being leaked.

b. Two areas in the payroll system in which system controls are satisfactory:

i. The personnel department determines the wage rate and initiates the setup of payroll records, which is a good example of segregation of duties.

ii. A backup of the master file is made after each weekly processing of the payroll.