Change Control Board
The Change Control Board (CCB) ensures that changes to technology systems are communicated 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).
This procedure applies to all production systems that are maintained by, on behalf of, or involve ITS: resources.
Members are listed on the CCB website and are comprised of a representative group of ITS: staff.
Members are responsible for
- Reviewing, discussing, and voting on CRs (or appointing a delegate to do so on their behalf) within 48 hours of a CR being submitted.
- A delegate can only represent one CCB member at a time.
- Periodically reviewing open CRs and following up as necessary.
- Reviewing backed-out and failed changes.
- Debriefing emergency changes and ensuring they are documented.
Change control process
- On a regular basis, CCB members will review approved CRs which are still open.
- A requester starts the process by logging into OSTicket and creating a new change request (CR)
- CRs must be submitted no later than 48 hours before the change is scheduled to take effect.
- The CCB will review the CR and respond within 48 hours, recording the response in the ticket. Approval is by majority vote (at minimum, a quorum of members or their delegates must weigh in or a CR cannot be approved).
- Once the change has been implemented, the requester logs into OSTicket and closes the CR.
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 these windows unless otherwise approved by the CCB.
Changes which require a CR
- Significant change: has a significant impact on multiple users, even if simple to implement.
- e.g., Upgrade to a wireless controller.
- e.g., Banner upgrades that affect multiple users/user groups.
- Emergency change: immediately implemented to fix an IT resource outage, or to address an issue which cannot wait for the normal process.
- The CR is filled out after the change takes place as a way to debrief and help prevent a recurrence.
- Communicate with the relevant cabinet member.
- e.g., Take part of the network offline so that computers cannot spread an infection.
- e.g., Wireless connectivity is broken because of a software bug, so an upgrade is installed immediately.
- e.g., A patch to address a critical, time-sensitive security vulnerability.
Changes which do NOT require a CR
- Minor change: routine patches, low impact changes, and most firewall rule changes
- e.g., Apply a security patch to our Windows server operating systems.
- e.g., A new vulnerability has just been released and we want to create a firewall rule to block it as soon as possible.