Alter Control

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

A change control process should consider the post-obit elements:

  • Change Request Initiation and Control - Requests for changes should exist standardized and field of study to management review. Changes should be categorized and prioritized and specific procedures should be in place to handle urgent matters. Alter requestors should be kept informed nigh the status of their request.
  • Impact Assessment - A procedure should exist in identify to ensure that all requests for change are assessed in a structured manner for all possible impacts on the operational organisation and its functionality.
  • Control and documentation of Changes - Changes to product systems should be fabricated just past authorized individuals in a controlled manner. Where possible a process for rolling dorsum 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 clarification of the modify; engagement the alter was implemented; who made the change; who authorized the modify (if multiple people tin can authorize changes); and what technical elements were affected by the alter.
  • 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 improver, their system admission rights should exist controlled to avert 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 besides every bit creating a split up test environment.
  • The standard test suite will help identify if cadre elements of an application were inadvertently affected. Maintaining this suite will make it less probable you will forget to test some feature in the future. The separate test environment will minimize disruptions to the product 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 blessing changes existence made.
  • Testing Surround - Ideally systems should accept at least three carve up environments for development, testing and product. The examination and production environments should be as similar as possible, with the possible exception of size. If price prohibits having three environments, testing and development could take place in the same environment; but development activity would demand to be closely managed (stopped) during acceptance testing. In no instance should untested lawmaking or development be in a production environs.
  • Version Control - Command should exist placed on production source code to ensure that only the latest version is being updated. Otherwise previous changes may exist inadvertently lost when a new change is moved into product. Version control may also help in being able to finer back out of a change that has unintended side affects.
  • Emergency Changes - Emergency situations may occur that requires some of the plan change controls to exist overridden such as granting programmers access to product. Nonetheless, at least a verbal authorisation should be obtained and the change should be documented as soon as possible.
  • Distribution of Software - Every bit a change is implemented, it is of import that all components of the change are installed in the correct locations and in a timely manner.
  • Hardware and Organization Software Changes - Changes to hardware and organisation software should too be tested and authorized before being practical to the production surround. They should also exist documented in the change log.

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