Evaluating Application Systems Acquisition and Implementation
| The IT organization is responsible for ensuring that the acquired solutions meet the objectives of the organization and reduce risk to the organization through the use of formal acquisition and implementation processes. The IS auditor should assess this process by reviewing control issues regarding acquisition and implementation. A comprehensive acquisition process should include clearly defined procedures for requirements gathering, feasibility studies, proposal creation, and vendor selection. Implementation of the applications should follow a documented system life-cycle development process (SDLC), as well as defined project-management and change-control procedures. Application-Implementation PracticesThe primary concern for an organization is to ensure that projects are consistently managed through a formal documented process. This process includes the SDLC, project management, change control, and policies/procedures aligned with the strategic plan. The introduction of new software, whether developed in-house or acquired, can affect systems and services if not implemented properly. All software should follow rigorous testing procedures and meet existing standards before being put into production. Before being added to the production environment, the software should undergo vulnerability testing to validate controls and to document and correct any deficiencies. The software should be added to existing procedures (backup, vulnerability testing, and patch/upgrade schedules) to ensure continued confidentiality, integrity, and availability of the software and its associated data. If an IS auditor observes that an IS department fails to use formal documented methodologies, policies, and standards, the auditor should at least document the informal standards and policies, and test for compliance. Furthermore, the IS auditor should recommend to management that formal documented policies be developed and implemented. Application System-Acquisition ProcessesThe acquisition of software is driven by business requirements. The IT organization should have clearly defined acquisition procedures, including procedures for performing the feasibility study and requirements gathering. In conjunction with managers, the IT organization should analyze the requirements and create the feasibility study. This study helps determine whether the organization will "buy" or "build" the software to meet the needs of the organization. Although software acquisition is not part of the SDLC, it should have a formal documented process. According to ISACA, the project team, technical support staff, and key users should be asked to write a request for proposal (RFP). This RFP should be sent to a variety of vendors, and their responses (proposals) should be reviewed to determine which vendor's products offer the best solution.
"Make vs. buy" decisions are typically made during the feasibility study phase of the software- or systems-development project. After the vendors respond to the RFP with their proposals, the project team should review them for completeness and determine whether a single vendor can be chosen. If a vendor cannot be chosen based on the proposals, the project team should narrow the list to two or three vendors through a suitable methodology. This methodology should ensure that the same criteria are used in evaluating the vendors. This might require the project team to obtain additional information from the vendors (additional documentation or demonstrations) and to use a scoring methodology to determine which vendor is the best fit for the organization. After the project team makes the selection, it must negotiate and sign a contract. Per ISACA, the contract should include the following items:
As an IS auditor, you should look for evidence of a structured approach to software acquisition. This includes acquisition procedures, defines the process for feasibility studies, and outlines a suitable methodology for the evaluation of proposals. After the software is acquired, there should be a project-management and change-control process to implement the software. All software acquired should be added to existing maintenance contracts, or a new maintenance contract should be acquired. Before being introduced into the production environment, the software should be tested according to written test plans, and responsibilities for the production software should be clearly defined. The software should be secured (physical, logical) and added to the business continuity plan. Application Change Control and Emergency Change-Management ProceduresAs stated in an earlier section, the change-management process ensures that any deviations from the original requirements are approved (or denied) and, if approved, are added to the project. There is one exception to the normal change-management process: the emergency change request used to correct immediate system problems that might affect critical services or processing. The difference between emergency changes and regular change requests is that the emergency change is corrected immediately and the change request (with supporting documentation) is completed after the fact. The organization should use emergency IDs to enable programmers and analysts to log in to the system and correct emergency problems. These IDs should be monitored and logged, and used only in the event of any emergency. The code associated with emergency changes should be stored in an emergency library until the change-control board has reviewed the request. When complete, the code should be moved to the production library. The IS auditor should review emergency change requests as well as the program change log to ensure that only authorized program changes were made. |
