Alternative Project Initiatives for Controlling the UAT Environment
(Part 1 of 2)
By: Mitchell H. Levine, CISA
Audit Serve, Inc.
One of the hot audit issues which is being debated as part of the IT General Controls portion of the Sarbanes Oxley 404 Project and has been a focus area of IT Audits is the manner in which the User Acceptance environment is being controlled (referred to hereafter as UAT). There are four separate control initiatives relating to the UAT environment; (1) Security access controls to preserve the integrity of the UAT test, (2) Enforcement of SDLC requirements to perform UAT Testing (3) Providing a quality UAT environment to support testing
requirements (4) Providing a secured migration path for production changes and ensuring that the test migrated to
production was the version tested.
Security access controls to preserve the integrity of the UAT test
It has always been understood that access to the production environment needs to be secured to prevent
unauthorized updates. The need to restrict access to the UAT environment is predicated on the view that the integrity of the UAT test needs to be preserved. The security requirements include restructuring access to the online transactions which update the data and restricting batch access to data which can be updated via utilities/programs. It is recognized that if automated data restore process have not been established, the development group would require update access to the data in order to set-up the test environment.
A risk assessment of your organization should disclose whether the disclosure of data (e.g., social security numbers) is of any consequence. This impacts the test data which can be used within your organization. Typically production data is used as the test data in the UAT environment. However, if there is sensitive data, either the data needs to be manipulated prior to its restoration to the UAT environment or access to the data through the UAT environment needs to be tightly controlled which included restricting access to online transactions and batch access which can view data.
The security over the directories which stores that application programs also needs to be restricted in the UAT environment. If the migration of programs to production does not occur from the UAT environment then the risk of unauthorized access is limited to preservation of the integrity of the User Acceptance Test. If programs are migrated from the UAT to production after the completion of the UAT test then the risk of unauthorized access is greater.
Enforcement of SDLC requirements to perform User Acceptance Testing
The quality of the User Acceptance Test is ultimately measured based on tracing the origin of the defects.
Unfortunately most organizations do not have mature control processes which can identify the root-cause of the system problem.
Organizations should have testing standards established which reflect the type of development performed and technology used by the organization. For example, an organization which uses a thirty party vendor product in which customization is performed at the report level should have specific test requirements for report changes as compared to a full functional vendor release which would require an integrated test to be performed. This brings into question the type of SDLC (Systems Development Life Cycle) used within an organization.
Establishing a SDLC which defines the phases of development and the key deliverables associated with each SDLC phase is a standard framework found in most large organizations. However, establishing an SDLC which scales the SDLC deliverables and the components of these deliverables based on the type of development activity provides a more reasonable framework. Implementing a generic SDLC is not easily acceptable because
the SDLC components required for a major enhancement is quite different from a minor maintenance fix which does not involve any changes to calculations or selection processes.
In order to ensure that the development group is complying with SDLC and change control standards, a separate group should be responsible for performing reviews at various checkpoints of the development life cycle to ensure that key deliverables have been established. These review would consist of ensuring that SDLC deliverables have been established based on the type of development activity. The two system enforceable checkpoints are prior to the migration of code into the UAT environment and prior to the migration to production.
For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at Levinemh@auditserve.com.
Copyright 2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.