System Development Life Cycle Audit Program


A system development life cycle (SDLC) is a methodology that can be used to develop or modify application systems. Each organization should establish a SDLC methodology and assign responsibility for each phase of the cycle so that system design, development, and maintenance may progress smoothly and accurately. This cycle starts with a perceived need and extends through feasibility study, design and development, testing, implementation, system acceptance and approval, post-implementation review, and maintenance of the application and systems software. Following each phase of this cycle ensures that the new or revised software meets the organization's needs, that adequate internal controls are consistent with management's objectives, and that the application is properly implemented.

This audit program assumes that an application system is developed by an in-house programming staff. However, application systems in use by many state agencies were not developed in-house but instead were purchased. In these instances, all the steps performed during in-house development of an application are not applicable for purchased software. Specifically, systems and programming standards, and file and programming specifications are not needed. In these cases, document in the Summary Memo how the scope of this audit program will be modified and answer Not Applicable (N/A) to any questions on the ICQ that do not apply.

Suggested interviewees for ICQ:

A. System Programming Manager

B. Director of Data Processing

A. Control Objective #1 - SDLC Methodology

  1. Determine the extent of the responsibilities of management, internal audit, users, quality assurance, and data processing during the system design, development, and maintenance.
  2. Review SDLC workpapers to determine if the appropriate levels of authorization were obtained for each phase.
  3. Obtain and review requests for DP services. Determine if the University's procedures are being followed.

B. Control Objective #2 - Needs Analysis

  1. Review and evaluate the procedures for performing a needs analysis.
  2. Review a needs analysis for a recent project and determine if it conforms to standards.

C. Control Objective #3 - Systems Design and Development

  1. Review and evaluate the procedures for systems design and development.
  2. Review design specifications schedules, look for written evidence of approval, and determine if the design specifications comply with the standards.
  3. Determine if an audit trail and programmed controls are incorporated in the design specifications of a recent project.
  4. Review samples of source documents used for data entry which are included in SDLC workpapers of a recently developed application. Determine if they are designed to facilitate accurate gathering and entry of information.
  5. Obtain and review programs to determine if they comply with the University's programming standards.

D. Control Objective #4 - Testing Procedures

  1. Review and evaluate the procedures for system and program testing.
  2. Review documented testing procedures, test data, and resulting output to determine if they appear to be comprehensive and if they follow University standards.
  3. Review the adequacy of testing performed on the manual phases of an application.

E. Control Objective #5 - Implementation Procedures

  1. Review and evaluate procedures for program promotion and implementation.
  2. Review documentation of the program promotion procedure. Determine if the standards are followed and if documentation of compliance with the standards is available. Trace selected program and system software changes to the appropriate supporting records to determine if the changes have been properly approved.
  3. Review documentation of the conversion/implementation of a newly developed application. Determine if the University's implementation procedures were followed.

F. Control Objective #6 - Post-implementation Review

  1. Review and evaluate the procedures for performing post-implementation reviews.
  2. Review program modifications, testing procedures, and the preparation of supporting documentation to determine if the University's standards are being followed.

G. Control Objective #7 - Maintenance of Applications

  1. Review and evaluate the procedures for the maintenance of existing applications.
  2. Review program modifications, testing procedures, and the preparation of supporting documentation to determine if the University's standards are being followed.

H. Control Objective #8 - Control over Systems Software

  1. Review and evaluate the procedures for modifying systems software.
  2. Review systems software modifications, testing procedures, and the preparation of supporting documentation to determine if the University's standards are being followed.
  3. Review and evaluate documentation of in-house developed systems software and the features/options of proprietary systems software in use.

I. Control Objective #9 - Documentation Standards

  1. Obtain and review the documentation standards to determine if they are complete.


Because it has been estimated that a major portion of the cost of an application over its useful life is incurred for maintenance after the application becomes operational, if little attention is given to the SDLC in the creation of a system, excessive maintenance costs can be incurred, especially if it is necessary to put controls in after the application is already in production. Redesign is not only expensive, but difficult to accomplish.

If accurate and comprehensive documentation is not maintained, the auditor will have difficulty assessing controls without expending substantial effort to obtain an accurate description of significant applications and their relationships to one another.

If modifications to application and system software are not adequately controlled, the integrity of the software may be compromised by unauthorized changes in programs, procedures, or data.

When an application is properly designed, systems development and documentation controls can prevent or disclose the following types of errors:

  1. implementation of applications that do not have adequate application controls;
  2. development of applications that either do not meet management objectives or do not operate in accordance with original specifications;
  3. implementation of applications that have not been adequately tested, and;
  4. implementation of applications that are susceptible to unauthorized modification.