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:

E. Change Classification

Changes will be classified into four categories:

F. Procedure

  1. 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?
  2. 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.
  3. Implementation

    After proper approval notification, the change is released / performed on the date and time communicated.

  4. Testing

    Test the change thoroughly to verify success.

  5. 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: