ROWAN UNIVERSITY POLICY

Title: Change Management Policy
Subject: Information Security
Policy No: ISO:2013:09
Applies: University-Wide
Issuing Authority: Senior Vice President of Information Resources

...

and Technology and Chief Information Officer
Responsible Officer: Director of

...

Device Management
Date Adopted: 07/01/2013
Last Revision:

...

08/

...

11/

...

2023
Last Review:

...

08/

...

11/

...

2023

I. PURPOSE

...

The purpose of this policy is to manage changes in a well-communicated, planned and predictable manner that minimizes unplanned outages and unforeseen system issues. Effective change management requires planning, testing, communication, monitoring, rollback, and follow-up procedures to reduce negative impact to the user community.

II. ACCOUNTABILITY

Under the direction of the President and Provost, the Chief Information Officer and the Information Security Officer shall ensure compliance with this policy. The Vice Presidents, Deans,

...

and other members of management shall implement this policy

...

in their respective areas.

III. APPLICABILITY

This policy applies to all

...

members of the Rowan Community who manage, change or control the University's electronic information and information systems.

IV. DEFINITIONS

1. Change - The addition, modification or removal of approved, supported or base lined hardware, network, software, application, environment, system, desktop build or associated documentation of the production IT environment.
2. Production IT environment - system components used to provide information technology (IT) service to employees, faculty, patients, students, including but not limited to: server hardware and associated operating systems, virtual servers, software applications, virtual applications, networks, data storage, air-conditioning, power supply, server rooms, datacenters, networks, and workstations that are part of the University Environment. This includes IT environments managed by IRT, departments, colleges, and vendors.

V. REFERENCES

1. Change Management Procedures for IRT

VI. POLICY

Refer to Rowan University Technology Terms and Definitions for terms and definitions that are used in this policy

V. POLICY

1. All changes to an information system or an information technology environment must follow appropriate change management procedures.

2. Change management procedures support the goal of increasing

   General Principles:
   Change management refers to a formal process for making changes to IT services. The goal of change management is to increase

   awareness and understanding of proposed changes across an organization and ensure that all changes are made in a

   thoughtful

   way that minimizes negative impact to services and customers. Change management

   generally includes

   procedures must include the following steps:

   1. Categorized into separate levels, each with different approval and notification requirements that are outlined in the Change Classification Matrix. 

   2. Assigned a priority based on the definitions outlined in the Change Priority Description. 

1. Planning

   : Plan the change, including the implementation design, scheduling, communication plan, testing plan and roll-back plan.
2. Evaluation: Evaluate the change, including determining the priority level of the service and the risk of the proposed change; determine the change type and the change process to use.

3. and Submission: This phase consists of the steps to move a change from request to the eventual release into the production environment. These steps include the design, test, backup, rollback, and documentation of this request. Change requests are:

4. Evaluation: This phase consists of reviewing the impact of the change in order to validate the change priority description, change category, schedule, risk and business impact, as well as defining the appropriate change process. 

5. Approval: This phase consists of reviewing the change plan

   Review: Review Change Plan

   with peers and/or Change Advisory Board (CAB) as appropriate to the change type

   .Approval: Obtain

   and obtaining approval of the

   Change Plan

   change plan by management as needed.

6. Communication:

   Communicate about changes with the appropriate parties

   This phase consists of communicating the change and any announcements for planned downtime to all affected stakeholders.

7. Implementation:

   Implement

   This phase consists of implementing the change by the change assignee or release team.

   Documentation: Document

8. Post Implementation Review and Closure: This phase of closing the change

   and any review and approval information.
9. Post-change review (if necessary): Review the change with an eye to future improvement
   1. All changes to IT services must follow a standard process to ensure appropriate planning and execution
   2. Changes are categorized into four categories, each with different approval and notification requirements that are outlined in the Change Classification Matrix (Appendix A). In addition, all changes are assigned a priority based on the Change Priority definitions (Appendix B). 
   3. It is the responsibility of the CIO, Dean, and/or Vice President of the business unit or college to ensure that all areas under their direction have documented processes that meet minimum standards, are reviewed annually, and are communicated to staff. The CIO, Dean, and/or Vice President serves as Change Manager by default and is ultimately responsible for ensuring that changes are made in a manner appropriate to their impact on university operations.
3. Minimum Standards:
1. All changes must follow a process of planning, evaluation, review, approval, and documentation as referenced in the Change Management Procedure for IRT.
2. All changes deemed Normal Major must be presented to a Change Advisory Board (CAB) for input and advice (See Section D – Roles & Responsibilities"). Should a Change Manger (or designee) decide to act contrary to advice from the CAB, a written explanation must be submitted to the CAB and the Vice Provost for Information Services. In addition, before a change can be deemed a Standard Charge it must be presented to the CAB for input and advice.
3. All changes deemed Emergency must be presented to a Change Advisory Board (CAB) for input and advice unless time constraints require that changes be made prior to submission. In these cases, verbal approval must be given by the Change Manager. Submission to the Change Advisory Board for review must be done by the next scheduled meeting.
4. Documentation of all changes must be made in a Change Log that is stored in a common location so that coordination of changes across the organization can be managed appropriately
4.  Security Review and Approval:
1. In addition to the requirements above, all security changes must be reviewed and approved by the Information Security Office (ISO).
2. All firewall, ACL, and GPO changes must include a business justification for each change item

Roles & Responsibilities:

Roles

Description/Responsibilities

Change Advisory Board (CAB)

The Change Advisory Board is a group called together by the Change Coordinator to act in an advisory capacity to the Change Manager to all changes that are categorized as major or emergency (after triage). They also authorize changes as Standard Changes, if the qualifications are met. The CAB is made up or individuals within or outside IT who are relevant in the making the decisions on whether a change should be authorized. They are called together as required in order to ensure that changes are progress in a prompt and efficient manner.

Change Advisory Board Members

• Review the list of scheduled changes• Attend a weekly meeting either in-person, by video or telephone conference.• Prepare for the weekly meeting by inviting representatives from business or user groups, technical support staff and vendors as necessary to resolve potential conflicts.• At the meeting, affirm acceptance of planned changes on behalf of the Department or state potential conflicts and work to resolve them. Stated positions will be required and recorded.

Change Coordinator

The Change Coordinator will be the chairperson for the CAB. Responsible for the coordinating the flow of documentation/communication surrounding any changes to the IT production environment.

Change Implementer/Change Implementation Team

The Change Implementer will usually be the technology subject matter expert who is responsible for implementing the change into production. If the change implementation needs external third party or supplier involvement this needs to be documented within the RFC form.

Change Initiator

Anyone can initiate a change within the organization – however, consideration must be given to whether this should include all users. If users are to be allowed to raise changes this should be controlled through the service desk, this will ensure that only relevant and appropriate changes are raised.

Change Owner

The Change Owner is the person who is responsible for the making the change happen, ensuring the change ticket is updated and marked as completed. This includes designing the change.

Change Tester

Wherever possible with all changes the Change Tester should not be the Change Implementer. This is to ensure rigorous and error free testing.

Internal Audit (IA)

Determine the effectiveness of internal controls, adherence with applicable laws and regulations, and reliability of financial reporting

1. request and reviewing the lessons learned from successful or failed changes with the goal of learning from the experience, documenting them for future reference.

5. Change requests must adhere to the following:

1. A change request must be submitted for all changes in accordance with change management procedures.

2. All change requests must adhere to the time requirements set forth in the change management procedures to enable adequate review of each change type including but not limited to normal, emergency, or standard changes.

3. All change requests must go through the approval process in accordance with the change management procedures before proceeding with the change implementation.

4. Any change request not meeting the criteria established in the change management procedures will be denied. 

5. All change requests must include the items and necessary documentation, test plans and information outlined in change request requirements

6. Approvals, Pre-Approvals or Change Exemptions:

1. All changes are subject to the approval process outlined in the procedures for the Change Management Process, Normal Change Process, Emergency Change Process or Standard Change Process.

2. CAB meetings should occur on a bi-weekly schedule but no less than weekly to support the review and approval of change requests. 

3. In coordination with the Information Security Office (ISO), the CAB chair may define criteria under which a change may be considered pre-approved or exempt from change control. 

4. Pre-approved criteria must be documented and made available for all CAB members.

7. Change Communication:

1. All changes are subject to the communication processes outlined in the planned maintenance communication.

2. The change requestor is responsible to ensure that communication flows to the stakeholders impacted by the change. The CAB has the authority to designate the flow of specific communication.

3. All change must be communicated to the corresponding stakeholders including data owners, data stewards, and where appropriate the general university community

8. Change Control Process Documentation:

1. Documentation supporting the change control process must be maintained and reviewed periodically as needed.

9. Testing and Validation:

1. Test environments are recommended for information technology systems or environments creating, processing, storing or transmitting data classified as confidential.

2. For changes impacting confidential data, testing and validation must be completed to ensure the isolation of the change, minimize the unnecessary impact on relevant business process(es), and ensure a successful change implementation

10. Roles and Responsibilities: 

1. The change management process is supported by the following stakeholder roles and associated responsibilities:
   
   

   Roles	Description/Responsibilities
   SVP and Chief Information Officer (CIO)	The SVP and Chief Information Officer designates and appoints the CAB Chair.
   Information Security Officer	The Information Security Officer may provide staff with security expertise to serve on the CAB and/or to conduct security impact analysis prior to approval of a change. The Information Security Officer or designated staff has the authority to reject a change if deemed the change would cause harm to the university.
   Chief Technology Officer (CTO)	The CTO must provide staff with infrastructure expertise to serve on the CAB and/or to conduct technology impact analysis prior to approval of a change. The CTO or designated staff has the authority to reject a change if deemed the change would cause harm to the university.
   Directors of Software Development & Systems Services and Business Intelligence & Analytics	The Directors of Software Development & Systems Services and Business Intelligence & Analytics must provide staff with application and analytics expertise to serve on the CAB and/or to conduct technology impact analysis prior to approval of a change. The Directors of Software Development & Systems Services and Business Intelligence & Analytics or designated staff have the authority to reject a change if deemed the change would cause harm to the university.
   Change Advisory Board (CAB) Chair	The Change Advisory Board (CAB) Chair functions as the chairperson for the CAB. The CAB chair is responsible for managing the implementation and maintenance of the change management program.  Responsibilities and authority of the CAB chair includes but are not limited to: Ensuring all steps of the change management procedures are followed in accordance with section V.2 of this policy.  Management of CAB membership including appointment of new members and offboarding of old members Ensuring CAB members have access to CAB resources including system tools, procedures, and training.  Ensuring change management program documentation is maintained.   Designation of a backup to handle change coordinator and change meeting responsibilities. Cancellation of CAB meetings when no changes are due for review Discretionary authority to override any deviation from the change request procedures. Any deviation must be recorded in the change management system.
   Change Coordinator	The CAB chair acts as the routine change coordinator. The change coordinator functions as the individual responsible for overseeing the change management meetings. The CAB chair can designate another individual to act as the coordinator in their absence.  The change coordinator hosts weekly change management meetings and coordinates the flow of change requests on the agenda.
   Change Advisory Board (CAB)	The Change Advisory Board (CAB) is a group of individuals that have the collective responsibility and authority to review and approve changes. The group is chosen to evaluate changes from various perspectives within the organization and approve changes based on their domain expertise. The CAB is a check and balance on change activity, assuring that changes are held to the defined criteria before being implemented.  Responsibilities and authority of the CAB includes but are not limited to: Acting in an advisory capacity to the change manager for all changes.   The CAB is required to participate in the change management meetings facilitated by the change coordinator  The CAB may invite guests to the change management meeting as needed to provide additional perspective from the business or user community.
   Change Advisory Board (CAB) Guests	Change Advisory Board (CAB) Guests are individuals with subject matter expertise who may be asked to participate in meetings to discuss specific changes that impact their areas (e.g. individuals from business or user groups)
   Change Requestor	The Change Requestor is the individual requesting the change  to be reviewed and considered for implementation. This request for a change may originate from any number of sources including the end user of the system, the support desk, or from management. Proposed changes may also originate from vendor-supplied patches, application updates, security alerts, system scans, etc
   Change Manager	The role of the change manager

Change Manager

The role of the Change Manager

1. in the change process is to authorize/approve all changes. The

Change Manager

1. change manager also ensures that all activities to implement the change are undertaken in an appropriate manner and are documented and reviewed when completed.
   Change Implementer	The change implementer will usually be the technology subject matter expert who is responsible for implementing the change into production.

Non-Compliance and Sanctions
Violation
1. 
   

VI. POLICY COMPLIANCE

Violations of this policy may subject the violator to disciplinary actions

...

up to or including termination of employment or dismissal from

...

school, subject to applicable collective bargaining agreements and may subject the violator to penalties stipulated in applicable state and federal statutes.

...

Unscheduled or unauthorized changes that occur outside this Change Management Policy will be considered violations. Sanctions shall be applied consistently to all violators identified in Section III Applicability regardless of job titles or level in the organization per the Acceptable Use Policy.

VI. ATTACHMENTS

1. Attachment A - Change Classification Matrix
2. Attachment B - Change Priority Description
3. Attachment C - Clarification of Change Management Requirements with Respect to Virtual Environments
    

By Direction of the CIO:Image Removed
 __________________________________

Mira Lalovic-Hand,
SVP and Chief Information Officer

...

Image Removed

...

Priority

...

Description

...

Immediate

...

Requires immediate implementation (emergency change process). Causing loss of service or severe usability problems to a larger number of Users, a mission-critical system, or some equally serious problem. Immediate action required. Resources may need to be allocated immediately to build such authorized changes.

...

High

...

Requires implementation within 48 hours. Severely affecting some users, or impacting upon a large number of users. To be given highest priority for change building, testing and implementation resources. (Other than emergency).

...

Medium

...

Requires implementation within five days. No severe impact, but rectification cannot be deferred until the next scheduled release or upgrade. To be allocated medium priority for resources.

...

Low

...

Requires implementation by an indicated date. A change is justified and necessary, but can wait until the next scheduled release or upgrade. To be allocated resources accordingly.

ATTACHMENT C
Clarification of Change Management Requirements with Respect to Virtual Environments

...

This example applies only to virtual environments, not to systems in general. Exemptions are offered for cases where a change cannot impact the production environment. 
Note: Clustered pair server technology is not considered part of a virtual environment. Although service fails over from one server to another, there is a momentary lapse of service in the active production environment, as well as a risk of not restoring full redundancy.

...

The terms host and guest describe the physical and virtual machines. The physical computer on which we install VMware Workstation software is called the host computer, and its operating system is called the host operating system. The operating system running inside a virtual machine is called a guest operating system. 

IRT provides a host server service. If there are changes in interface connectivity or service availability of the host, then IRT will schedule such changes per the IRT Change Management policy. However, routine maintenance, such as operating system patching, is done without impacting interface connectivity or service availability, is not considered part of the active production environment, and is therefore exempt from the IRT Change Management policy. Detailed records of such routine maintenance are stored in the VMWare environment.

IRT also provides guest server service. Changes to guest servers may impact service to the production environment and therefore should be scheduled in accordance with the IRT Change Management policy.

Virtual Applications: Xen Server and CitrixIRT provides an application service. I f there are changes in interface Connectivity, service availability, the user experience or integration with other applications, then such changes are said to impact the production environment and IRT will schedule such changes per the IRT Change Management policy.