SCOPE: FACULTY AND STAFF

1. POLICY STATEMENTS

1.1. Change management is used to minimize any negative impact to information resources users as a result of changes and minimize unwanted reductions in security.

1.2. This policy provides the requirements for the appropriate management of changes to information resources.

2. CHANGE MANAGEMENT

2.1. A consistent process shall be used for the implementation of changes to information resources. The degree to which change management activities and processes are employed is dependent upon the projected inherent risk of the change and the complexity of the information systems involved.

2.2. Changes to LIT information resources shall be made as per LIT Change Management Standards and Guidelines (Appendix A).

2.3. Potential impacts to security shall be considered during all phases of change management.

2.4. Notification shall be provided to appropriate personnel in a timely manner. The method of notification should be appropriate to the environment and the user base.

2.5. Changes to information systems supporting critical business processes shall be documented. Documentation shall include, at a minimum, the date and time of the change, the nature of the change, an indication of successful or unsuccessful completion of the change, and any relevant documentation from the review and approval process.

3. AUTHORITY AND RESPONSIBILITY

Questions related to this policy should be addressed to the IRM at irm@lit.edu.

Appendix A – Change Management Standards and Guidelines

Change Preparation

Change Preparation consists of steps that are conducted prior to all but Emergency Changes. With regard to Standard Changes, this occurs as part of the pre-approval for types or categories of low-risk changes. This process includes the following elements, where appropriate (based on factors such as risk level) or specifically required by LIT policy.

1. Identification of hardware, applications, and business processes that are affected.

2. Identification of technical and business personnel that will be involved in implementation.

3. Description of the change, including the reason for the change.

4. Development or confirmation of change procedures (e.g., installation process), to include pre-implementation backups where appropriate.

5. A review of prior changes.

6. Analysis of any potential security issues during and after implementation.

7. Determination of Risk Level and/or in-depth risk assessment/impact analysis.

8. Concurrence of the information resource owner that the change should occur.

9. Development of a backout plan and identification of the backout window.

10. Determination of when the change should occur based on urgency and assessment of potential conflicts with business needs. Questions to ask include:

a. Can the change wait until the next scheduled maintenance window?

b. Can the change take place during normal business hours, such as during a lowutilization period?

c. How much staffing is required to implement the change?

d. Does the change need to be scheduled with a vendor's technical support staff, possibly in a different time zone?

11. How much time will be needed to review and test the change?

12. Determination of the length of time required to implement the change.

13. Identification of training needs for technical staff and end users.

Change Review/Approval

Change Review begins with a request for change and ends with a final approval or rejection. The level of controls involved in the change review process depends upon factors such as the information resource's levels of risk and complexity and the results of the risk assessment. Although types or categories of Standard Changes should be approved through this process initially, each individual Standard Change should follow a Standard Change Implementation Process. The Change Review Process includes the following elements, where appropriate or specifically required by relevant LIT policies.

All Levels of Risk

1. For code revision changes developed in-house, a review of the code shall be performed by someone other than the developer.

2. Code revision changes must be approved by someone other than the developer(s).

3. Review of documentation for previous changes.

Elements Based on Risk Level

Low, Non-Standard Change

1. Custodian submits a request for change to the IRM.

2. The IRM identifies relevant stakeholders and data owners and determines the appropriate level of approval required.

3. Code review, if necessary, as specified above.

4. Approval or rejection

Moderate

1. Custodian submits a request for change to the IRM.

2. The IRM identifies relevant stakeholders and data owners and determines the appropriate level of approval required.

3. Code review, if necessary, as specified above.

4. Implementation in a test environment, if available.

5. Analysis of test implementation.

6. Approval or rejection.

High

1. Custodian submits a request for change to the IRM.

2. The IRM identifies relevant stakeholders and data owners and determines the appropriate level of approval required.

3. Code review, if necessary, as specified above.

4. Consultation with additional subject matter experts, if possible and practical.

5. Walkthroughs and tabletop testing.

6. Implementation in a test environment, if available.

7. Analysis of test implementation, including tabletop testing.

8. Approval or rejection.

Notification

Prior to implementation, notification must be given to users in a timely manner, including relevant details that would not negatively impact the security of the information resource. Notification should be given far enough in advance that there is time to reschedule. The best time to implement the change should have already been determined in the Preparation stage. The methods of notification used should be appropriate to the environment and the user base. Methods include:

• Email notification.

• Announcement posted on internal web sites.

• Announcement posted on the public website.

Implementation

Prior to implementation, changes must be approved. After approval, the changes should be implemented as stated in the request for change, in accordance with any restrictions or limitations set forth as part of the approval process, and with adequate separation of duties for tasks that are susceptible to fraudulent activity. Any deviations, along with the reason, should be identified in the Post-Implementation Review and documented.

EXCEPTIONS:

There are only two instances in which changes to information resources may be made without a per-change approval:

1. Standard Change - A pre-approved change that is well known, low-risk, follows established procedures and is an accepted response to particular requirements or events. Examples may include: hardware failure fixed by vendor, download and installation of virus DAT files, installation of approved software, replacement of a desktop computer based on approved replacement cycle, or application of tested operating system patches.

NOTE: Changes requiring code revision should NOT be considered Standard Changes.

2. Emergency Change - A change that requires immediate unscheduled implementation to correct an existing or prevent an imminent service outage or disruption.

Emergency Change Implementation

This process must be flexible, as emergency changes are typically time sensitive, and should contain the following elements, where appropriate:

1. Notification of appropriate personnel.

2. Immediate approval, if possible, or prior approval to make emergency changes.

3. Disaster recovery plan implementation.

4. A backout plan.

5. Ensuring adequate technical staff is available for an appropriate time period following the change in the event of problems.

6. In a timely manner (within 48 hours is recommended), submit all appropriate documentation to the appropriate personnel for review. The level of documentation should be appropriate to the level of risk and should include everything that would normally have been submitted with the request for change.

Standard Change Implementation

All standard change implementation processes should have the following elements:

1. A backout plan.

2. Scheduling, either during pre-approved time periods or after consulting with the appropriate personnel.

3. Notification of appropriate personnel. Notification should be given far enough in advance that there is time to reschedule.

4. Ensuring adequate technical staff is available for an appropriate time period following the change in the event of problems.

Post-Implementation Review

This process is conducted after implementation in order to test and verify the change, identify and resolve any issues, and determine whether to initiate the backout plan. The following elements are included where appropriate or specifically required by relevant LIT policies:

1. Verification that the change occurred.

2. Testing of the system post-change.

3. Resolution of any problems, if possible.

4. Decision on whether to initiate backout plan.

5. Analysis and "lessons learned" (corrective or preventative actions) from any issues or complications.

Documentation

1. Post-implementation, change details are documented in order to provide a record of the change (audit trail) that can be used in preparation for future changes or in future problem or incident handling. The specific manner in which changes are logged (e.g., spreadsheet, database, paper files, problem/helpdesk software, etc.) can be decided upon by the information resource owners or custodians; however, the following elements should be included where appropriate or specifically required by relevant LIT policies:

a. Date/time of change implementation.

b. Any relevant Post-Implementation Review details, such as complications, changes to testing procedures, or problem resolution.

c. Issues that arose during implementation.

d. Individuals that performed the implementation.

e. An indication of successful or unsuccessful completion of the change.

f. Updates to documentation such as disaster recovery plans, operational documentation, or change management databases.

g. Archiving of request for change documentation. h. Submission of additional documentation or reports (e.g., post-implementation analysis) to appropriate personnel.

2. Updates to relevant operational documentation shall be made in a timely manner.

3. Analysis and corrective/preventative actions shall be documented for changes that deviated from the plan unexpectedly, resulted in an unplanned disruption in services, or unexpectedly reduced the security of the information resources.