BP.00.002 - Business Practice for Change Control

Printable Version in PDF Format (Get Adobe Acrobat) (PDF, 140KB)

Table of Contents

History [top]

  • Business Practice Number: BP.00.002
  • Version: 6
  • Drafted By: Neal Fisch
  • Approved By: Michael Berman
  • Approval Date: 07/21/2010
  • Latest Revision Date: 02/02/2017

Purpose [top]

Describe the management of production hardware and software changes at Channel Islands.

Background [top]

Change Management is the process of implementing changes to an information resource in a controlled, orderly manner, which helps to ensure that the intended purpose of the change is successfully accomplished and eliminates or minimizes any negative impact to the users of the resources as a result of the change. Proper application of change management also minimizes unwanted reductions in security and provides an accurate record of changes and associated supporting documentation that is useful when planning future changes.

Business Practice [top]

Accountability [top]

Vice President for Information Technology Services

Applicability [top]

All ITS employees.

All hardware and software production systems used at CI, regardless of their location. This includes end-user computing devices (ie. Laptops, desktops, and tablets), all servers (physical or virtual), and software running on these servers or end-point devices.

All production network equipment including but not limited to, routers, switches, and any associated wireless or telecommunications equipment.

Definition(s) [top]

  1. Change. Any modification to the software, hardware, or firmware of a network component, server, end-user device, or service in production use.
  2. Change Control Administrator. The ITS employee responsible for administration of the Change Control program, including the retention of Requests for Change (RFC). The Change Control Administrator is also responsible for maintaining the change calendar and change repository.
  3. Change Control Board. The team responsible for approving risk level 4-5 changes. The Change Control Board
    1. Director, Enterprise Services and Security
    2. Manager, Infrastructure
    3. Director, Academic Technology
    4. Manager, User Services
    5. Director of IT Strategy
    6. Information Security Officer
  4. Change Calendar. A calendar available to all ITS employees listing changes that have taken effect and that are scheduled to take effect. The RFC should be directly accessible from the Change Calendar.
  5. Production System. A computer or system used by students, faculty, or staff as indicated in the systems and services inventory.
  6. Minor Service Interruption. A period of service unavailability lasting for less than 1 hour, impacting less than 10 concurrent users and has no life and safety implication.
  7. Major Service Interruption. Any interruption that is not a minor interruption.
  8. Pre-Approved Change. A pre-approved change is a change that is low risk, relatively common, follows an established procedure, and is the accepted solution to a specific requirement or set of requirements. The Change Control Board determines which changes can be pre-approved. Pre-approved changes are maintained in the change control repository and change calendar.
  9. Emergency Change. A change that requires immediate unscheduled implementation to correct or respond to an imminent service outage or disruption. .
  10. Normal Change. A change that is not classified as a pre-approved or emergency change.
  11. Risk Level. A score determined by the ITS Risk Level Worksheet used for assessing the risk of a change. It is based on the complexity and impact of the change
  12. Change Initiator. The ITS staff member responsible for:
    1. Planning the change,
    2. Submitting the appropriate change control documentation,
    3. Leading the implementation of the change,
    4. Initiating the quality assurance process following the change, and
    5. Documenting the completion of the change
  13. Change Team. The ITS staff members responsible for implementing the change.
  14. Change Manager. The manager that supervises the change initiator.
  15. Change Owner. The individual and department that is the functional owner of the hardware or software being changed.
  16. Quality Assurance Team. The ITS staff members responsible for assuring that the change has been implemented correctly and that there is no negative impact on campus systems or services.

Text [top]


Change Procedures

Normal Change Procedures for risk Levels 1-3

  1. Change initiator submits a request to their Change Manager.
  2. If requested, additional information is provided by the Change initiator or other relevant parties.
  3. Approval or rejection by Change Manager.
  4. Change is posted to Change Calendar.
  5. Appropriate communication is made to affected user groups, change team, the change owner, and the change manager.

Normal Change Procedures for Risk Level 4-5

  1. Change initiator submits an RFC to their Change Manager. Scheduling lead time is 1 week, minimum.
  2. If requested, additional information is provided by the Change initiator or other relevant parties.
  3. Consultation with relevant subject matter experts.
  4. Implementation and testing in a test environment.
  5. Approval or rejection by Change Manager.
  6. If approved, must be approved by ISO.
  7. If approved by ISO, approve or reject by Change Control Board.
  8. If approved, change is posted to Change Calendar.
  9. Appropriate communication is made to affected user groups, change team, the change owner, and the change manager.

Pre-Approved Change Procedures

Each department should implement its own process for implementing Pre-Approved Changes. For a standing approval to be issued, each category of Pre-Approved Change should go through an initial Normal Change Procedure. All Pre-Approved Changes are required to be reviewed and approved by the ISO. A risk analysis form must accompany any pre-approved change request.

Each Pre-Approved change should be:

  1. Documented in a manner consistent with the department's standards for Pre-Approved Changes. There may be more than one type of documentation, depending on the department's processes (i.e. firewall changes may be documented differently than computer patches)
  2. Scheduled during pre-approved time periods or scheduled with sufficient notice to reschedule if necessary.
  3. Ensure staff is available for an appropriate amount of time after the change in the event of problems.

Emergency Change Procedures

Each department should implement its own process for implementing Emergency Changes. Due to the emergency nature of the change, the process should be flexible to allow efficient resolution of the problem.

Emergency changes should:

  1. Notify the affected user groups and ITS management by an appropriate communication method.
  2. The Change Initiator should seek approval from the appropriate ITS manager for the change if possible or expedient.
  3. In a timely manner, submit all appropriate documentation to the appropriate people, such as the Change Manager.
  4. In a timely manner, update the Change Calendar to reflect the approximate time the change was implemented.
  5. Ensure staff is available for an appropriate amount of time after the change in the event of problems.
  6. Within 5 working days of an Emergency Change, all change documentation required for a High Risk Normal Change is due to the Change Control Board and ISO for retroactive approval and document storage.

Scheduling Procedures

All changes should be scheduled based on urgency and potential conflicts with university needs.  

Any changes that are designated as Impact level 3-5 according to the RFC evaluation rubric shall be completed outside of the following business hours while classes are in session: 8:00am - 10:00pm Monday thru Thursday, and 8:00am - 6:00pm on Friday. Changes to CI's Common Management System (CMS) instances are scheduled by the Chancellor's Office and are exempted from this scheduling restriction.  Exemptions from this scheduling restriction will be approved in writing by the VP of ITS.

Changes involving a minor service interruption should be scheduled in a manner to not disrupt the business of the University.

Changes involving a major service interruption should be reserved for campus maintenance windows.

Campus maintenance windows shall be determined by the Change Control Board, based on the number and duration of scheduled Standard changes.

The Change Manager is responsible for best-effort scheduling of major service interruption changes around campus events.

Quality Control Procedures

After the completion of any Normal, Pre-Approved, or Emergency RFC, the Quality Assurance Team should test and verify that the change was completed to specification.

Communication of Changes

Prior to implementation of Normal and Pre-Approved changes, affected user groups must be notified of the upcoming change. Notification should be given far enough in advance to permit rescheduling.

Appropriate notification methods include, but are not limited to:

  1. Email
  2. Announcements posted on a public website

All changes must be logged in the Change Calendar.

All production changes require communication to the affected parties.

All members of the change team, the change owner, and the change manager must be notified in advance of a Normal or Pre-Approved change, by an appropriate method.

Location of documentation for changes

All change-related documentation must be placed in the ITS Change Repository. The Change Control Board defines the Change Repository. The location and instructions for accessing the ITS Change Repository will be communicated bi-annually (May 1st and November 1st) by email to all members of the ITS staff.

Change blackout periods

Except as required to respond to or prevent a system outage or disruption in services, or for changes required to comply with business process changes for regulatory systems, no major changes will be performed during the following periods:

  1. One week before the first instructional day of each semester to one week after the first instructional day of the semester (two weeks total), and
  2. One week prior to the day that final exams commence until after instructors' grades are due.

Emergency changes are exempted from change blackout periods.

The Change Control Board may specify other change blackout times as required to support notable campus-wide events or other occurrences critical to the University's mission.

Waivers from change blackout periods may be granted by the Change Control Board.

Ongoing review

ITS will review and document the effectiveness of this business practice on an annual basis, and make such changes as may be needed to improve the process.

Exhibit(s) [top]

These documents are incorporated by reference. Please consult the ITS Policy website for the latest versions where applicable:

Instructions for Completing a ITS Request for Change (RFC) (PDF, 305KB)

ITS Request for Change (RFC) Template (PDF, 2.2MB)

Integrated CSU Administrative Manual, Policy 8055.0—Change Control.

Integrated CSU Administrative Manual, Policy 8065.0 – Information Asset Management

Information Security Data Classification Standard – 8065.S02

ITS Firewall Ruleset Configuration Change Form: created and managed in Track-It using the following process:

  1. Network technician logs into Track-It, and opens a Help Desk ticket as follows: Set Type to "Infrastructure", Set Subtype to "Network", and Category to "Firewall RFC"
  2. Technician chooses "Actions" menu > Template > RFC Firewall Rules. This pastes Firewall Ruleset Configuration Change Form template into Technician notes.
  3. Technician edits the notes, and saves the work order/change request.
  4. Manager of Infrastructure gets email notification from Track-It.
  5. Manager of Infrastructure reviews and gives preliminary approval, then emails request to ISO.
  6. ISO reviews, and emails approval to Manager of Infrastructure.
  7. Manager of Infrastructure marks final approval in Track-It.
  8. Change Manager submits request to be added to Change Calendar.
  9. Technician receives automatic email notification that it has been approved.
  10. Technician can proceed with requested firewall change.

Assessment History [top]

DescriptionFrequencyRole Assigned
Review of business practice   AnnualInformation Security Officer