Change Management Policy

Updated annually.


Skycore is a Software as a Service provider as its primary business. From time to time each Information Resource requires planned upgrades, maintenance, or fine-tuning. Additionally, unplanned outages may occur that may result in upgrades, reboots, or maintenance. As the business grows, the need for a strong change management process is essential.


This policy applies to all changes to architectures, tools, and IT services provided by Skycore to customers. Modifications made to non-production systems (such as testing environments with no impact on production IT services) are outside the scope of this policy.

Change management generally includes the following steps:

  • Planning: Create an implementation plan, schedule, test plan, rollback plan, and communication plan.
  • Evaluation: Evaluate the changes risk, priority, nature to determine change type and process.
  • Review: Review the change plan as appropriate to the change type.
  • Approval: Obtain approval of the change by the management authority.
  • Communication: Communicate about changes with the appropriate parties.
  • Implementation: Implement the change.
  • Documentation: Document the change and approval information.
  • Post-change review: Review the outcome of the changes.


All changes to company informational services must follow a structured process to ensure appropriate planning and execution.

By ITIL definition there are three types of changes:

  • a Standard Change
  • a Normal Change (of low, medium, or high risk)
  • an Emergency

See “Appendix A – Types of Changes and Definitions” for more detailed definitions. Each Change Authority must establish an appropriate complete change management process commensurate with the type of change being authorized (see “Appendix B – Risk Assessment” and definitions of types of changes.)

Minimum Standards

  1. All changes must follow a process of planning, evaluation, review, approval, and documentation.
  1. Change Authorities (CA) will have the authority to determine change type and risk level.
  1. All Standard Changes must have documented procedures called Change Requests(CR ) in place that have been approved by the CA or delegate.
  • All CRs should be reviewed by one other engineer
  • All Normal Low Changes must be approved by the CA
  • All Normal Medium and Normal High Changes must be approved by the Change Advisory Board (CAB).
  1. All Emergency Changes must be authorized by a manager, have the CR reviewed by at least one other engineer, and submitted for review by the CAB in retrospect to ensure that effective oversight was maintained.
  1. Documentation of Normal Medium, Normal High, and Emergency Changes must be logged in a common location so that coordination of changes across the organization can be managed appropriately.

Types of Changes

There are three types of changes:

  1. Standard Change – A repeatable change that has been pre-authorized by the Change Authority by means of a documented procedure.
  1. Normal Change – A change that is not an Emergency change or a Standard change. Normal changes follow the defined steps of the change management process. Low, Medium, or High priority is determined according to the Risk Assessment included in Appendix B
  • Normal Low Changes must be reviewed and approved by the manager delegated as Change Authority.
  • Normal Medium and Normal High Changes must be reviewed and approved by the Change Advisory Board as Change Authority.
  1. Emergency Change – A change that must be introduced as soon as possible due to likely negative service impacts. Any Emergency Change must be authorized by a manager as the CA and reviewed by a peer. The Change Advisory Board must be briefed retroactively.


Definitions adapted from Information Technology Infrastructure Library (ITIL).

Change – The addition, modification, or removal of approved, supported, or baselined hardware, network, software, application, environment, system, or associated documentation.

Change Advisory Board – A group of people that support the assessment, prioritization, authorization, and scheduling of changes.

Change Authority -The person or group authorizing a change.

Change Control – The procedure to ensure that all changes are controlled, including the submission, analysis, decision making, approval, implementation, and post-implementation of the change.

Change History – Auditable information that records, for example, what was done, when it was done, by whom, and why.

Change Log – Auditable log of who, what, why, and when for all changes. This may be system-specific as certain systems have the ability to automatically log changes in this manner.

Change Management – Process of controlling changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved changes with minimum disruption.

Core Service – A service that users directly consume and the organization receives value from.

Critical Operations Windows – Finals week starting on the Monday of that week for each quarter, first two days of classes for each quarter, graduation weekend starting on the Friday of that weekend, and fiscal year-end close.

Change Request – A documented change to the code or to the network requiring approval.

Enabling Service – A service that must be in place for a core service to be delivered.

Enhancing Service – A service that adds extra value to service but is not absolutely required.

Impact – Determined by potential disruption to users, departments, colleges, and the organization as a whole. User means approximately 10 or fewer individuals.

Peer – Another IT professional that can review a change and understand the technical elements involved.

Process Log – A central repository of Changes that documents the process followed for a particular change. The purpose of the process log is to ensure that high-impact changes have been carefully considered and to serve as a basis for process improvement when changes do not go as planned.

Request for Change (RFC) – A formal proposal for a change to be made. It includes details for the proposed change.

Urgency – How quickly a change must be implemented to maintain a stated service level agreement (SLA). Low can wait until the next scheduled CAB meeting, Medium cannot, and High needs to be done ASAP

Risk and Change Type Matrix

Normal and Emergency Changes
First, determine the impact of the change on the service. Then assess the Urgency of the proposed change. Low changes can wait until the next scheduled CAB meeting, Medium cannot, and High needs to be done ASAP.

Low ​Urgency Med ​Urgency High ​Urgency
Impact – All Customers Normal Medium Normal High Emergency
Impact – All High Profile Customers Normal Medium Normal High Normal High
Impact – One High Profile Customer Normal Medium Normal High Normal High
Impact – One Regular Customer Normal Low Normal Low Normal Medium

(Note: A Standard change does not need to use this matrix because the risk is controlled by a pre-approved standardized process)

Change Advisory Board (CAB)

The members of the Change Advisory Board provide a due diligence readiness, assessment, and advice any Request for Change (RFC) that are referred to it for review.

CAB members are responsible for:

  • thoroughly reviewing all change requests
  • raising any potential concerns about the impact or timing of those requests
  • ensuring the changes requested:
    • have undergone proper planning and testing
    • are planned to ensure the lowest possible risk to services
    • are coordinated so changes do not impact each other
    • are coordinated to avoid times of high impact for affected services

Any decision to move forward with an RFC should include approval by the CAB in advance for Normal Medium Changes and after the fact for Emergency changes.


Change Management responsibilities for managers include the following tasks:

  • Review and approve timing and feasibility of RFCs
  • Review and approve RFCs when authorized by CA
  • Engage IT Communications manager to initiate communication with users
  • Ensure that Requestor fills out the RFC accurately and completely
  • Ensure staff availability to successfully complete the RFC

Change Authority

Change Management responsibilities for the CA include the following tasks:

  • Provide advisory input to the Requestor on any needed changes to the RFC prior to
  • Review and approve RFCs when needed
  • Review change outcomes and make process changes appropriately


Change Management responsibilities for the Requestor include the following tasks:

  • Ensure that additional resources are available in case of problems
  • Prepare the request for change (RFC) and submit it to the Change Authority
  • Incorporate feedback from the Change Authority into the RFC
  • Document the outcome of the change

Change Documentation

The following details the kind of information that should be logged for each change and where it will be logged. The Change Log and Process Log can be the same document.
C​hange Log

  • All Standard, Normal, and Emergency changes are logged in the Change Log
  • The Change Log contains information such as: Who made the change, What was changed, Why the change was made (Reason/Comment) When the change was made.

Process Log

  • Medium, High, and Emergency changes are logged in the Process Log
  • Test Plan and Test Results
  • Risk Assessment
  • Communication Plan
  • Deployment & Roll-back Plan