SM-17-9th Ed Final [PDF]

Citation preview

Chapter 17 page 130



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.



Chapter 17 page 131



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 user’s 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.



Chapter 17 page 132



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.



Chapter 17 page 133



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



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



Chapter 17 page 134



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 application’s 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.



16.



a.



Test data method



b.



Base case system evaluation



c.



Tracing



d.



Integrated test facility



e.



Parallel Simulation



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 auditor’s substantive testing task is thus made easier since they do not have to identify significant transactions for substantive testing.



Chapter 17 page 135



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.



Chapter 17 page 136



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.



Chapter 17 page 137



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 student’s 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 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 system’s 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.



Chapter 17 page 138



4.



Financial systems that calculate interest payments on bank accounts or charges on mortgages and other loans employ special rounding error applications. Rounding errors occur when the level of precision used in an interest calculation is greater than that used for reporting. For example, interest calculations on bank account balances may have a precision of five decimal places, whereas only two decimal places are reported on balances. If the remaining three decimal places are simply truncated, the total interest reported for the total number of accounts will not equal the sum of the individual calculations. Rounding error routines use an accumulator to keep track of the rounding differences (plus or minus a fraction of a cent) between calculated and reported balances. When the accumulator balance reaches plus or minus one cent, the balance is added to (or subtracted from) a randomly selected account.



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 customer’s account (that is, the accumulator value is > +.01), the program instead adds one cent to the perpetrator’s 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.



Chapter 17 page 139



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 application’s internal logic. Instead, auditors analyze flowcharts and interview knowledgeable personnel in the client’s 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 application’s 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.



Chapter 17 page 140



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 application’s 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 client’s 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



Chapter 17 page 141



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.



Chapter 17 page 142



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 walkthrough of the application’s 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 application’s 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 auditor’s processing reconcile with the organization’s 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.



Chapter 17 page 143



MULTIPLE CHOICE 1.



A



2.



A



3.



D



4.



C



5.



A



6.



C



7.



B



8.



C



9.



E



10.



E



Chapter 17 page 144



PROBLEMS



Chapter 17 page 145



1. DESIGN TESTS OF APPLICATION CONTROLS 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 auditor’s 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.



Chapter 17 page 146



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 supplier’s 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.



Chapter 17 page 147



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.



Chapter 17 page 148



2.



COMPUTER FRAUD AND CONTROLS Identification and Description of Type of Fraud



Explanation



Protection Methods



a. Input



Input alteration requires the least



Documentation and Authorization



Alteration



amount of technical skill and almost  no knowledge of how the computer



Data input formats properly documented and authorized



system operates. Input documents







Programmed terminal/user protection



are improperly altered or revised







Programs designed to accept only certain



without authorization, e.g., payroll



inputs from designated users, locations,



time cards/time sheets can be altered terminals, and/or times of the day. to pay overtime or an extra salary. b. Program



Program alteration requires



Programmers should only make changes to



Alteration



programming skills and knowledge of



copies of production source programs and data



the program. The program coding is



files, never to the actual production files.



revised for fraudulent purposes, e.g.,



Segregation of Duties



ignore certain transactions such as  overdrafts against the programmer’s



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



account, draw checks and have them Periodic Comparisons sent to a falsely constructed account,



Internal Audit or some other independent group



grant excessive discounts to certain



should have copies of the official programs, or



specified trade accounts, etc.



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



File alteration occurs when the



Restricted Access to Equipment/Files



Alteration



defrauder revises specific data or







Restrict access to the computer center.



manipulates data files, e.g.,







Programmers, analysts, and computer



fraudulently changing the rate of pay



operators should not have direct access to



of an employee in the payroll master



production data files.



file via a program instruction; or







Production data files are maintained in a



Chapter 17 page 149



transferring balances among dormant library under the control of a librarian or database administrator.



accounts to conceal improper withdrawals of funds.







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 Theft



Data theft can be accomplished by data



Electronic sensitization of all library materials for



interception over a network, by access to



detection if unauthorized removal from the library



files and central databases, and by



is attempted.



physical removal of data files and of hard



Sensitive transmitted and stored data should be



copies of reports. With considerable



encrypted using secured encryption methods



amounts of information being transmitted



such as RSA.



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



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.



remove reports and hard copy printouts of files. e. Sabotage



The physical destruction of hardware



Terminated employees immediately denied



or software.



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 FOR TRUE, BLUE, AND SMITH System Access and Security



Chapter 17 page 150



AUDIT OBJECTIVES RELATED TO SUVERSIVE THREATS The audit objective is to verify that network controls (1) can prevent and detect illegal access both internally and from the Internet, (2) will render useless any data that a perpetrator successfully captures, and (3) are sufficient to preserve the integrity and physical security of data connected to the network. AUDIT PROCEDURES 1. Review the adequacy of firewall controls in terms of the following criteria: • Flexibility. The firewall should be flexible enough to accommodate new services as the security needs of the organization change.



•



Proxy services. Adequate proxy applications should be in place to



provide explicit user authentication to sensitive services, applications, and data. •



Filtering. Strong filtering techniques should be designed to deny all



services that are not explicitly permitted. In other words, the firewall should specify only those services the user is permitted to access, rather than specifying the services that are denied. •



Segregation of systems. Systems that do not require public access



should be segregated from the Internet. •



Audit tools. The firewall should provide a thorough set of audit and



logging tools that identify and record suspicious activity. •



Probe for weaknesses. To validate security, the auditor (or a



professional security analyst) should periodically probe the firewall for weaknesses, just as a computer Internet hacker would do. A number of software products are currently available for identifying security weaknesses. 2.



Verify that an Intrusion Prevention Systems (IPS) with deep packet



inspection (DPI) is in place for organizations that are vulnerable to DDoS attacks, such as financial institutions. 3.



Review security procedures governing the administration of data



encryption keys. 4.



Review the message transaction logs to verify that all messages were



received in their proper sequence.



Chapter 17 Page 121



Test the operation of the call-back feature by placing an unauthorized



5.



call from outside the installation.



AUDIT OBJECTIVES RELATED TO USER ACCESS PRIVILEGES The audit objective is to verify that access privileges are granted in a manner consistent with the need to separate incompatible functions and in accordance with organizational policy. AUDIT PROCEDURES 



Review the organization’s 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 system users have signed statements acknowledging 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 PASSWORD POLICY



Chapter 17 Page 122



The audit objective here is to ensure that the organization has an adequate and effective password policy in place for controlling access to the 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 SECURITY THREATS FROM VIRUSES AND MALWARE The audit objective is to verify that effective policies and procedures are in place to protect the system from the introduction and spread of viruses and other destructive programs. AUDIT PROCEDURES 



Through interviews with system users, 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.







Verify that the current version of antiviral software is installed on the



Chapter 17 Page 123



server and that upgrades are regularly downloaded to workstations. 



Verify that system workstations and file servers are routinely scanned for viruses and malware







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



AUDIT OBJECTIVES RELATED TO AUTOMATED AUDIT TRAILS The audit 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



Chapter 17 Page 124



evaluate their disposition to assess the effectiveness of the security group. Systems Development and Program Changes AUDIT OBJECTIVES RELATED TO SYSTEMS DEVELOPMENT The audit 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. AUDIT PROCEDURES The auditor should select a sample of completed projects 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 values. • The detailed design was an appropriate and accurate solution to the user’s problem.



Chapter 17 Page 125



• 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. AUDIT OBJECTIVES RELATED TO PROGRAM CHANGES. The audit objective is to detect unauthorized program changes (which may have resulted in significant processing errors or fraud) and to determine that 1. program change procedures protect against unauthorized changes, and 2. program changes have been tested prior to being implemented.



AUDIT PROCEDURES 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. Any discrepancies between version numbers and supporting documents may indicate an unauthorized program change.







Confirm



Program



Change



Authorization.



Program



change



documentation should indicate the nature of the change requested and the date of the change. The auditor should confirm the facts contained



Chapter 17 Page 126



in the authorization and verify the authorizing signatures with the managers involved. 



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. If necessary the auditor can retest the application to confirm its integrity.



Organizational Structure Controls AUDIT OBJECTIVES RELATED TO ORGANIZATIONAL STRUCTURE The audit 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



Chapter 17 Page 127



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.



Chapter 17 Page 128



4.



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



RISK IDENTIFICATION AND PLAN OF ACTION Potential risk—unauthorized 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.



Chapter 17 Page 129



3.



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



6.



RISK IDENTIFICATION AND PLAN OF ACTION Potential risk: 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 firm’s 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.



Chapter 17 Page 130



7. SYSTEMS DEVELOPMENT AND PROGRAM CHANGES Winston Financial Services (WFS) A) RISKS ASSOCIATED WITH WFS’ SYSTEMS DEVELOPMENT APPROACH 1) One-man-operation may result in poorly designed systems that contain undetected flaws that result in material misstatements of financial data. 2) The programmer both designs and maintains the application and may therefore be in position to perpetrate program fraud. 3) Documentation of the system may become inadequate and outdated thus hampering day-to-day operations and system auditability.



B) INTERNAL CONTROL WEAKNESSES 1) The maintenance programmer trained in VIEW is wholly responsible for the design,



implementation, and subsequent maintenance of new system.



Consequently, he will perform many incompatible tasks in contradiction with internal control standards established for the SDLC. A well designed SDLC would include the following control points: systems authorizations, user specification activities, technical design activities, internal audit participation, program testing, and acceptance procedures. These formal control points are intended to ensure that only authorized programs go forward for development. These applications will be designed to high technical standard that meet user needs and will be thoroughly tested and validated before their implementation.



Chapter 17 Page 131



2) Systems development and program changes should be segregated tasks. Under the proposed approach the programmer who codes the upgrade program also maintains the system later. Since WFS deals with client investments and wealth management, this access could possibly lead to the following frauds:







With full access to the program source code, the programmer could implement hidden subroutines that will allow him to divert funds to his personal account.







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







He may perform unauthorized and illegal transactions such as using proprietary information to invest for personal gain.







Since, the programmer will have unlimited maintenance access to the program after the development stage he can remove any fraudulent code when the system is under audit to protect himself from detection and reinitiate the fraud when the audit is complete.



Chapter 17 Page 132



Documentation Inadequacy Because the system programmer and the maintenance programmer are the same person, no formal transfer of the completed VIEW documentation to the maintenance group will take place. As a result system documentation will likely be sparse and only meant to refresh the programmer’s memory about specific routines and procedures. Existing documentation will thus be equivalent to a set of personal notes. This defeats the purpose of documentation, which is to allow future programmers to read and understand the system so they can work on it as efficiently as the original programmer. A related problem is one of dependency where the VIEW programmer becomes indispensable to the company as he is the only one who understands the new system. In addition to these operational issues, inadequate documentation impacts the auditability of the system. Accurate and current system documentation is critical to an auditor’s understanding of system functionality and controls. Lacking such essential information auditors are severely encumbered in their ability to design tests of controls in compliance with auditing standards.



Chapter 17 Page 133



8.



AUDIT OBJECTIVES AND PROCEDURES 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 auditor’s 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.



RISK IDENTIFICATION AND PLAN OF ACTION 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 year’s 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 year’s accounts receivable be considered for investigation.



 



Chapter 17 Page 134



10. COMPUTER ASSISTED AUDIT TOOLS AND TECHNIQUES 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.



Chapter 17 Page 135



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 application’s 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.



Chapter 17 Page 136







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.



Chapter 17 Page 137







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.



Chapter 17 Page 138







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. AUDIT OF SYSTEMS DEVELOPMENT 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 user’s view of the problem, not that of the systems professionals.



Chapter 17 Page 139



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



Chapter 17 Page 140



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.



Chapter 17 Page 141



12.



PAYROLL APPLICATION CONTROL 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.



Chapter 17 Page 142



13. ANNOUNCING A NEW INFORMATION SYSTEM The issues to be addressed include the following: 



The decision to exclude users from the development process is flawed.







During systems development, systems professionals should work with the primary users to obtain an understanding of the users’ problems and a clear statement of their needs.







A survey of the current system is essential. gather facts:



The consultants need to



These include facts about. Data sources, users, key



Processes, controls points, transaction types and volumes, error rates, resource costs, bottlenecks and redundant operations.







Some of the above facts can be gathered independently through documentation, but many of them can be obtained only through user participation. This includes personal interviews, open-ended questions, and structured questionnaires. o The internal auditor should be involved in the development process. An internal audit group, astute in computer technology and with a solid grasp of the business problems of users serves in an essential liaison capacity.



Chapter 17 Page 143







The internal auditor must ensure the auditability of the system. Some computer auditing techniques such as the Embedded Audit Module (EAM) and the Integrated Test Facility (ITF) need to be designed into systems as integral components.







The internal auditor is best qualified to determine if the system under consideration is a good candidate for integrated audit features.







The auditor should be involved in the final system selection to assess the economic feasibility of the proposed system.



14. PROBLEMS VS SYMPTOMS Classify each of the following as a problem or a symptom. a. declining profits—symptom. Possible problems: producing defective products causing a decline in sales Increased costs due to high maintenance of outdated machinery. b. defective production process—problem. Possible symptoms declining sales or increased COGS due to labor time for reworks.



c. low-quality raw materials—problem.



Chapter 17 Page 144



Possible symptoms declining sales increased COGS.



d. shortfall in cash balance—symptom. Possible problems poor accounts receivable collections over-purchase of inventory.



e. declining market share—symptom. Possible problems producing the wrong product mix (i.e. producing unwanted items) poor customer service.



f. shortage of employees in the accounts payable department—problem. Possible symptoms increased discounts lost increased errors in processing tasks (unrecorded liabilities)



g. shortage of raw material due to a drought in the Midwest—problem. Possible Symptoms declining profits unfilled customer orders. NOTE: It could also be viewed as a symptom of relying too heavily on one supplier.



Chapter 17 Page 145



15. SPL RISKS AND CONTROLS Response: 1) Trade-Off between Efficiency and Control Control is always in conflict with operational flexibility and efficiency. For these reasons, systems professionals who must work daily within this environment sometimes oppose controlling the SPL. To achieve an acceptable control-efficiency trade-off management must be aware of the risks that are created when control features are not employed or are routinely circumvented. In spite of the risk, the nocontrols approach is sometimes the choice (perhaps inadvertently) that management make.



2) The risks associated with Orben’s approach are: The opportunity for program fraud is increased when applications are developed and tested by the same individual. Also, unfettered access to all programs in the SPL increases the potential for fraud. Documentation suffers in this situation. If the design / maintenance programmer leaves the organization he/she may leave behind an application that is poorly documented and which will be difficult to understand by the maintenance programmer who inherits it. The maintenance approach employed by Orben provides no audit trail of program changes. Each application change should be documented and the revised program should be formally installed as the current version of the application.



Chapter 17 Page 146



For the reasons mentioned, externals auditor are concerned about the adequacy of systems development and program change procedures. The process followed by Orben will likely result increased application control tests and substantive tests.



3) Control to reduce the risk Orben manufacturing should implement SPL controls that include the following features: Password control over access to the SPL. Separates test libraries when program changes can be thoroughly tested before being implemented Audit trail reports that describe the details of all changes to applications Version numbers that uniquely identify each version of the application and permit a reconciliation between the current version and all authorized changes to it during the period under review. Controlled access to powerful maintenance commands that could be used to destroy audit trail data that are critical to the audit.