CET Change Management Process [Coming Soon]

Overview

Purpose of this Procedure

Change management processes exist to minimize the chances of introducing cybersecurity risks to the ECU network resulting from modifications to the CET IT (Information Technology) infrastructure and systems. This procedure outlines change management procedures including initiation, planning, evaluation, execution and documentation.

Description of Procedure

This procedure applies to planned changes to critical CET IT infrastructure which could adversely impact campus cybersecurity. Critical IT infrastructure refers to IT assets that connect to "The University Network" as defined by ECU (East Carolina University) regulation RUL08.10.03. Planned changes may involve hardware, software, configurations or any other features of critical IT infrastructure and assets. Changes that go beyond normal operating procedures and may increase cybersecurity risk to the network if not planned and executed appropriately are subject to this Change Control Process to ensure appropriate planning, approval and execution.

Roles & Responsibilities

• Change Requester – Person(s) or entity requesting the change.
• Change Approver – Person(s) or entity responsible for final change approval.
• Change Implementer – IT person(s) who will perform the change.
• Customer(s) – Persons or entities impacted by change.

Definitions

This section lists unfamiliar or technical terms and terms with special meaning that, when defined, add to the reader’s understanding of the SOP (Standard Operating Procedure).

• Change Control – is a systematic approach to managing all changes to CET IT Resources. The purpose is to ensure that no unnecessary changes are made, that all changes are documented, that services are not unnecessarily disrupted, and that resources are used efficiently.
• Change Management – the process of requesting, developing, approving and implementing a planned or unplanned change within the CET IT infrastructure
• IT Resources – include CET computing, networking, communications, application and telecommunications systems, infrastructure, hardware, software, data, databases, personnel, procedures, physical facilities, cloud-based vendors, Software as a Service (SaaS) vendors, and related materials and services.
• Request for Change (RFC) – a documented request to modify the CET IT infrastructure.
• Statement of Risk – cybersecurity vulnerability impact to ECU network/community

Available To

CET staff

Change Initiation Process

Change requester submits this Request for Change (RFC) form. Each RFC request must describe the proposed change, its impact, its risk and a roll-back or remediation plan. If the risk is significant, the RFC form must describe actions to be carried out to mitigate the risk. The following items must be included when submitting the RFC form:

• Description of change
• Reason for change
• Outage window (if needed, including any time required for rollback, not just the time the system is down)
• Statement of risk
• Impact assessment (downtime, customers affected, etc.)
• Documentation: steps, test plans, roll-back plan (if applicable), any applicable drawings or diagrams

Change Review Process

The CET-IT group meets weekly and reviews new and ongoing RFCs during these meetings. Changes scheduled for a given week must be presented at or before the previous week’s CET-IT meeting. Each RFC in process has an assigned status from the following list:

• New – New request documented; review/approval is requested.
• Assessing – Ongoing impact/risk assessment, change planning.
• Declined – Proposed change has been declined.
• Authorized & Scheduled – Change has been approved and may proceed as scheduled; awaiting implementation.
• Postponed – Approved, scheduled change delayed and pending rescheduling.
• Cancelled – Previously approved change is cancelled.
• Implemented/Review – Change has been implemented; outcomes pending review and documentation via notes to be appended to RFC.
• Closed (with Outcome): Change is complete and all closure information has been documented in TeamDynamix ticket.
• Change Documentation:  Review and discussion by CET IT Ops Group results in designation of a Change Implementer and a change of RFC status. The Change Implementer is responsible for (1) documenting RFC status change and meeting discussion notes via follow up email to the RFC email thread; (2) communicating RFC status, progress, and outcome to the Change Requestor; and (3) documenting change outcome and closure as described below.
• Change Outcomes. Upon implementation of an approved change, the following outcomes may result:
  • Successful: Fully implemented with no unexpected consequences.
  • Partially Successful: Partially implemented; some elements cancelled or postponed for further review.
  • Postponed: Implementation delayed.
  • Aborted: Terminated during implementation with appropriate roll back.
  • Rolled Back: Implemented with unexpected consequences necessitating roll back.

Outcomes of every change implementation must be documented by the Change Implementer via this RFC followed by discussion at the next CET IT Group meeting.

Change Request Closure

• All requests for change are closed out with documentation archived for future reference and retrieval for audit purposes. The RFC/TD ticket is tagged to reference “Change Management SOP” and denotes its origin from the CET IT Ops Group.
• Changes declined for implementation:  Rationale for declining the RFC is documented in the RFC by the CET IT Director or designate. The change request should be closed as described above.
• Changes successfully implemented are documented in the RFC, including any components (parts) of the change that were postponed or cancelled during implementation and subsequently resolved. The change requester (or an informed representative) will be available at a meeting of the CET IT Group to discuss the outcome of the implementation. This final review notes the status of the change request execution and any service or infrastructure impacts. If the change has performed as desired, it should be closed as described above.
• If a change is only partially successful or must be postponed, aborted, or rolled back, it is documented in the RFC and discussed at the next CET IT Group meeting. RFC status change and next-step actions are noted by the Change Implementor in the RFC. Such changes are not closed until next-step actions are implemented and reviewed.