Configuration change management processes may include:
- Identification and documentation of changes.
- Assessment of the potential impact of changes, including security implications, and criticality.
- Identification of a change control authority, which may be vested in either individuals or groups as appropriate.
- Documented review and approval by the designated change control authority.
- Communication of significant changes and their planned schedule to stakeholders using a standard template.
- Identification of schedules and timelines for changes.
- Rollback/contingency plan.
- Testing procedures to ensure the change is functioning as intended.
- Communication of completed change details to stakeholders using a standard template.
- Updating of all appropriate system documentation upon the completion of a significant change.
Each department/unit may identify its own change control methods, and perform a change impact assessment of systems and types of changes based upon impact factors, such as: projected downtime, sensitivity of data, number and dependency of users, cross-system dependencies, technical knowledge of change/system, frequency of similar changes made, support status, etc. An example follows:
Low Impact Changes
Medium Impact Changes
High Impact Changes
|Description of Change||A change intended to repair a fault in an information system or network resource. Such changes may include minor changes to hardware/software components.||A change intended to update or upgrade an information system or network resource. Such changes may include significant changes to hardware/software components.||
A change intended to result in major changes to an information system or network resource.
Such changes may include replacing entire systems or fundamental changes to the system. Such changes may include significant changes to hardware/software components.
|Pre-change Requirements||A contingency plan must be in place.||A documented risk assessment must be conducted on the change. A contingency plan must be in place.||Information systems or network resources that are being changed must be fully recoverable. A documented risk assessment must be conducted on the change. A contingency plan must be in place.|
|Change Control Authority||System administrator with documented pre-existing authorization from Manager/ Administrator||Manager/Administrator||
• Campus ISO (if appropriate)
• MPP-level approval (if appropriate)
|Change results must be logged and appropriate configuration documentation updated.||Change results must be logged and appropriate configuration documentation updated.||Change results must be logged and appropriate configuration documentation updated.|
Sample change management request form (RFC)
- used by ITS systems team in OTRS
- (*indicates required information)
- Change Request Title * (note in subject if urgent)
- Description: *
- Servers/Services/Systems Affected:*
- Upstream/downstream servers/services/applications affected (e.g., e-mail not available during upgrade, HRMS unavailable or a specific machine will be unavailable):*
- Proposed Start Date and Time:*
- Expected Outcomes:*
Other system or services changes related to this change, also note any dependencies which must occur before this change, or any changes which require this change before they can be completed
Who will be contacted, by whom and how. (e.g., Helpdesk + Students + Staff, ITS, CCCC, All MPPs)
- Test plan:*
Include possible visible outcomes and potential impacts. Also include when the rollback would occur and its duration
An inventory of all servers should be maintained (by the department or campus) indicating the operating system version, directly or indirectly-exposed applications which present a potential risk of security exploitation, the current patch level of critical components and designated administrators.
Department and unit patch management standards and procedures may include:
- A timeline for applying (or deciding not to apply) patches for network-connected devices.
- A procedure to address exceptions for not installing or for removing security patches. Such patch application decisions must be documented and state reason(s) for not installing or for removing a security patch, and should include appropriate management review and approval.
- A rollback procedure to remove patches that interfere with production services.
- A post-installation verification to ensure patches are at intended level.
- MPP-level approved process for ensuring periodic review and confirmation that patches are updated on a regular basis.