The information resource owner, or designee, is responsible for ensuring that the risk mitigation measures described in this Control are implemented. The intended audience is information resource owners and custodians of high or moderate impact University information resources.

A consistent process is to be used for the implementation of information resource changes. The degree to which change management activities and processes are employed is dependent upon the projected inherent risk of the change (e.g., potential for unplanned disruption of service, corruption/loss of data, or disclosure of confidential information resulting from the change implementation) and the complexity of the information resources (e.g., number of users, interconnections with other systems, or number of components or subsystems).

Change preparation may include:

• 2.1

  Review of results of previously implemented changes to prevent repetitive mistakes or negative impacts.

• 2.2

  Determination of the following:

  • 2.2.1

    The best time/date for implementation (to minimize the impact to users) and the length of time required;

  • 2.2.2

    The net impact to other systems or impact to normal operation during and following the change implementation (inherent risk); and,

  • 2.2.3

    The risk associated with the change implementation (to minimize the risk of disruption of service caused by the change).

• 2.3

  Development of a back-out/rollback plan in the event that the change needs to be reversed and identification of a back-out/rollback window (the time period in which the decision to reverse the change can safely be made);

• 2.4

  Confirmation that the changes will not negatively impact the overall system security.

• 2.5

  Obtaining the concurrence of the information resource owner for implementation of the change.

Change review/approval may include:

• 3.1

  Determination of the level of control necessary based on inherent risk. Typically, the higher the risk the greater the level of control required. Controls include, but are not limited to, levels of approval, types of testing performed, length of review time, and consultation with subject matter experts.

• 3.2

  Review of change-related details, including code review where appropriate, by the individual(s) responsible for approving the change or their designee.

• 3.3

  Review of logs for previous change implementations.

• 3.4

  Formal, documented approval or rejection of the change.

• 3.5

  For changes involving code revision, review and approval shall be performed by someone other than the developer.

• 3.6

  For emergencies, where this is not possible, establish a timely management review process.

Notification must be given to users in a timely manner, including relevant details that would not negatively impact the security of the information resource, such as time and date, nature of the change (e.g., projected net effect), and time needed for implementation. The method of notification should be appropriate to the environment and the user base, but may include email or an announcement posted on the web.

Implementation should be performed in the approved manner, with adequate separation of duties for tasks that are susceptible to fraudulent activity.

Post-implementation review may include:

• 6.1

  Verification that the change occurred.

• 6.2

  Testing of the system post-change.

• 6.3

  Resolution of any problems, if possible.

• 6.4

  Decision on whether to initiate back-out plan.

• 6.5

  Analysis and of any issues or complications

Documentation is performed post-implementation in order to provide a record of change (audit trail) that can be used in preparation for future changes or in future problem or incident handling. Documentation may include:

• 7.1

  Date/time of change.

• 7.2

  Duration or length of time required to implement the change.

• 7.3

  Nature of the change (a brief description of the net effect, including the information resource(s) affected).

• 7.4

  An indication of successful or unsuccessful completion of the change.

• 7.5

  Identification of personnel involved in the change.

• 7.6

  Updates to relevant operational documentation.

• 7.7

  Any relevant documentation from the review & approval process.

• 7.8

  Analysis and “lessons learned” (corrective/preventative actions) for changes that deviated unexpectedly from the plan, resulted in an unplanned disruption of service, corruption of data, or disclosure of confidential information.