Change Management Policy

Scope:
Change requests are to be submitted submitted to the VP for MIS, General Manager ,
MIS Manager, Risk Management, and Internal audit.  The change should not be
completed until reviewed and approved according to procedures defined within this
policy.  All sections of the change request should be completed in a thorough manner. 
The documentation must identify the scope of the change, areas affected, back-out
process, testing completed, communication plan and planned date of deployment.  This
to be done at a level to ensure the scope as described can be accomplished and to
provide assurance that the change will have the desired result.  Once a change request is
submitted it will be known as a change item and is assigned a change number.

Any change item affecting the high security environment should be noted as such with
any additional fields/requirements completed appropriately.
Any change item with an impact on PII (Personally Identifiable Information) should be
noted as such with any additional fields/requirements completed appropriately.

The purpose of this policy is to:

 manage changes to the IT infrastructure to enable MIS staff members and

Divisions to plan accordingly
 to reduce the impact of changes on other tasks/projects
 promote communication and collaboration regarding change items
 to share knowledge with the MIS Division regarding infrastructure modifications
 enable a smooth beginning and startup of Network and Servers daily
 minimize the likelihood of outages
 maintain compliance to applicable regulations

Policy:
The following outlines the process for submitting, reviewing, approving, deferring and
closing technology change items.

Submittal of a Change Request

Change requests are to be submitted to the VP for MIS, General Manager , MIS
Manager, Risk Management, and Internal audit.  The change should not be completed
until reviewed and approved according to procedures defined within this policy.  All
sections of the change request should be completed in a thorough manner.  The
documentation must identify the scope of the change, areas affected, back-out process,
testing completed, communication plan and planned date of deployment.  This to be
done at a level to ensure the scope as described can be accomplished and to provide
assurance that the change will have the desired result.  Once a change request is
submitted it will be known as a change item and is assigned a change number.

Any change item affecting the high security environment should be noted as such with
any additional fields/requirements completed appropriately.

Any change item with an impact on PII (Personally Identifiable Information) should be
noted as such with any additional fields/requirements completed appropriately.

Review of New Change Items

New change items are reviewed during the change meeting. The leader of the change
meeting is to review each pending change item with the group to ensure all attending
understand the change and its dependencies. Items that are understood and agreed to
by all are motioned for approval. Any incomplete requests will be held or deferred as
decided on during the change meeting.

Approval & Deferral of Change Items

Authorization of a change item occurs after the change is reviewed and depends on the
priority of the item as described in the table below.

Change
Timing /
Type Authorization Discussion Notes

Standard his type of change These changes Considered SOP

is performed on a bypass the (standard
regular basis and approval operating
is considered process.   procedures)
routine. Standard Chance
changes are Manager team
typically created manager
through one of the always has an
various change option of
templates classifying
available. A user some standard
cannot create a changes as
standard change major or
in the same emergency,
fashion as other forcing through
changes.  the approval
process
 Change
Timing /
Type Authorization Discussion Notes

Emergen This type of Approval Emergency

cy change is usually Required
a response to a
failure or error that
needs an urgent
fix. Emergency
changes must be
made quickly and
is usually
recorded after the
change has
already been
made.

Major This type of Approval Non-Emergency. 

change requires a Required Similar to 
lot of items or Significant but
dependencies and the impact is less
may require other
associated
change requests.

Minor Small changes or Approval Non-Emergency

changes that have Required
a small or minor
affect are
classified this
way.

Significa These changes Approval Non-Emergency

n have a large Required
impact on the
organization. 
Similar to major
except that
significant
changes might
 Change
Timing /
Type Authorization Discussion Notes

need to be divided
into several partial
subsequent
changes that
together would
constitute a large
significant
change,
depending on the
policies and
requirements of
your organization.

Items that are not approved according to the table above should not be implemented
until the review and approval process is followed. Unapproved change items should only
remain so for a short period of time (1 or 2 change meetings only). Items that cannot be
approved and/or will not be deployed in a reasonable timeframe should be moved to
deferred status and reactivated when the change is ready for deployment.

Closing a Change Request

Change items that are previously approved and subsequently deployed are reviewed for
closure during the change meeting. The owner of the change (or an informed
representative) should be available at the change meeting to discuss the
implementation.  The review should note the status of the change item execution and
any service or datacenter infrastructure impacts.  If the change has performed as desired
it may be closed.  In the event a change does not perform as expected or causes issues to
one or more areas of the production environment, the attendees of the change meeting
will determine if the change should be removed and the production environment
returned to its prior stable state.  Appropriate action should be noted within the change
application and successfully acted upon prior to marking the item closed.

Change Meeting Attendance

To ensure successful review, approval, implementation and closure of change items,

each core ITS service area should be represented during the change meeting.

Definitions:
Change Management—the process of requesting, developing, approving, and
implementing a planned or unplanned change within the ITS infrastructure.
Change Item (or Change Request)—a documented request to modify the ITS
infrastructure. This to be completed via the ITS Change Management Application.

Datacenter Infrastructure—the network, server, storage, programs, database and

solutions technologies managed by the CWSLAI MIS DIVISION.

Emergency - Any interruption of in scope systems or services including down systems,

service outages and unplanned system restarts.  Emergency items must be approved by
a Director.

Urgent -  Any change that had to be deployed prior to a scheduled change meeting in
order to continue CWSLAI Datacenter operations and services.  Urgent items must be
approved by a Director.

Normal - Any requested and scheduled change to in scope systems and services.  To be
submitted but not implemented prior to change management meetings.

Major & Minor - See definitition above.  Level determined by components of risk and
impact questions in the ticket creation. 

The level of authority required to authorize a change is determined by the type of

change. 

 Emergency
 Urgent,
 Normal Major
 Normal Minor

Compliance with Legal and Regulatory Requirements:

Per BSP 808, the change management procedures should be formalized, enforced and
adequately documented. Authorization and approval are required for all changes and
the personnel responsible for program and migration should be identified. For the
purpose of accountability, proper sign-off should be adequately implemented where
formal acknowledgement is obtained from all related parties.

Policy Adherence:
Failure to follow this policy can result in disciplinary action as provided in the Staff and
Employment Guide, and Faculty Handbook. Disciplinary action for not following this
policy may include termination, as provided in the applicable handbook or employment
guide.

Exceptions:
Exceptions to this policy will be handled in accordance with the MIS Security Policy.
Review:
This policy, and all policies, standards, handbooks and supporting materials contained
within, will be reviewed by the ISO(Information Security Officer) on an annual basis.

Emergencies:
In emergency cases, actions may be taken by the Incident Response Team in accordance
with the procedures in the MIS Information Securiy Policy. These actions may include
rendering systems inaccessible.