IS Problem- and Change-Management Strategies and Policies

To coordinate the planning, design, and implementation of changes that could affect the connected systems or data, such as upgrading hardware or software or adding services, the organization should develop a change-management process. The change process is usually facilitated by a chartered change control board (CCB). A CCB generally is charged with reviewing all changes in the environment and has the authority to accept, deny, postpone, or send back a change request for additional information. The CCB is in place to ensure that the implementation of changes does not disrupt the availability or integrity of data, introduce vulnerabilities, or allocate resources (personnel and money) to projects or changes that do not meet business objectives. The change-management process establishes an open line of communication among all affected parties and allows those parties to provide input that is instrumental in the implementation process as it unfolds.

Change management is an integral part of any production IT infrastructure; it not only approves change in the environment, but it also can schedule changes and monitor milestones of changes that are in progress. The CCB is usually composed of members from the information systems department, as well as senior managers from the business functions. The CCB usually includes an administrator who is responsible for receiving, documenting, and scheduling the review of change requests (CR). The CR should contain all the information necessary to allow the CCB to make an informed decision about the change. A CR typically contains this information:

• Originator of the CR

• Reason for the change

• Work breakdown structure:

  • Project/change milestones

  • Resources required (personnel and budget)

  • Amount of time the change will take

  • A backout plan if the change does not work

  • User acceptance testing procedures

• Documentation (such as user/system manuals)

• Risk assessment:

  • What happens if the change is not made

  • Potential effects of the change

  • Issues that affect availability, integrity, or confidentiality of systems

The CRs generally are reviewed by subject matter experts (SMEs) before they are submitted to the CCB and include suggestions or concerns. The SME can be in the business or IT area and can include business managers, users, security personnel, application developers, or network and systems engineers. SMEs provide the board with enough information to make a decision on the request and to understand the impacts in the environment. A formal change-control process is generally applied to systems and application development, but it can apply to network, security, and documentation changes as well.

In a development environment, the CR identifies how the object code will move from development to a test library and how it will test security and control features. The CR also defines how the program will be introduced into the production environment, as well as data conversion, user training, and documentation.

The presence of a formal change-control process ensures that other governance and procedures (project planning, security, and so on) are formally involved in environment changes. In a development environment, it helps to ensure proper segregation of duties because programmers should not be able to make changes to production code and introduce the chance of fraud.