Previous Table of Contents Next


SETTING THE AUDIT OBJECTIVES

The IT Audit Professional may need to make adjustments to the audit objectives, depending on the design methodology used or other issues that may have arisen during the procedures up to this point in the process.

Development Methodology Audit Considerations. The IT auditor may customize the two audit objectives for this phase based on one or more of the following factors.

First, the status of design up to this point must be considered. The fewer problems involved in this application, the less need there is for audit attention during this phase. Second, the design methodology used must be noted. Audit involvement changes significantly, depending on whether the software is developed in-house, contracted, or purchased, as follows:

  For software developed in-house, the audit involvement should be at critical management checkpoints, usually at the end of developmental phases.
  For contracted software, the audit involvement must either be specified in the contract or else be limited to the points in time when key deliverables prepared by the contractor are made available to the organization.
  For purchased applications, the only audit involvement is an assessment of the design methodology for determining whether adequate controls were incorporated to develop an effective application. This is done in preparation for a decision to purchase or contract.

Third, the IT Audit Professional should consider technology integration factors. During the implementation phase, the risk attributes of technology integration can be reassessed to evaluate the implementation risk. The greater the risk, the greater the need for audit attention in this phase. The technology integration attributes that must be considered in evaluating the scope and objectives of audit work include:

  The make-up of the project team in relation to the technology used (i.e., number, training, and experience)
  The applicability of the DP design methodologies and standards to the technology in use
  User knowledge of related technology
  The margin for error (i.e., is there reasonable time to make adjustments, corrections, or perform analyses before the transaction is completed?)
  The availability of automated error detection and correction procedures
  The degree of dependence on the system
  The criticality of interfaces with other systems and external organizations

DETAILED AUDIT TESTING

During detailed audit testing, the IT auditor should evaluate the adequacy of the programming effort by reviewing the test results. First, the auditor should evaluate the results of quality assurance reviews of testing efforts.

The results of this evaluation determine the effectiveness of the quality assurance department’s reviews and thereby affect the nature and extent of audit procedures in this phase. If no effective quality assurance function exists, and there is no provision for another project participant to assume those responsibilities, then the IT auditor may be asked to evaluate the adequacy of testing efforts.

Second, the IT auditor may evaluate the adequacy of documentation-user, programming, maintenance, and installation manuals. Again, the auditor may review quality assurance efforts in these areas, yet try not to duplicate the work done by that function. If, however, there is no effective quality assurance function, and none of the other project participants assume those responsibilities, the auditor may be asked to substitute for the quality assurance specialist.

THE AUDIT TEST

The IT Audit Professional should also develop a standard audit test program for the programming phase. The test begins by outlining the more common audit objectives. For each objective, the IT auditor is given one or more tests to perform, and for each test, one or more tools and techniques are suggested.

AUDIT RESULTS AND REPORTING

The result of the programming phase review should be documented and given to project management. Deficiencies and their potential effect on meeting the system mission should be reported to project management on a timely basis. Delays in submitting review reports can significantly increase the cost of correcting deficiencies.

Common Deficiencies. In the programming and testing phase, some deficiencies occur more frequently than others. The following deficiencies are among the more common ones for this phase.

  Documents and tasks are not completed or are not completed on time (i.e., goals are met but documents and tasks are not completed).
  Goals are not met because of incomplete tasks.
  Applications are coded that could be done more economically through contracting or purchasing off-the-shelf software.
  Documentation for programming and training is not prepared in accordance with standards or is not prepared at all, resulting in additional maintenance and operational costs.
  The program documentation is not kept current; as programs are changed, the documentation is not updated and therefore is unusable for maintaining the system.
  No quality control is exercised over the documentation to ensure that it is complete and in compliance with standards.
  Programs are not fully tested, resulting in the operation of defective programs.
  Users are inadequately trained in the use of the application; thus, they either misuse the software or are unable to use the software features.
  User manuals are not prepared or are not prepared in accordance with standards, resulting in incorrectly entered or processed transactions and improper use of output.
  Audit and quality assurance tools and techniques are not included or are not properly implemented in the system.

Deficiencies in programming result in inaccurate or incomplete processing, which causes abnormal terminations in processing, resulting in reruns of processing and late delivery of output. Deficiencies not uncovered through operational controls result in improper processing by users.

In addition, deficiencies in documentation and training result in operational malfunctions and erroneous processing. These deficiencies can also result in uneconomical operations, because tasks must be performed several times to be performed correctly.

The IT Audit Professional should be able to quantify the impact of these potential deficiencies, and should demonstrate the potential adverse effects that can occur because of inadequate programming, documentation, and training.

In particular, the auditor should process test data to show that the system was not properly programmed to prevent erroneous processing, compare user and programmer documentation to identify discrepancies between these two critical documents, and compare user documentation with training documentation and instruction to identify inconsistencies.

EVALUATING THE AUDIT STRATEGY

The IT Audit Professional, at the end of the programming and training phase, should determine the nature and extent of the audit procedures to be performed. As with other phases, if only minimal problems are detected by the end of this phase, the auditor may not need to expend extensive effort in the evaluation and acceptance phase. Conversely, if the auditor suspects that there are potential weaknesses in the system, extensive audit involvement may be warranted during the next phase.

The IT auditor should also finalize any post-implementation audit programs, tools, and techniques during this phase. As the project sponsor is evaluating the system during the next phase, the auditor should be prepared to evaluate the audit program developed for use during operations. At a minimum, this audit program should include:

  A list of potential areas for audit investigation
  Tools for file analysis and software packages for use during operation for file analysis
  Step-by-step audit programs for the audit team to use in auditing the operational system
  A permanent working file on the system, including key aspects of documentation, with references to official systems documents


Previous Table of Contents Next