Change Control is the process that management uses to identify, document and authorize changes to an IT environment. It minimizes the likelihood of disruptions, unauthorized alterations and errors. The change control procedures should be designed with the size and complexity of the environment in mind. For example, applications that are complex, maintained by large IT Staffs or represent high risks require more formalized and more extensive processes than simple applications maintained by a single IT person. In all cases there should be clear identification of who is responsible for the change control process.

A change control process should consider the following elements:

• Change Request Initiation and Control - Requests for changes should be standardized and subject to management review. Changes should be categorized and prioritized and specific procedures should be in place to handle urgent matters. Change requestors should be kept informed about the status of their request.
• Impact Assessment - A procedure should be in place to ensure that all requests for change are assessed in a structured way for all possible impacts on the operational system and its functionality.
• Control and documentation of Changes - Changes to production systems should be made only by authorized individuals in a controlled manner. Where possible a process for rolling back to the previous version should be identified. It is also important to document what changes have been made. At a minimum a change log should be maintained that includes a brief functional description of the change; date the change was implemented; who made the change; who authorized the change (if multiple people can authorize changes); and what technical elements were affected by the change.
• Documentation and Procedures - The change process should include provisions that whenever system changes are implemented, the associated documentation and procedures are updated accordingly.
• Authorized Maintenance - Staff maintaining systems should have specific assignments and their work monitored as required. In addition, their system access rights should be controlled to avoid risks of unauthorized access to production environments.
• Testing and User signoff - Software is thoroughly tested, not only for the change itself but also for impact on elements not modified.
• Consider developing a standard suite of tests for your application as well as creating a separate test environment.
• The standard test suite will help identify if core elements of an application were inadvertently affected. Maintaining this suite will make it less likely you will forget to test some feature in the future. The separate test environment will minimize disruptions to the production environment. Another important aspect of testing is that you test with transactions for which you know the correct results. Business owners of the systems should be responsible for signing off and approving changes being made.
• Testing Environment - Ideally systems should have at least three separate environments for development, testing and production. The test and production environments should be as similar as possible, with the possible exception of size. If cost prohibits having three environments, testing and development could take place in the same environment; but development activity would need to be closely managed (stopped) during acceptance testing. In no case should untested code or development be in a production environment.
• Version Control - Control should be placed on production source code to ensure that only the latest version is being updated. Otherwise previous changes may be inadvertently lost when a new change is moved into production. Version control may also help in being able to effectively back out of a change that has unintended side affects.
• Emergency Changes - Emergency situations may occur that requires some of the program change controls to be overridden such as granting programmers access to production. However, at least a verbal authorization should be obtained and the change should be documented as soon as possible.
• Distribution of Software - As a change is implemented, it is important that all components of the change are installed in the correct locations and in a timely manner.
• Hardware and System Software Changes - Changes to hardware and system software should also be tested and authorized before being applied to the production environment. They should also be documented in the change log.

If a vendor supplies patches, they should be reviewed and assessed for applicability and potential impact to determine whether their fixes are required by the system.