Audit Participation in Application Development, Acquisition, Conversions, and Testing

Action Summary

Senior management should involve IT audit in major application development, acquisition, conversion, and testing.

The development, acquisition, or conversion of an automated application is a lengthy and complex process requiring a significant degree of interaction among the programming staff, user departments, and internal audit. This process, known as the system development life cycle or system development methodology, requires detailed developmental stages to ensure that applications meet the needs of the institution. As each stage of the life cycle is reached, the auditor should review the internal controls, testing, and audit trails included in the application. The incorporation of internal controls within a completed application already in production is usually more difficult and expensive. Guidelines should be developed to facilitate the review of new applications during the design phase so that controls can be identified during independent audit review early in the development process.

The institution's audit policy, as approved by the board of directors, should include guidelines detailing what involvement internal audit will have in the development, acquisition, conversion, and testing of major applications. This includes describing the monitoring, reporting, and escalation processes (when internal controls are found to be insufficient or when testing is found to be inadequate). For acquisitions, this includes describing the phases of the system development life cycle in which IT audit will be involved. For acquisitions with significant IT impacts, participation of IT audit may be necessary early in the due diligence stage.

It is necessary that audit's participation in the development process be independent and objective. Auditors can determine and should recommend appropriate controls to project management. However, such recommendations do not necessarily "pre-approve" the controls, but instead guide the developers in considering appropriate control standards and structures throughout their project. The auditors are more than just "consultants" on internal controls. While they should not have any direct involvement in management decisions, they should raise objections if they believe the control environment to be inadequate.

Once a new application system, conversion, or major revision to an existing system is accepted for production processing, the IT auditor should conduct a post-implementation review. This review should occur shortly after the implementation of the new or revised system and should include extensive testing of program logic, calculations, error conditions, edits, and controls. Such testing helps to validate that the software operates as expected. By performing the review soon after migration to the production environment, the auditors can quickly identify processing errors or other unsatisfactory conditions. A prompt post-implementation review should minimize potential losses from processing errors or ineffective software operation or controls and loss of reputation caused by inaccurate information provided to customers.

In larger IT facilities, formal quality assurance or change management groups may have primary responsibility for post-implementation reviews. In such cases, the IT auditor may choose not to perform a separate review but instead to participate in establishing the test criteria and evaluating results of any other independent reviews.


Previous Section
Risk Scoring System
Next Section
Outsourcing Internal IT Audit