Change Control

To ensure changes to a system, service or application are introduced in a controlled and coordinated manner and to reduce the possibility that unnecessary changes will be introduced without forethought, introducing faults or undoing changes made by others.  Changes require serious forethought, careful monitoring, and follow-up evaluation to reduce negative impact to the user community and to increase the value of Information Resources. The Change Management process is designed to control the implementation of all changes made to any device, system or application within the Bryant University production environment. 
The purpose of this document is to formalize the requirements for change management for hardware and software changes to ensure that a consistent and systematic approach is used for modifying Bryant University’s IT resources.  The goals of change management include minimal disruption to services, reduction in back-out activities, and cost-effective utilization of resources involved in implementing change.  The intent is to streamline processes while mitigating risk and potential loss due to system outages.

In general, all changes shall be planned, approved, tested, and documented. They will undergo subsequent review by the Change Review Board. Every change to a Bryant University’s Information Technology Resources such as: operating systems, computing hardware, networks, and applications is subject to the Change Management Guidelines outlined in this document.

Any change that might affect IT resources upon which Bryant University’s personnel relies to conduct normal business operations are within the scope of this document. The following non-exhaustive list depicts common types of change:

• Software upgrades, updates or additions
• IT Infrastructure changes
• Preventative maintenance
• Security patches
• System architecture and configuration changes
• Hardware upgrades

• The University change management system will be used to log, monitor, track, approve and follow-up evaluation of Request for Change (RFC) submittals.
• Only authorized staff shall perform the changes, with the changes endorsed by the application or system owner(s).
• Assessment of the potential impact of such changes shall be conducted.
• Audit trail of all changes, configuration changes made, person who performed the change, date of the change, purpose of the change, whether the change was a success or failure and other relevant information shall be recorded and retained.
• Procedures for testing and approval of changes shall be implemented prior to promotion to production.
• Procedures identifying responsibilities for aborting and recovering from unsuccessful changes shall be implemented.
• Information users shall be notified regarding how these changes shall impact them.  If system availability will be affected while the change is being made, notify affected individuals letting them know what to expect and when to expect it. They should also know whom to contact in case they experience difficulty as a result of the change.
• Current backups and roll-back procedures shall be available when changes are made.
• The application or system owner may deny a scheduled or unscheduled change for reasons including, but not limited to, inadequate planning, inadequate back-out plans, the timing of the change will negatively impact a key business processes such as year-end accounting, or if adequate resources cannot be readily available. Adequate resources may be a problem on weekends, holidays, or during special events.
• In certain circumstances emergency changes can be made with approvals being documented after-the-fact.  System failures or the discovery of security vulnerability may necessitate emergency changes.
• From time to time information technology infrastructure components may require an outage for planned upgrades, maintenance or fine-tuning. Additionally, unplanned outages may occur that may result in upgrades, maintenance or fine-tuning.  Whenever possible and where applicable maintenance windows will be defined to limit the impact to productivity.

COMPLIANCE

The University considers any violation of the directives outlined within this document to be an objectionable offense. Failure to comply may subject the violator to disciplinary action by the University.

EXCEPTIONS

Any exceptions to directives outlined within this document are to be reviewed and approved by the Security Management Team, as needed.