Section 6.4.  What Do Acquisition and Implementation Mean?

6.4. What Do Acquisition and Implementation Mean? In Chapter 2, "SOX and COBIT Defined," we established a high-level definition for the COBIT Acquisition and Implementation domain: "Once the plans are developed and approved, there may be a need to acquire new applications or even acquire or develop a new staff skill set to execute the plans." Upon completion of the Acquisition phase, the plans now need to be enacted in the implementation phase, which should include maintenance, testing, certifying, and identification of any changes needed to ensure continued availability of existing systems and new systems. In this chapter, we look at the specifics of each of the control objectives of the Acquisition and Implementation domain and attempt to summarize and distill the various control objectives to lend themselves more to the structure of a small to medium-sized company. In Chapter 3, "The Cost of Compliance," we cautioned you about minimizing overlap as much as possible in the applications you select for your environment. Well, now we would like to add another caution: Given that there are no acquisition costs associated with open source tools, the tendency might be to over-implement. Our point is this: If you implement open source applications based on a specific requirement versus your total environment, you will likely discover that you have over-implemented, thereby increasing your environment resource and skill set requirements rather than reducing them. Whether for COBIT or Sarbanes-Oxley compliance, we will again use BuiltRight Construction and NuStuff as companies that need to come into compliance. If a particular Control Objective of the COBIT Acquisition and Implementation or an individual item is not applicable to BuiltRight, NuStuff, and/or would not apply to a small to medium-sized company it has not been listed as part of the guidelines in this chapter. For a complete list of the COBIT guidelines, see Appendix A, "COBIT Control Objectives." Neither BuiltRight nor NuStuff performed any in-house development activities; thus, only a few Control Objectives apply to either fictitious company. Therefore, what we will do is identify Control Objectives that might not necessarily appear to pertain to these companies, ones that you may want to consider from a different aspect, and/or ones that will feed into other processes that you might need to consider. It is also noteworthy to mention that even if your organization does not perform in-house development, you will want to be able to articulate this and demonstrate it to your auditor. 6.4.1. Identify Automated Solutions This section as it pertains to COBIT deals with identification of Automated Solutions, and more specifically, systems that were developed in-house. Although you might think you are in the clear because you have no development staff, you will need to consider any applications you had developed by consultants and contractors. For clarity in this section, we again state that the scope of Sarbanes-Oxley is any system that is significant in the financial reporting process. 6.4.1.1. Definition of Information Requirements (Repositioning) The COBIT practice states that a methodology should exist to ensure that business requirements are met for existing systems and future development activities. Perhaps not as it relates to development, but this is an area you may want to look to as you prepare your plans and evaluate open source tools. 6.4.1.2. Audit Trails Design (SOX) The COBIT practice states that an organization's system development life cycle methodologies specify that systems have the capability to track activities via audit trails. Even if you do not have any in-house developed systems or systems provided by a consultant or contractors, you might still not be in the clear. If you have systems that have been significantly customized or modified, you will want to examine them. 6.4.1.3. Third-Party Software Maintenance (Repositioning) Although by its very nature, open source cannot be sold, some commercials companies have embraced open source as part of their business model by providing third-party support. In a good IT organization, application support should always be included in the overall plans. 6.4.2. Acquire and Maintain Application Software This section as it pertains to COBIT deals with design elements of systems developed in-house. However, keep in mind that heavily customized or modified systems may fall in this category from a SOX perspective. 6.4.2.1. Major Changes to Existing Systems (SOX and Repositioning) COBIT states that major system changes should follow a process similar to a systems development process, and should contain Change Management. 6.4.2.2. Definition of Interfaces (SOX) COBIT basically states that the system development life cycle methodology should include the requirement that all system interfaces are properly specified, designed, and documented. If you have systems that are significant in your financial reporting process and feed into your financial system, you will also need to include the interface as part of your testing and certification. 6.4.2.3. IT Integrity Provisions in Application Program Software (SOX) COBIT basically states that the application should routinely verify the tasks performed by the software to help ensure data integrity and provide rollback capabilities. As this provides a "Prevent Control," it may be a requirement to use to evaluate future application and/or interfaces you may need to implement. 6.4.2.4. Definition of Interfaces (SOX) COBIT defines that unit, application, integration, system, load, and stress testing should be in accordance with your project test plan. However, from a SOX perspective, if you use production data as part of this process, in essence you have placed your test environment in production, and therefore, all SOX production environment criteria now apply to your test environment. 6.4.3. Acquire and Maintain Technology Infrastructure This section as it pertains to COBIT deals with the acquisition and maintenance of systems related to your IT infrastructure. Depending on the processes you identified to implement from the previous domains, this could impact your open source tools selection. 6.4.3.1. System Software Security (SOX) COBIT states that the setup of system software to be installed does not jeopardize the security of the data and programs. This is true from a SOX perspective as well. If an infrastructure type system interfaces with your financial system (e.g., monitoring, etc.), it too will need to follow the same guidelines as your financial system. 6.4.3.2. System Software Maintenance (SOX and Repositioning) This is in line with 1.15 of Identify Automated Solutions. 6.4.3.3. System Software Change Controls (SOX) As part of your Change Management Process, procedures for system software changes should identified and documented. 6.4.3.4. Use and Monitoring of System Utilities (SOX) This particular control is in line with 3.3, but expands it to include system utilities. 6.4.4. Develop and Maintain Procedures This section as it pertains to COBIT deals with the development and maintenance of procedures for system development activities. However, as previously established, customized or significantly modified systems also fall under this umbrella. 6.4.4.1. Operational Requirements and Service Levels COBIT states that the system development life cycle methodology should ensure the timely definition of operational requirements and service levels. When looking at open source systems and/or application acquisition, you will want to ascertain SLA methodology management and processes. 6.4.4.2. Operations Manual COBIT states that operational manuals should be prepared and kept up-to-date as part of system development methodology. Again, remember that customized or significantly modified applications will also need to be considered. 6.4.5. Install and Accredit Systems This section as it pertains to COBIT deals with the installation and verification of systems before and after migration to production. As with NuStuff or BuiltRight, the Control Objectives in this section are not germane, but we would like to make a few general statements. At the risk of belaboring points already covered, keep in mind that: If required, the focus of these activities should only pertain to systems/applications significant in the financial reporting process. Customized or significantly modified applications will also need to be considered. Control Objectives listed in this section should be incorporated into your Change Management Procedure, whether specific to application/software development or a general Change Management procedure. For specifics on these Control Objectives, refer to Appendix A. 6.4.6. Manage Changes This section as it pertains to COBIT deals with change and the management of that change. If you haven't noticed, the various COBIT Control Objectives fundamentally exist in each domain, and are merely restated as they pertain to a particular domain. Therefore, to avoid redundancy we will cite the previous Control Objectives as they apply to this section and guidelines for Change Management. 6.4.6.1. Change Request Initiation and Control (SOX and Repositioning) COBIT states that change requests for system maintenance and supplier maintenance should be standardized, and have a formal change management procedure. Specific elements should include categorization and prioritization of end-user communications. 6.4.6.2. Impact Assessment (Repositioning) COBIT states that procedures should be developed and put in place to assess the proposed change to the environment. At any point of impact, testing should be performed, whether it be functional or integration. 6.4.6.3. Control of Changes (SOX and Repositioning) COBIT states that Change Management and software control and distribution are integrated with a configuration management system. The change control system should be automated. 6.4.6.4. Emergency Changes (SOX and Repositioning) COBIT states that parameters should be established for defining emergency changes and the procedures that control these changes when circumstances require circumvention of normal processes. All and any changes should have prior approval of IT management and be recorded. This should and could be part of your overall Change Management Process. 6.4.6.5. Documentation and Procedures (SOX and Repositioning) COBIT states that the change process should ensure the appropriate documentation and procedures are updated accordingly when a change occurs to the system. This should and could be part of your overall Change Management Process. 6.4.6.6. Authorized Maintenance (SOX) COBIT states that procedures should be in place to ensure that personnel with system access are monitored, and do not perform unauthorized activities. This can be addressed as part of the access policies and procedures.