Information Technology Change Management Standard


University of North Carolina at Chapel Hill Standard on Information Technology Change Management



Information Technology (IT) change management increases awareness and understanding of proposed IT changes. IT change management ensures that we make IT changes in a way that is better for IT systems, services, and the people who use them. 

The purpose of this Standard is to:

  1. Describe what needs to happen before making a change to reduce the risk to other systems and services,
  2. Support notification to affected people in advance of any change, and
  3. Set requirements for University units making changes that tell them how to comply with IT Security obligations.


Any person and any University of North Carolina at Chapel Hill ("University" or "UNC-Chapel Hill") unit responsible for material changes to production IT systems, applications, and services for the University.



Any unit responsible for IT systems and services needs to have a defined practice that follows this Standard to make changes to an IT environment.

People need to request, test, and approve each change before making the change according to the unit practice.

Units need to set their change processes according to the size, scope, and risk profile of their IT environment. Units must create and document processes or procedures which need to:

  • Classify types of IT changes into categories. You must use at least the following categories: operational change, normal change, and emergency change. You may use more categories if needed. Document examples for each category.
  • Ensure that only authorized people make changes.
  • Ensure that you assess changes based on risk.
  • Decide who will need to approve the change, with proper separation of duties.
  • Communicate changes to people who need to know.


When units build IT change management processes for their IT systems, we recommend:

1. Documenting the Change Request

Include categories and how to record change requests. Include informal ways for people to tell how important and how difficult the change will be.

2. Formal Assessment

Decide why you need to make the change. What are the risks and benefits of making or not making the change? Create a system for accepting or rejecting change requests. Include a way to communicate decisions back to the person who requested the change.

3. Planning

Document a way to track test plans or keep detailed records of tests and project plans. The document needs to include:

  • change design,
  • how you're going to make the change,
  • plans for undoing (“rolling back”) changes, and
  • ways to tell (“rollback triggers”) if the change won't be successful.

4. Designing and Testing

Design the program for system and software change and tests. Once the change tests are successful and approved, schedule the change to be made in a live (“production”) environment.

5. Implementation and Review

Staff make the change and the right people review the change as needed.

6. Final Assessment

Close the change request when the change is complete.

7. Change Documentation

Document all planned changes made to systems (for example: servers, databases, applications, batch jobs, and infrastructure) and all planned changes requiring change management approvals.


Some principal investigators (PI) need to put in place research systems quickly and only use them for a short time. In cases where the PI is maintaining the research system, and not relying on a formal IT group, the PI does not need to follow the requirements of this Standard. The unit responsible for each system will be responsible for any use of this exception. The person responsible for  IT change management for the unit needs to approve and document the exception.

If test and development systems are separate from production systems, the test and development systems don't need to follow the requirements of this Standard. However, this Standard does apply if changes to the test and development systems could change the live production system.

The Chief Information Officer (CIO), the Assistant Vice Chancellor for Customer Experience and Engagement, or anyone named in writing by the CIO may issue other exceptions to this Standard. All exceptions must be made in writing.


  • Change: The addition, modification, or removal of anything that could affect IT services.

Related Requirements

External Regulations and Consequences

Failure to follow this Standard may put University information assets at risk and may have disciplinary consequences for employees, up to and including termination of employment. Students who do not adhere to this Standard may be referred to the UNC-Chapel Hill Office of Student Conduct. Contractors, vendors, and others who do not adhere to this Standard may face termination of their business relationships with UNC-Chapel Hill.

Violation of this Standard may also carry the risk of civil or criminal penalties.

University Policies, Standards, and Procedures

Contact Information

Primary Contact

Unit: ITS Policy Office

Phone: 919-962-HELP


100% helpful - 1 review
Print Article


Article ID: 131250
Thu 4/8/21 9:04 PM
Sun 9/11/22 4:06 PM
Responsible Unit
School, Department, or other organizational unit issuing this document.
Information Technology Services
Issuing Officer
Name of the document Issuing Officer. This is the individual whose organizational authority covers the policy scope and who is primarily responsible for the policy.
Issuing Officer Title
Title of the person who is primarily responsible for issuing this policy.
Assistant Vice Chancellor, Customer Experience & Engagement
Next Review
Date on which the next document review is due.
09/11/2025 12:00 AM
Last Review
Date on which the most recent document review was completed.
09/11/2022 12:00 AM
Last Revised
Date on which the most recent changes to this document were approved.
08/19/2020 10:48 AM
Effective Date
If the date on which this document became/becomes enforceable differs from the Origination or Last Revision, this attribute reflects the date on which it is/was enforcable.
08/19/2020 10:48 AM
Date on which the original version of this document was first made official.
04/24/2018 12:00 AM