Change Management Procedure
A. Purpose
Change Management helps to assure that system and data integrity controls are appropriate for systems which process Sensitive Data, including network administration, research system configuration control, research system software, proprietary (application) software and research data.
B. Responsible Office and / or Officer
The Project Owner / Project IT Custodian is responsible for reporting any changes to system configurations, installed software, etc. The Lamont IT Department is responsible for categorizing the change requests and approving, denying or modifying the changes.
The Lamont IT Department is responsible for the maintenance of this procedure, and for responding to questions regarding them.
C. Scope
This procedure is required whenever a change is planned for the following aspects of the Lamont network and research computing platforms that process, store or access Sensitive Data:
- System configurations
- System software
- Application software
- Proprietary software
- Procedures
- Processes
- Infrastructure
D. Risk Matrix
Changes are classified into three different priorities, based on the potential impact that would occur in the wider Lamont network:
- Priority 1
- Crosses organizational boundaries, serving the business functionality of many units. Is critical to the ability of Lamont to meet its business and regulatory obligations, support the delivery of education, or administer research.
- Priority 2
- The system is a feeder to Priority 1 systems; or is a system that does not cross organizational boundaries, but is still critical to the ability of Lamont to meets its business and regulatory obligations
- Priority 3
- Any research computing system that supports the internal operations of any research group or departmental function and does not cross organizational boundaries.
E. Change Classification
Changes will be classified into four categories:
- Classification
- Routine
- Description
- A Routine change is one that has relatively low risk with well-understood outcomes that is regularly made during normal business. A routine change follows predetermined processes and can be performed with zero impact on users.
- Change Request Required
- Notification of change for record keeping only
- Approval Required
- No
- User Notification Required
- No
- Classification
- Minor
- Description
- A Minor change is one that has low to medium risk for critical services, involves less understood risk, has less predictable outcomes, and / or is a change that not regularly made during normal business. Because of the ability to affect downstream or upstream services, changes must be reviewed and approved before implementation.
- Change Request Required
- Yes - submit Change Request before the change
- Approval Required
- Yes
- User Notification Required
- Yes, unless the impact is transparent to users
- Classification
- Major
- Description
- A Major change is one that has medium to high risk for critical services, involves unknown risks, and involves downtime which impacts a large percentage of users across Lamont or Columbia University.
- Change Request Required
- Yes, at least two days before the change
- Approval Required
- Yes
- User Notification Required
- Yes
- Classification
- Emergency
- Description
- An Emergency change is one that involves services which are already impaired and requires the utmost urgency to resolve. The approach here is to fix the problem first and document the change afterwards. Root-cause analysis must be performed to determine if the issue can be prevented in the future
- Change Request Required
- Notification of change for record keeping only
- Approval Required
- N/A
- User Notification Required
- N/A
F. Procedure
-
Request for Change
Open a ticket at askit with the keyword "[Change Management]" in the subject which answers the following questions, at a minimum:
- Change Classification (Routine, Minor, etc.)
- When is the requested date to perform the change?
- What are the proposed technical changes?
- What systems are impacted?
- Why is the change necessary?
- What people will be involved in performing the change?
- Was this change tested in a non-production environment and by whom?
-
LDEO IT Response
- Approval - the change will be scheduled and communications will be sent to the appropriate group or groups.
- Denied - the request will be closed OR modifications will be requested.
-
Implementation
After proper approval notification, the change is released / performed on the date and time communicated.
-
Testing
Test the change thoroughly to verify success.
-
Review
- If the change is successful, communicate that to the relevant users and peers, update the ticket to indicate the change was successful.
- If the change failed, communicate that to the relevant users and peers, attempt to restore the previous state of the system and update the ticket with all relevant information as to what went wrong and possible solutions to the issue.
- Update the project's Information Asset Inventory to reflect the new state of the system.
G. References
See the CU Registration and Protection of Systems Policy here: https://universitypolicies.columbia.edu/content/registration-and-protection-systems-policy