Previous Table of Contents Next


Fully Automated Procedures

This term is an oxymoron, as there are no known automated tools that can independently identify, evaluate, discuss, report, and follow up on potential audit issues. It is used to describe tools and techniques that continue to function and produce results automatically after a single development effort. The IT auditor can choose from any of the following based on the requirements of a particular application or situation.

Integrated Test Facility. The audit director asks senior management for permission to have a fictitious master record added to an application. This might be a vendor master record in a purchasing or cash disbursements application. The fictitious record would have to be established without the knowledge of the persons responsible for master file maintenance or transaction processing, or else the reliability of the results would be compromised. Transactions are initiated by the auditor at random or present intervals, are indistinguishable from live transactions, and are processed exactly like live data. The IT auditor must take special care to avoid understating or overstating balance sheet or income statement amounts. In addition, the auditor should also be aware of possible local legal implications or restrictions regarding the use of this procedure.

Parallel Simulation. The IT auditor arranges for application software to be developed, based on the same functional requirements used to develop all or part of an application that is live in production. Once completed, the IT auditor obtains copies of master and/or transaction records that were entered into the production application, along with any related output produced by the application. These master and transaction records are then input to the specially developed application software and processed to see if the output from the independent system bears the same results as the real processing.

Parallel Operations. The IT auditor participates in a procedure that is similar to Parallel Simulation, except that the auditor is an observer in this scenario while the end user or software developer processes a standard set of transactions through both the new and existing application software to see if any differences result. The purpose of these operations is to verify the accuracy of new or revised application programs by processing production data and files, and using the existing and the newly developed programs. Processing results are compared to identify unexpected differences.

Base Case System Evaluation. The IT auditor develops a standard transaction or group of transactions and processes them through the original application. The results are confirmed and recorded, and the IT auditor can now resubmit the transactions to confirm that a change was made, to test whether no changes were made, etc. Such testing may be performed whenever application are modified.

Embedded Audit Data Collection. The IT auditor works with the audit director to obtain senior management’s approval for having a special module developed and implemented as part of an automated application. The module would most often be designed to identify master file or transaction data records based on predetermined criteria, standard intervals, random intervals, or any other basis that can be written into a rule. The selected data would then either be automatically displayed or printed for the IT auditor to evaluate.

Extended Records. These records are created by adding a control field to a master record or by creating a special record that is linked to a transaction record. This record or field may include data about all the application programs that processed a transaction, or other data deemed significant in that context.

Whatever the source, any specially developed applications or standalone programs should remain under the strict control of the audit department. For this reason, all documentation, test material, source listings, source and object program modules, and changes to such programs must be strictly controlled. In installations using advanced library management software, audit object programs may be cataloged with password protection. This is acceptable as long as the auditors retain control over the documentation and the appropriate job control instructions necessary to retrieve and execute the object program from its library. If general controls do not provide for strict audit control, audit programs should not be cataloged. The IT auditor should ensure that programs intended for audit use are fully documented to help ensure their continued usefulness and reliability.

The IT auditor should also take reasonable steps to protect the integrity of processing. Appropriate controls can include:

  Maintaining physical control over the audit software, unless it is cataloged in the system and protected appropriately
  Developing independent program controls that monitor or limit the processing of the audit software
  Maintaining control over software specifications, documentation, and job control cards
  Controlling the integrity of files being processed and output generated

APPLICATION DEVELOPMENT AND TESTING

Automated application development projects should be carried out according to a reliable SCLC methodology. Any project is likely to require complete and effective communication between the end users and the developers, whether the project is done in 3 or 12 phases. The IT auditor should work to evaluate controls during development, as it has been generally accepted that modifying a live-production application costs five to ten times more than implementing the desired feature during the development phase. The IT auditor’s evaluation could come at or near the end of each phase, or more often if deemed necessary. Guidelines should be developed to facilitate the review of new applications during the requirements definition phase so that controls can be identified for early assessment and potential inclusion.

IT auditors need to be capable of recommending effective controls to user management during the requirements definition and development phases. Such recommendations will not ensure that controls are absolute, but only that the structure is appropriate. Acting in this manner in this capacity, the IT auditor can be viewed as an internal controls consultant. The IT auditor should be careful not to make, or participate in making, any management decisions.

The IT auditor should consider the need to schedule a post-implementation review for each major or identifiable automated application accepted and implemented into the production environment. Reviews that get scheduled should be done within six to nine months of the production implementation. Where the IT auditor originally evaluated the defined and expected controls, he can now evaluate the effectiveness of the controls as implemented.

One indirect benefit from a timely post-implementation review is that any control deficiencies may get worked into the normal code fine-tuning activities that follow the implementation of many automated application development projects.

The IT auditor should also be aware that any serious problems or deviations from the functional requirements deliverable that made it into production are likely to be identified by the end-user personnel responsible for the affected business function faster than almost any audit could do the same.

In larger IT departments, quality assurance or change management personnel may be responsible for performing a post-implementation review for each completed application development project. If this is the case, the IT auditor should consider whether to participate in the planned post-implementation review or conduct his own. Regardless, the IT auditor should request copies of all post-implementations as they should contain information that is important to the audit planning process.

DOCUMENTING AND REPORTING AUDIT WORK

The internal audit manual should include standards for audit workpapers and other standard documents. Since workpapers are the primary evidence of the audit procedures performed, the workpaper package for each audit should be well-organized, clearly written, and address all areas in the audit scope. Audit workpapers should contain sufficient evidence of the tasks performed and conclusions reached, including:

  Audit program with sign-offs
  Planning and administrative documents
  Permanent file including internal control and other carry-forward information
  Workpapers indicating the preparer and reviewer
  Detailed evidence of work performed, results achieved, issues identified, etc.
  Authorized signatures approving the final opinion


Previous Table of Contents Next