Page Settings

  • Show menu: true
  • Use horizontal menu: true
  • Show sidebar: no
  • Skip to main content

    Change Control Board

    The Change Control Board (CCB) helps to ensure that changes to technology systems are communicated well and managed in a rational and predictable manner. The CCB is responsible for enforcing IT Change Management Policy and for overseeing and approving change requests (CRs). The CCB emphasizes both usability and security, and both a member of the front line support team and the ITS: staff member overseeing security serve as voting members.  


    This procedure applies to all production systems that are maintained by, on behalf of or involve the IT resources of ITS.  Systems outside the purview of ITS should also follow this procedure.


    • Assessment of CRs, including considering impact, availability of resources, priorities, authorization, and coordination of changes
    • Vote whether to approve, modify, or deny change requests
    • Discussion of topics affecting the change management process
    • Discussion (from a change management perspective) of topics affecting the business
    • Review backed-out and failed changes
    • Debrief regarding any emergency changes made


    Membership is defined as including permanent members who attend all meetings and ad hoc members who attend meetings based on the agenda. Each permanent member of the CCB has a named designated backup. In the event that a member (or the designate) does not attend the CCB meeting, that member implicitly approves all CCB decisions. Anyone interested is welcome to attend CCB meetings; you do not need to wait for an invitation.

    When can changes occur

    Colorado College has established scheduled maintenance windows. All changes affecting user connectivity and access to IT services must be scheduled within pre-scheduled maintenance windows unless otherwise approved by the CCB.


    • Minor change: routine patches, low impact changes.
      • e.g., Apply a security patch to our Windows server operating systems.
      • e.g., staff/faculty/student not being able to see her/his schedule due to specific access issues.
    • Break / Fix change: a change that is immediately implemented to fix an IT resource outage
      • e.g., A fileserver has gone down due to a bad hard drive, and so the drive is replaced.
      • e.g., A minor programming change to handle a special data condition.
    • Fast track change: a change that has a low probability of impact to the stability of production systems, does not need extensive communication, and has potential benefits from implementing the change sooner rather than later.
      • e.g., Apply a patch to fix a slowness issue on the wireless controller.
    • Firewall rule change: a change to firewall rules to block a threat or open a hole for an application.
      • e.g., A new vulnerability has just been released and we want to create a rule to block it as soon as possible.
    • Major change: has a large impact on more than 20 users, even if simple to implement.
      • e.g., Upgrade to a new wireless controller.
      • e.g., Banner upgrades that affect multiple users/user groups.
    • Emergency change: changes made to address an issue that is impacting service levels because not doing so significantly increases risk or because the usual timeframe is too long.
      • e.g., Take a segment of the network offline so that infected computers cannot spread the infection.
      • e.g., Wireless connectivity is broken because of a recent upgrade to Bradford, and so ITS: staff change Bradford’s configuration as a workaround.
      • e.g., A patch to address a critical security vulnerability.


    • If a CR has been submitted, the CCB meets on the next Wednesday at 9 AM unless conflicting meetings have been scheduled.
    • CRs must be submitted no later than noon the day before CCB meets for consideration at that week's meeting.
    • Regular CRs will go into production no sooner than one week after approval unless the approved CR specifies a different implementation date.
    • Requestors' attendance is necessary to answer questions about the CR they have submitted. Requestors should invite CR stakeholders.
    • Requestors may not vote on their own CRs.
    • Emergency changes by definition need to happen immediately and so CCB approval may not be possible prior to the change.
      • After an emergency change, a CR should still be filled out and submitted to the CCB with the objective of avoiding a recurrence.
      • If possible, attain approval from the relevant cabinet member prior implementing an emergency change.
    • Minor and break / fix changes do not require the approval of the CCB and should be handled via departmental change procedures.
    • Fast track changes may be reviewed over email. CCB members reserve the right to call for a discussion over a meeting to review the change. Fast Track CRs may go into production sooner than one week after approval.
    • Firewall rule changes do not require a CR; just send a message to to notify us of the change.
    • CCB members are responsible to attend each CCB meeting or send in a delegate to represent their area of focus in ITS. 
    • Delegates may only represent one regular CCB member.
    • CCB meeting will not occur if at least three members (or delegates) cannot attend the review/approval meeting.
    • Customer notification must be completed in advance of the regular change.
    • All CRs can be viewed in the OS Ticket agent panel (create a custom search by help topic).

    CCB Members

    Jennifer Golightly – Chair
    Karen Klovdahl
    Eric Raczkowski
    Jeff Montoya
    Weston Taylor
    Andrew Watson