Skip to main content
Indiana Wesleyan University Support Knowledge Base

Change Management Policy


Change management aids in establishing and maintaining stable and secure information systems for all University Information Technology (UIT) customers.  This is accomplished through standardized processes and procedures to track and approve all requested changes to in-scope, production information assets.


Through the change management process, the following five risk indicators should be mitigated:

  1. Unauthorized changes
  2. Unplanned outages
  3. Low change success rate
  4. High number of emergency changes
  5. Delayed project implementations

Effective Date

This policy is effective November 19, 2015.


All changes to in-scope systems and applications must be processed through the change management process to ensure adequate and appropriate planning, testing, and execution.

In-scope changes will be categorized as one of three types of changes:

Standard Changes

Low risk changes with well-understood and predictable processes and outcomes based on a defined trigger.  Standard changes are pre-authorized; thus, may be executed in accordance to the approved, documented requirements.

Standard changes must be documented to the degree possible and as required by the Change Advisory Board (CAB) with the type of change, the timing of such changes, and approval from the CAB.  All standard changes must be processed through the change management process as a normal change prior to being established as a standard change.  Once approved as a standard change, the changes may take place without progressing through the CAB and change management process; however, the CAB may request each instance to be calendared or other documentation to be created as necessary.

Normal changes

Medium or high risk or impact changes that must proceed through the complete change management process.

All normal changes must be presented to and unanimously approved by the CAB in the form of a Change Request in iSupport prior to implementation to in-scope, production systems.  See IWU Change Management Process.

Emergency Changes

Changes to address a threat to the University or repair an issue with an IT system or service.  Very few changes are considered emergency changes.  Failure to plan is NOT an emergency.

Emergency changes are to be authorized by two CAB members or by the CIO and one CAB member.  A change request must be completed and documented post-implementation, if an abbreviated request cannot be created pre-implementation.

General Process

Change management must adhere to the following general process:

  1. Planning: At a minimum, planning must include scope, audience, implementation design, schedule, communication plan, testing plan, and back-out plan.
  2. Evaluation: The evaluation should include an impact analysis, risk analysis, and the change type.  The following questions should be answered to complete the impact analysis:





Has this change been conducted before?



Is this change simple to make?



Does UIT have a clear understanding of what the change will do?



Will the outcome of change be noticeable to customers?



Could this change impact other services?



Could this change potentially result in an extended service interruption?



The resulting scores of the impact analysis should be used to measure the risk according to the following matrix:

System(s) Impacted \ Risk Score

Low (score 0-1)

Medium (Score 2-3)

High (Score 4+)









UIT only





  1. Review: The CAB reviews the change request in the weekly CAB meeting.
  2. Approval:  The CAB approves or rejects the change.
  3. Communication: The project manager executes the communication plan.
  4. Implementation: Implement the change according to the plan and any advice given by the CAB.
  5. Testing: Execute the testing plan.
  6. Documentation: Document the outcome of the change and testing.
  7. Post-mortem review: At the discretion of the CAB, a review of the change with applicable stakeholders for future improvements may be requested.

All change requests will be documented in iSupport according to the Change Management Process

The CAB will meet on a weekly basis with required attendance for each functional area within UIT.  Each member of the CAB is responsible for reviewing each change request for the following two weeks prior to the weekly CAB meeting.  Primary membership consists of the following individuals or their assigned representative with voting rights:

  1. Information Security Officer (Chair)
  2. Director of User Services (Backup chair)
  3. Director of Software Development
  4. Director of Infrastructure
  5. Residential CSR
  6. Non-residential CSR

Each primary member listed above is required to appoint a backup individual in the case of absence and notify the CAB of that backup.


No exceptions to this policy are permitted.


Any faculty or staff found to be in violation of this policy is subject to disciplinary action up to and including termination as required by IWU Human Resources policy and allowed by applicable law.





The addition, modification, or removal of in-scope hardware, software, application, network, system, environment, or associated documentation

Change Advisory Board (CAB)

The oversight committee charged with reviewing and approving changes to in-scope resources

Change Control

The process of ensuring all changes to in-scope, production information resources are made in a stable, secure, and predictable manner.  Also known as change management.

Change Management

The process of ensuring all changes to in-scope, production information resources are made in a stable, secure, and predictable manner.  Also known as change control.

Change Request

The compilation of changes affecting in-scope, production information resources needed by the system owner or project manager

Revision History and Approval


Description of Change(s)

Author / Approver


Draft Policy

Bill Maki



Bill Maki


Reviewed - Draft Policy

Michael Madl



This policy applies to all changes to information technology services provided by UIT.

Any changes to non-priority IT components, such as non-production systems, testing/development environments, and UIT-owned resources, are not in scope of this policy.


19-Nov-2015 - Initial draft created.

20-Oct-2017 - Policy reviewed

Policy information

Last Revision Date: 11/18/2015


Policy Owner: Information Security Officer, UIT

Approved by

Chief Information Officer

Additional remarks

  • Was this article helpful?